

Inside FastBoot: the road to server-side rendering - steveklabnik
http://emberjs.com/blog/2014/12/22/inside-fastboot-the-road-to-server-side-rendering.html

======
xtrumanx
> 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.

~~~
insin
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:

[https://github.com/insin/newforms/issues/55#issuecomment-677...](https://github.com/insin/newforms/issues/55#issuecomment-67756422)

~~~
xtrumanx
Wow, really. That's awesome!

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?

~~~
insin
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.

[1] [https://github.com/insin/isomorphic-
lab/blob/master/src/reac...](https://github.com/insin/isomorphic-
lab/blob/master/src/react-router-middleware.jsx)

------
cookrn
Thinking out "loud":

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?

~~~
wycats
> 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.

~~~
chrischen
Wouldn't this add processing latency? You'd have to have your original
backend, it'd send to Node+Ember, then finally it responds to the client.

------
hiby007
SEO is my main concern.

Now I will definitely sift to javascript for server and client development.

Good Job ember.js team.

------
yeskia
Let the SEO-friendly client-side JavaScript framework wars begin!

------
devicenull
Not to be confused with the Android FastBoot.

