Server and client side sharing code for faster rendering / response

1

I first heard about emberjs from a video presentation by AirBnB, and more about their code sharing between client side and server side JS. I am new to JS and web stuff.

JS web app with rich (and fat) client it is quite slow.

They discussed sharing client side and server side javascript code for faster page rendering using Rendr /w Backbone.js.

The video presentation was done in Feb 2013.

I like to know if emberjs has similar capabilities where same JS code resides in client and server.

Thanks.

2 Likes
2

You can run any Javascript code on both server and client, including Ember. There are definitely people using Ember that way.

Ember actually offers two different levels of server-side runnability. There is a dedicated, DOM-less build of the Ember core runtime that makes it easy to execute all your application & model logic on the server side, without depending on a browser-like environment. Alternatively, you can use the full Ember build on the server side with a DOM implementation like PhantomJS to render complete pages.

Regardless of the framework you choose, the general tooling & ecosystem support for managing dependencies across both server and client is pretty poor. I use Browserify and it’s ok, but it is far from mature software and it took a lot of tweaking to get everything (including various 3rd-party dependencies) to play nicely together.

If you’re “new to JS and web stuff”, you may want to start with a more typical Ember or Backbone app that is all rendered on the client, and worry later about moving some rendering to the server if you need to. I’m not convinced that there’s a major performance reason to do it, most of the time. And one of the reasons Rendr exists (supporting deep-links) doesn’t apply to Ember, because Ember apps always support deep-links, even when rendering everything in the browser.

3

" And one of the reasons Rendr exists (supporting deep-links) doesn’t apply to Ember, because Ember apps always support deep-links, even when rendering everything in the browser."

First I do not understand the reasoning. Sorry. Rendr supporting deep link and Emberjs also supporting deep links. So they both have the same capabilities in this support. The “…reasons Rendr exists …doesn’t apply to ember, …” does not make sense to me.

Please also explain what do you mean by deep-links since any link is just another url.

Thanks.

4

I’m contrasting Backbone with Ember.

Ember does a lot of work for you to make sure your application can always gracefully start no matter what URL the user enters. Backbone leaves more of that work up to the developer to do by hand. Rendr is an attempt to automate some of it, bringing Backbone closer to Ember’s level of automation.

5

Hi Edward @ef4, would you mind linking to the dedicated DOM-less build of the Ember core that you refer to, please? I’ve had a quick look around but haven’t found it. If you know of any links to projects implemented with it, that would also be very interesting.

Thanks!

6

The DOM-less version gets built automatically whenever Ember is built from source. It’s the file called ember-runtime.js.

It’s not distributed pre-built on the website, unfortunately. But building Ember is pretty easy.

1 Like
7

Ah, I see. Thanks.

There are modules called ember-runtime-node and ember-runtime on npm, but they’re one and two years old, respectively! @stefan @wycats I gather from discussion in #697, #771 & #1434 that there are still some barriers to publishing up-to-date versions on npm?