Need suggestion for a "treeview" (navigation) JS widget for a site that is:
Really large (up to 100,000 pages)
Static - all pages are generated from a external source, and the widget is embedded in every page.
To clarify: there are no frames, and no application server. All pages are generated and placed in a file system, each page is loaded independently, that means the treeview navigation will be loaded every time as well, so it should either use multiple files and load parts of the tree on demand, or to be super-efficient.
Commercial OK.
Use mashable kind of tree. Click here for detailed architecture
All serious JS tree widgets allow dynamic loading of children. The key issue here is that most of them will send the server a query like getChildren?parent=23674 and this won't do for your case.
Since the site is static, you need to generate files with descriptions of the branches of the tree in JSON format and request those from the server as the user expands nodes in the tree. You could also create files which contain the tree children as HTML but you will be more flexible when you send data to the client and use JavaScript to convert the data into HTML (plus you will save a lot of bandwidth).
Try Yahoo's TreeView. There is an example how to load data dynamically.
Noticed that none of the links are working. However there was one written for the exact same reason, which is efficiency on large number of data. You might want to check out PixoTree, and see if it's the right tool for you.
PS. I know it's an old question, but thought it might help someone who stumbles upon this question.
Related
As seen in numerous articles about webpage rendering. What is the difference between the two?
Another example: ("Once the request is done processing, your browser gets back the fully rendered HTML and displays it on the screen.") [https://www.freecodecamp.org/news/what-exactly-is-client-side-rendering-and-hows-it-different-from-server-side-rendering-bd5c786b340d/]
Another example: ("Server-side rendering (SSR) is an application’s ability to convert HTML files on the server into a fully rendered HTML page for the client.") [https://www.omnisci.com/technical-glossary/server-side-rendering]
Bonus points for anyone who can give examples of actual differences in the code.
This is a common term when working with Single Page Applications (SPAs) built on React, Angular, Vue, etc. These frameworks render out Typescript/Javascript into browser-readable HTML. This is different then just making a raw .html file because these framework scripts are being 'rendered' as HTML.
Based on my understanding, HTML is a markup language that can be used to make web pages. Content wise, rendered or not, it will have the same tags <html></html>, <body></body>, and so on.
The only different I see as a user is that for a static HTML page, the id tags (e.g. <div id="myID"></div>) and class tags will likely be same for each visit.
However for rendered HTML page, the ids and classes might be different each time. (e.g. <div id="myID12"></div> for 1st time, but <div id="myID34"></div> for the second).
One possible incentive for using rendered HTML is to prevent other people from using web crawlers or automated programs on the website. I hope this answers your question.
So I am going to have many pages that have a bunch of text in them, that a JS and CSS file will convert to a colored and everything webpage. I noticed that the text is usually going to be long, and since there are going to be many webpages, I should lower file size. Also since I don't want to ruin file quality, I have decided that my JS file is going to take the text and make a webpage out of it. Side Note: what I am trying to do is make tutorial pages, so I am going to use JS to generate a lot of the things that are on every tutorial page, like the lessons list, to lower file size.
I have noticed that metadata (<head> content) usually takes up some space that JS could generate, so I thought, Why don't I just generate this with JS? But then arose the problem that the some browsers might not parse it, or it might be slow to parse it. So I am asking here on Stack Overflow:
Should JavaScript generate metadata (and maybe almost the whole page, like remove the <head> tag completely and generate it with JS)?
It depends on your desired result.
Google has improved it's SEO mechanisms to render your page before indexing it, see here:
https://developers.google.com/search/docs/guides/javascript-seo-basics
However other bots may not do the same, such as social media crawlers like facebook or twitter that read Open Graph meta tags, or other search engines like Baidu.
If a bot doesn't render your document then the javascript doesn't get executed and your meta isn't present.
Additionally, if your initial document does not contain the stylesheets or other CDNs it takes a bit longer for the client. Imagine the process:
With head
fetch document
fetch resources
render content
Without head
fetch document
render content
fetch resources
re-render
That's way over-simplified but it demonstrates my point.
Alternative:
If your content is so dynamic, you might consider Server Side Rendering (SSR) or Pre-Rendering
You would build your pages programmatically and store/serve them all, or build them on the server-side as they are requested.
https://developers.google.com/web/updates/2019/02/rendering-on-the-web
I want to write an application using NestJS. But coming from PHP, I am very much used to the SSR approach of rendering views for the client. Now, by using JavaScript, I could technically ask the server to not completely navigate a page, but just load the <body> element of the sent output, and then embed that into - and overwriting - the current view. By what I can tell, initially, this would work as I would just app.$mount(...) on the initially sent HTML and have Vue hydrate off that.
But what if I want to implement this across multiple pages?
The idea is, that by using SSR, I get to keep basically all SEO related features and can reduce the initially loaded JavaScript by taking advantage of WebPack's lazy-loading feature. But when a user navigates from page A (initially loaded) to page B (subsequent load), I would like to just replace/update the current content and then load the bundle apropriate to that page and hydrate.
Is that possible, and if, how?
So far, I know I would have to unload the currently used bundle to remove all references to events and objects from memory, and then load the new bundle in, which I can then use to hydrate the received view. And this does not take into account that a menu bar might not need to be treated separately, since it will only have to have the current location updated with a .current class appended to the relevant menu item. I might be wrong here, but that is why I ask :)
Check out the source code of Dropbox's main page or any Soundcloud page. You can see they've got a lot of Scripts going on, and little pure HTML content (article, main, p, div). I've been searching and it seems that way of generating pages is called dynamic content/HTML (correct me if wrong).
So, the function I think it has is to be able to edit multiple external separate files in Javascript (if that's the language it uses since they're scripts) so that the HTML documentes where they're linked to are generated dynamically.
Also, other possible function would be to have one external document, which let's say it's a navigation bar, and so you place it in multiple pages, and when you have to update, you just edit the external document and not each page (hooray!).
Questions:
Is it actually named Dynamic content?
What languages does it requires besides HTML, CSS, and JS? Like PHP or ASP (supposing if any is necesary at all).
Does creating pages in that way affects negatively/positively your website positioning in Google? Since I think when Googlebot reaches the page all it see are scripts.
There are two subtly different definitions of the word dynamic, which may be confusing your search for information about this. I'll answer your questions separately for each.
Dynamic as in "generated from content held in a database"
For example, on this page your reputation score was fetched from Stack Overflow's database and injected into the HTML.
Yes, this would be referred to as dynamic content. In contrast to static content, which would just be fixed files, dynamic content would be built up from its parts for each user who requests it.
Your second set of languages (PHP, etc.) are what read from the database and spit out the corresponding HTML.
Google's bot is smart: it can render pages and will see similar content to what you get in a browser. So generating pages dynamically instead of statically won't count against the site for SEO; dynamically generating lots of pages that are very similar might count against it though.
Dynamic as in "page content that updates without you having to refresh the whole page"
For example, as you wrote your question Stack Overflow tried to find similar questions and show them to you in case it had already been asked. JavaScript was sending a request to their server and updating part of the page in response.
This would also be referred to as dynamic content. The key difference is that it's JavaScript in the page that's making further calls to the server to fetch more content, which is what you're seeing on the minimalist sites you mention. This used to be called dynamic HTML (DHTML); more modern references are more likely to discuss it in terms of AJAX or "single page website".
Typically you'd have PHP or similar running on the web server, responding to the requests for content.
Again, Google's bot is smart enough to cope with this. That won't necessarily be the case for all search engines though.
I need to generate a PDF from the current screen in my webapp. Some kind of screenshot, but I'm facing serious difficulties.
The main problem is that the view contains a grid made with jQuery Gridster; and some "widgets" contain complex elements like tables, highcharts, etc.
So plugins like jsPDF or html2canvas can't render my page in a prorper PDF. They always generate it blank.
This is how the page looks like. You can/move resize each element:
(Sorry for the CIA style, but there's business data in there)
Some ideas I came across but don't work are:
Using browser print-to-pdf feature programatically. (can't)
Use phantomjs. (but page state matters, so...)
I believe a solution to this poroblem may be widely adopted by anyone trying to generate a PDF of img from current screen in a web app. Quite an unresolved problem.
It's ok if only works on Google Chrome.
Many thanks.
EDIT:
One posible solution might be to find a way to represent the current layout status with an object and save it with and id.
Then retrieve that object via url param with the id and apply the stored layout to the inital page.
This way I might able to take a screenshot with phatomjs, but it seems quite complex to me. Any alternative?
Based on the fact that you're struggling with capturing dynamic content, I think at this point you need to take a step back and see that you might need to alter your approach. The reason these plugins are failing is because they will only work with the HTML before interactions right?
Why not convert the HTML to .pdf format from the server side? But the key part here is, send the current HTML back. By sending it back, you're sending updated static HTML back to the server to be rendered into a PDF? I've used HTML to PDF from server side before and it works fine, so I can't see why it wouldn't be appropriate here.
See this answer for details about HTML to PDF server side.