Inside FastBoot: the road to server-side rendering
emberjs.com
emberjs.com
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...
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?
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.
Now I will definitely sift to javascript for server and client development.
Good Job ember.js team.