Inside Ember.js FastBoot: Faking the DOM in Node
emberjs.com
emberjs.com
Using React for our current project was a no-brainer because it was the only library at the time to build in-browser web apps with an SEO story. It's great to see other, previously DOM-bound frameworks, tackling this problem.
We'll be working on this feature for the next few months, and we think it has the opportunity to fundamentally change how web apps are written. As you noted, little bits and pieces of server-side rendering have existed for awhile (I've heard of people using Backbone + Handlebars, as well as React), but historically it's required so much manual labor, and is so error-prone, that in practice very few people have the resources to pull it off.
We hope that by moving a full-stack framework like Ember.js to the server-rendered model, it will start to see wide-scale adoption.
In my experimentation so far, the three things you need to be able to do on the server are:
- choose a view to render (ReactRouter),
- get whatever data that view depends on (Reflux), and
- render it
I'd be curious to see your take on this. Are there other concerns you think a "full-stack framework" is needed to manage?
http://conf.reactjs.com/schedule.html#tweak-your-page-in-rea...
Ember's advancements on this are sorely needed, as anyone doing this today has to solve a lot of hard problems with lots of tools just to come close.
1. receive an "intent" (request) 2. get whatever data that intent depends on 3. choose a suitable view
I tend of think UIs as projections of the state/model
A second component though is caching. Most fast server-side apps cache large portions of the rendered page. A built in cache layer could make things much easier. The test case is fully static websites.
2) Parsing and executing a JS-based app is a non-trivial task that requires CPU time. Serving ready-to-render HTML to underpowered clients (like mobile phones) can make your app appear more responsive (as users can read your content while the JS engine is initializing the dynamic bits).
For many client side apps like Ember.js, a blank or mostly-blank HTML page is returned by the server. After the browser finishes loading the client-side app and all of its JavaScript, then that app is able to render the app's real content into the DOM. Sometimes that's fast, other times it's slow.
The FastBoot feature is designed to pre-render the HTML page on the server, and then let Ember take over on the client side once all of its JavaScript has finished loading. So basically the server emulates enough of the browser to do the same rendering that the browser would have done, then serves that to the user so they more quickly see a fully rendered page.
It helps performance, and also lets more primitive JS-free search crawlers & bots see a page that would otherwise only be rendered by JavaScript. Google's crawlers can handle JS apps now, but others may not.
I've worked on apps that are close to either extreme. I.e. static pages with content, and you add one or change one or two small pieces later, which is easily done returning the piece of html from the server, and data-exploration type apps where you initially load some kind of menu and then incrementally add/update/remove/reload all kinds of data, in which case your templating lives in the browser.