<story><title>Inside FastBoot: the road to server-side rendering</title><url>http://emberjs.com/blog/2014/12/22/inside-fastboot-the-road-to-server-side-rendering.html</url><text></text></story><parent_chain></parent_chain><comment><author>xtrumanx</author><text>&amp;gt; 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.&lt;p&gt;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.&lt;p&gt;react-router is React&amp;#x27;s most popular router component (which is inspired by Ember&amp;#x27;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 &amp;quot;fetch the models&amp;quot; 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 &amp;quot;rehydrate&amp;quot; it won&amp;#x27;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.&lt;p&gt;For now, either we go back to spinners (which won&amp;#x27;t stop spinning if you&amp;#x27;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.</text></comment>
<story><title>Inside FastBoot: the road to server-side rendering</title><url>http://emberjs.com/blog/2014/12/22/inside-fastboot-the-road-to-server-side-rendering.html</url><text></text></story><parent_chain></parent_chain><comment><author>cookrn</author><text>Thinking out &amp;quot;loud&amp;quot;:&lt;p&gt;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?&lt;p&gt;2) Does this affect the ability to distribute your frontend over a CDN? Is this common practice for current Ember applications?</text></comment>