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.
I'll be speaking[1] about my experiments with this at ReactConf at the end of the month. I've been using React, ReactRouter, and Reflux for rendering, routing, and data flow respectively. Gluing them all together was definitely a non-trivial project (that I'll be sharing in conjunction with my talk). It'll be rad to have JS apps that Just Work, regardless of runtime.
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?
You used different words to describe the same flow. More importantly, I'm talking about the _features_ that need to be isomorphic, not necc. every little step. I think we can presume that any server knows how to "receive a request".
I completely agree that this model is waiting for a fullstack framework to come along. Full fledged React apps are way too hard to get running on the server, even if theoretically possible.
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.
Another option is DerbyJS (http://derbyjs.com), a framework that I wrote along with the team at Lever to do this from the start. We don't use any kind of DOM or Virtual DOM for server rendering. Server rendering is all done straight into HTML and client rendering is done via DOM methods directly. Glad to see server and cliemt agnostic rendering catching on with other frameworks!
Correct me if I'm wrong, but doesn't Derby use MongoDB for the backend? While Derby broke significant ground, that dependency eliminates it from consideration for most people I've talked to.
We use Mongo and currently Mongo is the only database with an adapter for the full realtime synced stack. However, Derby itself can be uses without the ShareJS backend, and it is possible to write adapters for different databases. Thanks for the question!
1) Not every client on the Internet is a JavaScript-enabled web browser. Searchbots are the most obvious example of this. They can better understand semantic HTML markup than the random blob of JS most client-side apps are made up of.
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).
Though you should read the blog post tomdale linked to in his reply, the short version of it is this:
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 get the motivation in the abstract, but does someone have a use-case for where this is really useful?
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.
25 comments
[ 3.0 ms ] story [ 64.9 ms ] threadUsing 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.
We've been doing this with React for a little while now, using an approach like the one for this example app: https://github.com/Dakuan/nattr
server: https://github.com/Dakuan/nattr/blob/master/app/server/route...
client: https://github.com/Dakuan/nattr/blob/master/app/client/app.j...
Although recently using React-router has helped clean things up a bit so they look a bit more like:
https://gist.github.com/Dakuan/a08ce668e6f7b25d9eec
I did a quick talk on the benefits of taking server rendering a bit further: https://www.youtube.com/watch?v=NklXL5100Cs#t=1m
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.