Congrats @tomdale!
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.
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.