Sounds like Progressive enhancement [1].
[1] http://tomdale.net/2013/09/progressive-enhancement-is-dead/
Sounds like Progressive enhancement [1].
[1] http://tomdale.net/2013/09/progressive-enhancement-is-dead/
The approach described in this blog post builds a JavaScript app from the get-go, and uses a server-side technique to extract standalone HTML from the JavaScript application.
The net effect is the same (you get HTML on the client before you executed the JavaScript), but the developer paradigm is sharply different.
Typical progressive enhancement techniques require you to carefully construct a version of your application that works without JavaScript, and then find ways to shim in and bring the page alive. The approach I'm working on provides the HTML as a by-product of running the application normally.
Additionally, progressive enhancement techniques almost always involve server-side rendering, which means you lose the benefits of client-side routing I describe in the post.
The goals of progressive enhancement are wonderful. My complaint has always been that previous techniques hamper developer productivity far too much to be realistic. With FastBoot, I'm hoping we can offer the benefits with far fewer costs.
Yes, progressive enhancement and server-side rendered JS are similar. You can see the latter as a new version of the former. But it is implemented in such a way - a novel way - that it definitely deserves a term of its own.
Even middle of the road efforts I tried a few years ago (such as sharing a templating language between client and server even when the implmentation language differs) was fraught with friction compared to this technique.
PE techniques aren't documented (so far as I know) so it's up the developer to take the path they're most comfortable with.
FastBoot, I suspect, will dictate how I code my application/server side logic.
On the surface, it looks like the cost of FastBoot is higher.
The benefits are, I suspect, are higher though: single code base, reusable views, etc.
As a developer of isomorphic (there's another term to pick apart!) React apps, I'm thrilled Ember and others are reaching the same conclusions on why server-side rendering is crucial.
I'll still call it Progressive Enhancement, since a server-generated response is "enhanced" with client-side functionally that still functions for those with it disabled.