Does anyone know what the difference is between Ember.js and Ember-runtime.js in the new builds section (aside from the obvious size difference)? Briefly looking at the source… does it remove (maybe partially) the jQuery dependency?
Ember is built up of many different packages. You can see the full list of them here.
The following assets are generated upon a successful build:
ember.js- This is the full development build. It includes all (or nearly all) of the packages.
ember.prod.js- The production files remove any debug statements and/or assertions. It includes all of the packages except:
ember.min.js- This is basically a minified version of
ember-runtime- This is a much limited subset of the available packages. It only includes:
Does that answer your question?
Ah, that is very useful and I was asking myself the same thing today.
So what is the use-case fro ember-runtime? When should/can it be used?
@GlobeCoder I was coming here to ask the same thing.It appears you can just use
Ember.Object just a generalized Object which comes packed with observers, sane accessors, computed properties, and a slew of polyfills and connivence methods. So if you want to use just those types of features without having to worry about how Ember does MVC, jQuery, and the hard dependency on Handlebars you can do so. These is at least what I gathered.
Ember.Controller is in ember-runtime but since all of it’s methods and properties are just inherited from
Ember.Object it is just a namespace. I think this is what the purpose is but I would like someone from the core team to respond.
I know this is an old topic, but I happened to notice it so here’s your answer:
ember-runtime exists so that you can use Ember objects in environments like NodeJS where there is no DOM. I use it because I have model-layer logic that takes advantage of things like computed properties, and sometimes it’s nice to be able to access your models on the server.