4 ms·

Why is ember.js being ported to node? Could someone give me a little back story?

by dmak 12y ago

tomdale 12y ago
We described our motivation in the previous blog post in this series: http://emberjs.com/blog/2014/12/22/inside-fastboot-the-road-to-server-side-rendering.html http://emberjs.com/blog/2014/12/22/inside-fastboot-the-road-...
bsimpson 12y ago
1) Not every client on the Internet is a JavaScript-enabled web browser. Searchbots are the most obvious example of this. They can better understand semantic HTML markup than the random blob of JS most client-side apps are made up of. 2) Parsing and executing a JS-based app is a non-trivial task that requires CPU time. Serving ready-to-render HTML to underpowered clients (like mobile phones) can make your app appear more responsive (as users can read your content while the JS engine is initializing the dynamic bits).
bgentry 12y ago
Though you should read the blog post tomdale linked to in his reply, the short version of it is this: For many client side apps like Ember.js, a blank or mostly-blank HTML page is returned by the server. After the browser finishes loading the client-side app and all of its JavaScript, then that app is able to render the app's real content into the DOM. Sometimes that's fast, other times it's slow. The FastBoot feature is designed to pre-render the HTML page on the server, and then let Ember take over on the client side once all of its JavaScript has finished loading. So basically the server emulates enough of the browser to do the same rendering that the browser would have done, then serves that to the user so they more quickly see a fully rendered page. It helps performance, and also lets more primitive JS-free search crawlers & bots see a page that would otherwise only be rendered by JavaScript. Google's crawlers can handle JS apps now, but others may not.

4 ms·

Why is ember.js being ported to node? Could someone give me a little back story?

by dmak 12y ago

Why is ember.js being ported to node? Could someone give me a little back story?

tomdale 12y ago
We described our motivation in the previous blog post in this series: http://emberjs.com/blog/2014/12/22/inside-fastboot-the-road-to-server-side-rendering.html http://emberjs.com/blog/2014/12/22/inside-fastboot-the-road-...
bsimpson 12y ago
1) Not every client on the Internet is a JavaScript-enabled web browser. Searchbots are the most obvious example of this. They can better understand semantic HTML markup than the random blob of JS most client-side apps are made up of. 2) Parsing and executing a JS-based app is a non-trivial task that requires CPU time. Serving ready-to-render HTML to underpowered clients (like mobile phones) can make your app appear more responsive (as users can read your content while the JS engine is initializing the dynamic bits).
bgentry 12y ago
Though you should read the blog post tomdale linked to in his reply, the short version of it is this: For many client side apps like Ember.js, a blank or mostly-blank HTML page is returned by the server. After the browser finishes loading the client-side app and all of its JavaScript, then that app is able to render the app's real content into the DOM. Sometimes that's fast, other times it's slow. The FastBoot feature is designed to pre-render the HTML page on the server, and then let Ember take over on the client side once all of its JavaScript has finished loading. So basically the server emulates enough of the browser to do the same rendering that the browser would have done, then serves that to the user so they more quickly see a fully rendered page. It helps performance, and also lets more primitive JS-free search crawlers & bots see a page that would otherwise only be rendered by JavaScript. Google's crawlers can handle JS apps now, but others may not.