4 ms·

Thanks! 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

by tomdale 12y ago

Thanks! 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.

bsimpson 12y ago
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? http://conf.reactjs.com/schedule.html#tweak-your-page-in-real-time-without-leaving-the-comfort-of-your-editor http://conf.reactjs.com/schedule.html#tweak-your-page-in-rea...
- ericclemmons 12y ago
  We should sync up! I've cracked this similar isomorphic nut myself in a similar manner and will be giving 2 talks on it as well. 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.
  - bsimpson 12y ago
    I'm easy to find. =)
- gcanti 12y ago
  Shouldn't it the other way around? 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
  - bsimpson 12y ago
    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".
deleted 12y ago
[deleted]
tristanz 12y ago
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.

by tomdale 12y ago

bsimpson 12y ago

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? http://conf.reactjs.com/schedule.html#tweak-your-page-in-real-time-without-leaving-the-comfort-of-your-editor http://conf.reactjs.com/schedule.html#tweak-your-page-in-rea...

ericclemmons 12y ago
We should sync up! I've cracked this similar isomorphic nut myself in a similar manner and will be giving 2 talks on it as well. 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.
- bsimpson 12y ago
  I'm easy to find. =)
gcanti 12y ago
Shouldn't it the other way around? 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
- bsimpson 12y ago
  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".

deleted 12y ago

[deleted]

tristanz 12y ago

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.