Aaand that's where I stopped reading. Try not to kick your articles off with dogmatic statements like this and, if you have to, at least make sure they're factual.
As stated below, I will probably remove this Introduction, since it seems to distract from what this article is about. I hope you consider reading the article anyway.
"Google is changing the monopoly of JavaScript by implementing the Dart VM in their own browser."
As far as I know community doesn't care much about Dart [1] and they are concentrating on further enhancement on ECMAScript.
[1] : http://en.wikipedia.org/wiki/Dart_%28programming_language%29...
Do you _honestly_ believe Dart is going to replace or threaten Javascript "very soon"? Enough to be willing to bet on that?
That alone discredited the article a bit. How can one be so confident of something that is highly improbable?
[1]: https://en.wikipedia.org/wiki/Dart_%28programming_language%2...
I will probably remove that statement though, since a lot of people seem to have extremely strong feelings about that, and are distracted from what this article is actually about.
Chrome ships a Dart VM and hopefully Mozilla, Apple and Microsoft will follow suit one day.
Google ships a special Dart-enabled version of Chromium (Dartium) with the Dart SDK. Chrome, however, does not currently ship (with) a Dart VM.
Doing this is a horrible waste of resources.
It's not really: we don't have a proper caching infrastructure anyway to conserve both CPU cycles and bandwidth by allowing the whole page to be cached and just minor fragments to be loaded dynamically. Back in the days, when most individuals/offices/ISPs would have some sort of cascaded Squid setup, it was more helpful.
As for caching in the client itself: possible and useful (provided the user will load the page many times per day), but not helping with the "re-rendering for each user" part as far as bandwidth is concerned.
The rendering effort itself is largely a non-issue. If your web framework is inefficient and you run out of juice on the server side, you can simply cache the static parts of your page with memcached or even use some setup with ESI on a load balancer.
Also
No, not with any kind of intermediate caching (assuming not all resources have identical cache lifetimes)
For certain definitions of free.
I've found that sites which abuse this tend to be much less responsive and can even cause my laptop fan to start spinning like crazy
Sometimes, depending on the team and the project, it will make sense to store at least some of that complexity in the HTML.
Usually, it forces all kinds of artificial constraints on the app, such as atomic ratings counts when a looser, more cache-friendly requirement would suffice, etc.,
"Create an AJAX request to the location (eg.: /about.html). Change the URL in the browser with the history API (this way, the back and forward buttons still work in the browser). Show a loading animation that the content is now being loaded. When the content is loaded, parse it to extract the contents of #main (you can help yourself there by adding markers in your HTML) and replace the content of your current #main section with the one you just loaded. Make sure that you handle all the links in your new #main content so they will act the same and fire off any BrowserScript required for the page that just loaded."
Aside of usability issues (what if the user has JavaScript disabled?), I don't really get how search engine spiders will be able to index the web site.
All the endpoints serve static html. I have no idea what the point in ajaxing it is (so you can stick in a pointless animation I guess). However it would degrade nicely, and search engines would be unaffected
It becomes necessary when you have elements that you want to persist on your page. That might be an audio player or the state of a menu that you want to avoid painting.
It's just about a better UX for your users.
Doesn't the scroll bar serve as an indication?
They maybe able to access the static version, but how about their participation? What if they need to login to get access to certain information?
I just learned that certain screen readers have some support of JS. But does it work in general?
I agree the static pages would be faster, but I feel like there is dynamic content that should always be rendered. Login pages for example are often linked in a dynamic menu.
If this is so, author might want to view his page in a NoScript enabled browser. Why should the front image show itself through JavaScript if JS is on its way to meet dodo the bird?
Also, gray text on white background?
The downside of course is that rendering different HTML based on your user, their location, cookies, user-agent, etc. is really freakin' convenient. And if you commit to static HTML, you have to do all of your customization on the client, and load real-time data with an AJAX call.
But if you want a highly-performant site, the tradeoff is worth it.
Anyway, reading on to the implementation section, this stuff sounds pretty standard, and people have been doing this for many years. Some implementation details changed (pushState, hashchange, etc), but this approach is ancient.
I mean, if you just want to describe a simple technique, there's no need write a long, vague and controversial introduction..
Regarding SEO/performance for serving static HTML, many frontend frameworks provide a mechanism for rendering content on the server. For example, React.renderComponentToStaticMarkup (http://facebook.github.io/react/docs/top-level-api.html#reac...) can be used to render each static page on the server before sending it over the wire.
Also, I'm not sure how you reduce complexity by coupling view logic with backend datastore logic. In my experience it's far more maintainable to separate the backend and frontend, communicating between them via a REST API/web sockets. That way, everything is independently unit-testable and can be integration tested as well.
