'Ember State of the Union' : http://cgcardona.github.com/2013/02/15/notes-from-the-ember-...
'Ember in Action' : http://cgcardona.github.com/2013/02/15/notes-from-the-ember-...
'UI Patterns' : http://cgcardona.github.com/2013/02/15/notes-from-the-ui-pat...
'Contributing to Ember' : http://cgcardona.github.com/2013/02/15/notes-from-the-contri...
'Performance Talk' : http://cgcardona.github.com/2013/02/15/notes-from-the-perfor...
'Testing Ember Apps' : http://cgcardona.github.com/2013/02/15/notes-from-the-testin...
'Ember Data Talk' : http://cgcardona.github.com/2013/02/15/notes-from-the-ember-...
'Expect More from Tooling' : http://cgcardona.github.com/2013/02/15/notes-from-the-expect...
'Optimizing Your API for Ember Data' : http://cgcardona.github.com/2013/02/15/notes-from-the-optimi...
'ClientSideValidations for Ember' : http://cgcardona.github.com/2013/02/15/notes-from-the-client...
There seem to be a few general themes going around on this thread and I'd like to address them all:
1. Ember docs aren't up to date
As this thread notes yesterday Ember.js Version: v1.0.0-rc.1 was released. This is the first release candidate of Ember.js 1.0. As with any project (and as was noted by Jeff Atwood in the Ember Camp keynote) you can expect the APIs to be fluid until version 1.0 at which point they become quite stable. From what I understand any further release candidates are going to be about bug fixes and not API changes so at this point you can basically consider the APIs locked in for version 1.0.0.
Along those lines the Ember Core team has announced that Ember.js is going to follow semantic versioning[1] which means that there won't be any major API changes in minor releases.
During the 'Ember State of the Union' session yesterday there was an acknowledgment of the quick start and docs stuff. They announced that yes there will be an effort to create 'The Best Quickstart EVAR™'
They also announced that the Ember Core Team will keep an eye out for docs that are out of date and will ask the authors to put a little disclaimer at the top of the post which says that the code isn't the 1.0.0 API.
Finally in the context of talking about bringing more people onto the Ember Core team they mentioned that seeing someone passionate about the community and documentation could be a reason to be considered.
All these things left me with the impression that documentation and quickly/easily onramping people to the framework is incredibly important to the Core Team and the community.
Also it really is worth mentioning that the API docs[2] and Guides[3] are just github repos. If you see something that is incorrect or there is something that just isn't there please clone the repo and add/fix it. That's a great way to become a contributor to the project and help other people not run into the same issue that you did.
2. Ember vs Angular vs Backbone vs Knockout vs jQuery (did I miss anybody)
First to be fair let me say that I don't really have experience with angular, backbone, or knockout. I've checked them out and read some docs but I haven't really dug in.
My thoughts are that it's still the early days of such rich client side applications. The teams behind all of these projects are incredibly smart and /me thinks that there is much to be learned from each one.
As with any toolset you pick what works best for the problem your trying to solve, what leverages your existing skills while pushing you to learn something new, what has the most thriving community, and yes what is easiest to onramp.
3. Why would you use Ember?
When it came time for me to wrap my head around an MVC (or MVC-like) client side framework I decided to check out Ember.js first because I like the work that Yehuda Katz and Tom Dale had done in earlier projects (jQuery, Rails, W3C TAG, SproutCore). I immediately found that I liked Ember.js for several reasons:
* Convention over configuration—-If you come from Rails this one is a no brainer. There are some things that are done pretty much always. Why bother setting that stuff up? It should just work and for the most part it does.
* Router--Ember's notion of mapping every potential state of your app to a url[4]. Actively acknowledging that URLs are a strength of the web platform which allows us to share deep state of our app.
* This video introduction by Tom[5]--I recently had the realization that frameworks such as Cocoa are amazing because of the building blocks that they provide. I also realized that the web platform has all these amazing primitives but there was just no framework that built on top of it. In that video Tom says that Ember.js is meant to be like Cocoa for web development and that immediately struck a chord with me.
* Client side MVC FTW!--Once upon a time I was a member of the W3C HTML5 Working Group and an acknowledged contributor to the HTML5 spec[6]. Early on I (like many others) saw the potential of HTML5 and it makes me happy to see a framework built which handles so much of the app on the client side with Javascript and HTML5.
There is one tool I'd like to mention--the Ember Inspector[7]. It is a really great Chrome extension which adds an `Ember` tab to your dev tools. This let you get Ember specific javascript output and visual feedback when hovering over controllers/templates.
It's still pre-release but I've played around with it and my impression is that as it matures it's going to become an indispensable tool for the Ember.js developer.
Links:
[3] http://emberjs.com/guides/
[4] http://emberjs.com/guides/routing/
[5] https://www.youtube.com/watch?v=hod-KX81i7s
[6] http://www.w3.org/TR/2010/WD-html5-20100624/acknowledgements...
[7] http://cgcardona.github.com/2013/02/15/playing-around-with-t...