I'm sad that the on-site docs are still inferior compared to the in-code comment docs. For example, the on-site docs hardly mention the built-in state manager, but they're very thoroughly documented in the code [1]. Many people (myself included) people will usually resort to searching Google before looking in the code when trying to figure out how to do something.
Ember team, any insight as to what's being done to rectify this, or why this is?
The documentation also completely ignores a number of objects and properties available in the framework which means that you either have to scan the source code or read through questions on www.stackoverflow.com with the [emberjs] tag.
It can be quite frustrating while you're still learning the framework.
(Their description of a framework for making ambitious web apps is a bit vague imho and i don't want to spend 15 mins reading docs about something that may not be of any use to me at all.)
It has a "Railsier" "Convention over Configuration" type ethos. Certainly more opinionated, if nothing else, where as Backbone is more of an empty canvas & instruments to cover it.
There are technical difference as well, but I think that's less of an issue.
I'd say Backbone is a library. Ember is more of a framework.
For example, create 100 todos in their demo app, then check the select all button. Notice the instance response. This is because Ember consolidate actions and executes them once at the end of the event loop. This is not possible in Backbone without basically reimplementing that functionality.
I believe this is what they mean by "ambitious," because it's designed around issues that will arise in an ambitious Backbone project.
Backbone:Sinatra as Ember:Rails for a rough analogy.
The documentation is underwhelming, from a get-up-and-running POV ... protip for authors of new libraries etc. I should be able to cut and paste your code and have it just work right away.
If you don't add
var MyApp = Em.Application.create();
to the examples in the docs page the code simply won't work.
It's a bit odd that the main example on the home page references an object called DS on 8 of 10 lines, but DS is never referenced elsewhere in the documentation.
I know from prior exploration at their github account that DS stands for "data store" but I still think it's pretty weird that searching for "DS" on the docs page brings up nothing.
I've used ember for a little bit. DS is the root namespace of ember-data (https://github.com/emberjs/data), which if you look at the github is pretty clearly still in Alpha and not recommended for production use. I've asked on IRC but haven't been able to get a straight answer out of anyone as to whether ember-data is ready for mass usage or not...
edit: kept trying on IRC and got an answer. Basically Tom Dale said that if you're using rails and ember you should be using ember-data now - should also be using Active Model Serializers gem too.
Thanks for the guides, I especially like the comparison to Rails. One tiny note, I noticed a few spelling errors briefly browsing through. "recieve" and "appropirate" on http://emberjs.com/guides/ember_mvc/
On a more personal note, it would be great if someone could compare this with meteor.js (which recently got featured on HN)? I mean a brief comparison would be really great..without having to dig up the docs in detail..
Meteor covers the client and the server, and tries to hide the different roles they play and how they communicate with each other. Ember is purely a client-side MVC framework, server's up to you (besides some conventions).
On a more personal note, it would be great if someone could compare this with spine.js (which recently got featured on HN)? I mean a brief comparison would be really great..without having to dig up the docs in detail..
Ember is probably more comparable to something like AngularJS (But I don't now 100% because I've never used Ember, just looked at their site for a few minutes). Backbone and Spine are much lighter-weight infrastructure frameworks.
Ember is a much more complicated than spine.js. I recently did work with Backbone.js and Ember.js and reviewed the documentation for Spine.js. Ember has a lot of magic that's really awesome, but it can be difficult to learn how to work within the framework properly.
What makes me sad about js client-side frameworks and Ember.js in particular is that they are still only client-side. Nevermind the code duplication, but the bare fact that I have to actually think about how to construct my server so that it works with Ember.js. The reason why people hooked up on Rails so quickly is because it solved all of their problems, not just one. Novices are not going to try Ember.js just because it works on the client, while having no idea about the server-side.
There are some nice new tools emerging to solve this problem, but don't force front end devs into an entirely new platform. One of my projects is an open source server (https://github.com/deployd/deployd) that's totally un-opinionated on the front end, but makes it really easy to add robust backends to client apps.
What I'm saying is that a tool for webdev that wants to stand any chance of becoming popular must be able say to developers: here's the familiar MVC structure, you write your models, you create your views (hopefully out of set of widgets that are highly replaceable/customizable at any moment), we take care of talking to the server, saving your models to the storage and syncing between different instances of an app. Sure, there are problems to solve here, but since everybody does it their own way at the moment, I don't see no reason why we can't have a framework that solves them for you.
Comparing it to Backbone, feels to me that Ember uses a notation that is closer to what I already know about Javascript, for example all the object methods and prototype class emulation. I was going through the API and everything seemed like it made sense right away. The only thing I wish the site had is more examples with bi-directional bindings.
How mature are the ember community's various supporting libraries and boilerplate builds? This kind of bothered me:
http://emberjs.com/documentation/#toc_getting-started
>> If your needs are simple or you're interested in just playing around, you can download the Ember.js Starter Kit. The Starter Kit is based on HTML5 Boilerplate and does not require any build tools or other dependencies...For larger apps, you may want to consider using Ruby on Rails. Rails helps you manage your source code and other assets, while also providing the REST API that your application will talk to.
(not saying that backbone et. al have better boilerplate builders. Just that hopefully there's a medium ground between HTML5 templates and RoR, the latter which I hope to mostly avoid through the use of JS frameworks)
Yea, I would not recommend using Rails for this purpose. Middleman (http://middlemanapp.com) is the best parts of Rails asset packaging in a more lightweight package.
We just started playing with this, it seems like a great alternative to backbone for those who want a bit more of the common stuff done for you (esp data binding).
Backbone is a great starting point if you have strong opinions and want to own it from the ground up.
It's fun to look at this new site in the context of the progression in the various iterations of the SproutCore saga over the years:
http://web.archive.org/web/20081003190606/http://www.sproutc...
http://web.archive.org/web/20110211051741/http://www.sproutc...
http://sproutcore.com/
http://emberjs.com/