1) How does transparent server-side rendering of Ember change the role of what was the server-side app before? Are you now managing a separate server environment for your Node Ember application?
2) Does this affect the ability to distribute your frontend over a CDN? Is this common practice for current Ember applications?
> How does transparent server-side rendering of Ember change the role of what was the server-side app before? Are you now managing a separate server environment for your Node Ember application?
Our goal is not to make Ember an "isomorphic" server-side framework. You would still have your regular backend responsible for generating JSON (whether that's Node, Rails, Django, .Net, etc.), and run an Ember app alongside it in the same data center to generate your HTML. In terms of server architecture, you've already separated HTML generation from JSON endpoints (for Ember, but possibly also for other clients like iOS, Android or API endpoints), and this continues that separation.
The benefit is that the HTML generation that lives on the client in order to make subsequent navigations fast can also live on the server to make initial boot fast.
> Does this affect the ability to distribute your frontend over a CDN? Is this common practice for current Ember applications?
It is a common practice and it doesn't affect distribution over a CDN; it makes the CDN story stronger imo. You would still distribute the JavaScript payload and other assets necessary to boot and hydrate your app over a CDN, but you get initial content while you're waiting for those assets to download.
> Your Ember app will behave no differently than server-rendered apps when it comes to search engines, mobile users, cURL, or users with JavaScript disabled.
How are Javascript disabled users going to use the app? Unless the app consists text and links, all interaction like submitting a form is usually coded with the idea that an ajax request will be made instead of a form submission triggering a page refresh.
react-router is React's most popular router component (which is inspired by Ember's routing system) just delivered a solution for server-side rendering a few weeks ago. My app can now deliver the fully rendered html from the server and the server also can "fetch the models" when preparing the html. However, if the user is quick (or their internet connection is slow) and tries to submit a form before React had a chance to "rehydrate" it won't work. Sure links work just fine but none of the bits that require my app to be running will work which is significant portion of most applications designed around React, Angular, Ember, etc.
For now, either we go back to spinners (which won't stop spinning if you've got JS disabled) or design the whole app with JS-disabled users in mind which would mean a lot of duplicate effort by having two possible endpoints for submitting forms; ajax-returning endpoints and traditional POST request endpoints which would return a redirect or a full page of html with validation errors included.
I have form submission and redisplay with and without JavaScript on the client working with my React forms library (newforms) and react-router.
The server version funnels POST bodies through the same willTransitionTo hook that the client uses for form submisson. Superagent is used within the hook to attempt submission to the same API route in both environments and redisplay is done by rendering a full page on the server, or emitting errors from the API via an EventEmitter on the client, all with the same React component. User input, validation errors and any other data required to render the server version are made available for the client version to rehydrate from at any time it's able to.
There are still some bits which feel (and are) hacky, but it works - details here:
My initial happiness when I got server-side rendering working complete with ajax calls on the server was short lived once I realized none of my forms worked until React had chance to load and run.
I'm really glad someone else out there has noticed this issue and is attempting to tackle it.
Although I was hoping I would still have control of how I build my forms while I do it. Do you think it would be possible to separate the form submission and redisplay functionality from the widget library part of newforms?
The important part for making it isomorphic is the data flow - you could use any component which can populate its form fields and error messages from props on initial render. The express middleware [1] which uses your react-router routes just handles getting data to the right place.
12 comments
[ 3.6 ms ] story [ 34.3 ms ] thread1) How does transparent server-side rendering of Ember change the role of what was the server-side app before? Are you now managing a separate server environment for your Node Ember application?
2) Does this affect the ability to distribute your frontend over a CDN? Is this common practice for current Ember applications?
Our goal is not to make Ember an "isomorphic" server-side framework. You would still have your regular backend responsible for generating JSON (whether that's Node, Rails, Django, .Net, etc.), and run an Ember app alongside it in the same data center to generate your HTML. In terms of server architecture, you've already separated HTML generation from JSON endpoints (for Ember, but possibly also for other clients like iOS, Android or API endpoints), and this continues that separation.
The benefit is that the HTML generation that lives on the client in order to make subsequent navigations fast can also live on the server to make initial boot fast.
It is a common practice and it doesn't affect distribution over a CDN; it makes the CDN story stronger imo. You would still distribute the JavaScript payload and other assets necessary to boot and hydrate your app over a CDN, but you get initial content while you're waiting for those assets to download.
How are Javascript disabled users going to use the app? Unless the app consists text and links, all interaction like submitting a form is usually coded with the idea that an ajax request will be made instead of a form submission triggering a page refresh.
react-router is React's most popular router component (which is inspired by Ember's routing system) just delivered a solution for server-side rendering a few weeks ago. My app can now deliver the fully rendered html from the server and the server also can "fetch the models" when preparing the html. However, if the user is quick (or their internet connection is slow) and tries to submit a form before React had a chance to "rehydrate" it won't work. Sure links work just fine but none of the bits that require my app to be running will work which is significant portion of most applications designed around React, Angular, Ember, etc.
For now, either we go back to spinners (which won't stop spinning if you've got JS disabled) or design the whole app with JS-disabled users in mind which would mean a lot of duplicate effort by having two possible endpoints for submitting forms; ajax-returning endpoints and traditional POST request endpoints which would return a redirect or a full page of html with validation errors included.
The server version funnels POST bodies through the same willTransitionTo hook that the client uses for form submisson. Superagent is used within the hook to attempt submission to the same API route in both environments and redisplay is done by rendering a full page on the server, or emitting errors from the API via an EventEmitter on the client, all with the same React component. User input, validation errors and any other data required to render the server version are made available for the client version to rehydrate from at any time it's able to.
There are still some bits which feel (and are) hacky, but it works - details here:
https://github.com/insin/newforms/issues/55#issuecomment-677...
My initial happiness when I got server-side rendering working complete with ajax calls on the server was short lived once I realized none of my forms worked until React had chance to load and run.
I'm really glad someone else out there has noticed this issue and is attempting to tackle it.
Although I was hoping I would still have control of how I build my forms while I do it. Do you think it would be possible to separate the form submission and redisplay functionality from the widget library part of newforms?
[1] https://github.com/insin/isomorphic-lab/blob/master/src/reac...
Now I will definitely sift to javascript for server and client development.
Good Job ember.js team.