14 ms·

Ember.js 1.0 RC1 released

142 points by stevewilhelm 14y ago

phasevar 14y ago
If you write single-page web apps, you owe it to yourself to check out Ember.js. The learning curve is a little steep, but once you get up and running you can't beat it for a client side MVC.
- scotth 14y ago
  Can't beat it? It's good, but Angular.js is definitely a front-runner.
  - rxcfc 14y ago
    I think if we're going to start this debate that we need to substantiate the claims on both sides. This is probably not the ideal place for that debate, however.
    - ninetax 14y ago
      On the contrary, I'd love to hear the debate! If not here then where?
      - codygman 14y ago
        here: https://news.ycombinator.com/item?id=5230636 https://news.ycombinator.com/item?id=5230636
        ninetax 14y ago
        Ah, thank you very much.
  - camus 14y ago
    they are very differnt , DI is great but all the directive lifecycle pisses me off sometimes. and dirtychecking on huge collections? without a native Object.observe it is slow.
    - rxcfc 14y ago
      Things like this make me extremely wary of Angular's DI: http://www.alexrothenberg.com/2013/02/11/the-magic-behind-angularjs-dependency-injection.html http://www.alexrothenberg.com/2013/02/11/the-magic-behind-an...
    - wycats 14y ago
      For what it's worth, it's not clear how Object.observe will substantially improve the performance of large collections. For example, if you insert an item at position 0 of a 10,000 item array, Object.observe will publish a change for every item (since they are all moved one item down). It is then up to the receiver of those changes to reverse engineer what exactly happened (which is slow). What is needed is Array observers, which would notify the index of the change, number of items removed, and any items added (the `splice` signature). Ember emulates this, but by using a different API than the normal Array API. I hope that future extensions to Object.observe will support Array observation. As a member of TC39, I worked closely with several members of the Chrome team on Object.observe and hope to work with them again on an Array extension to the spec to make Array observation faster. I yearn for a future where Ember can get good performance without having to ask our users to use an alternative API.
      - wolfhumble 14y ago
        > I yearn for a future where Ember can get good performance without having to ask our users to use an alternative API. Could you explain what you mean by: ". . . ask our users to use an alternative API"? Thanks!
        sandstrom 14y ago
        I think he's referring to the get/set accessors (e.g. `myObject.set('foo', bar)` instead of `myObject.foo = bar`). Here are some resources: # http://emberjs.com/guides/object-model/classes-and-instances/ http://emberjs.com/guides/object-model/classes-and-instances... # http://jfire.io/blog/2012/04/19/why-ember-dot-js-doesnt-use-property-descriptors/ http://jfire.io/blog/2012/04/19/why-ember-dot-js-doesnt-use-... # http://emberjs.com/api/classes/Ember.Array.html http://emberjs.com/api/classes/Ember.Array.html
  - jetako 14y ago
    I chose Ember in part to make use of its sibling framework, ember-data. Is there a relational model abstraction that integrates well with Angular?
- tomjen3 14y ago
  MVC can be used to build websites, but I prefer something more like MVVM (which may be MS term, I don't know) so I would stick with Knockout.js
camus 14y ago
congrats , Ember.js is a great framework , definetly my first choice for writing complex web apps.
sahat 14y ago
There is an in-depth comparison of two frameworks: Backbone.js vs Ember.js. Link: http://net.tutsplus.com/tutorials/javascript-ajax/game-on-backbone-and-ember/ http://net.tutsplus.com/tutorials/javascript-ajax/game-on-ba...
- yiransheng 14y ago
  Another comparison from a while ago, which includes eight of the js mv* frameworks: http://blog.stevensanderson.com/2012/08/01/rich-javascript-applications-the-seven-frameworks-throne-of-js-2012/ http://blog.stevensanderson.com/2012/08/01/rich-javascript-a...
namank 14y ago
Why not YUI? I'm so confused at the proliferation of these JS frameworks where everyone literally keeps reinventing the wheel. Excellent as a learning exercise but other than that, what's the point? YUI has been around for so long compared to these. It's mature, it's under active development, very well documented, it has the option of including so many more things if you want, it's modularized,has a devcon every year, releases architectural videos every so often, has a dedicated CDN. Why do you still pick ember or backbone or ...?
- ebiester 14y ago
  Looking at todoMVC, YUI takes ~400 lines of code to do what Angular does in 135, ember does in ~160, jQuery does in ~160, and even Backbone does in ~350 (and is anyone starting a project with backbone today?). Backbone unpacked, however, is only about 900 lines without spaces and comments. How big is YUI? To be fair, the YUI version has more comments, but it's fundamentally harder to follow too, IMHO. Further, YUI did a poor job of getting tutorials out at the quality of those available today for backbone, ember, and angular. As such, I at least found no approachable way to really get a mental model without working on an existing YUI project with a mentor or reading through a lot of documentation. I had done a simple YUI proof of concept with YUI 2, and went, "this is more work than jQuery" and never went back. So people reinvented the wheel, but they made it better. I'm glad that Yahoo blazed the path, but I'm not convinced it's the better option today.
  - alistair77 14y ago
    LOCs aren't a great metric. I'm far more productive with Backbone than with JQuery alone and Angular offers a fundamentally different approach (stuff auto-magically just works) which is brilliant but isn't always easy to customize. I agree about YUI though ;-)
    - ebiester 14y ago
      I get your point about angular -- I tend to think it has a particular use case in mind and does really well for that one. However, my point was that backbone doesn't give you much more than plain javascript itself -- let's not expect to abstract everything away compared to one of the full service frameworks. YUI, however, is aiming to be a full service framework. What is the additional benefit? Now, it's possible that YUI would show itself closer in terms of LOC/complexity to the other frameworks in a larger application. But looking piece by piece, ember and angular just seem to do things more efficiently, more clearly than YUI. And that was my point when discussing LOC.
paullth 14y ago
Havent looked for several months, but the website/docs are really looking great/improved. Well done
tferris 14y ago
Anyone preferring Angular over Ember?
- intelekshual 14y ago
  Many, at least according to this thread: http://news.ycombinator.com/item?id=5230636 http://news.ycombinator.com/item?id=5230636
- prophetjohn 14y ago
  Our application is currently jQuery and vanilla JS managed with require.js. I recently led spikes investigating both Angular and Ember. I landed on Angular. I found Ember to try too hard to be Rails when JavaScript is not Ruby. If you've got experience with Rails, Ember would probably be familiar enough that bending JavaScript into that model would be okay. But I think Angular is more geared toward the strengths of JavaScript (and away from its weaknesses). It's also a different kind of framework. Rails is so popular that it's understandable for frameworks to want to follow along that model. But Angular takes a completely different approach, trying to extend HTML. Because of this, Angular apps are incredibly readable. Our UI guy who isn't an engineer was able to look at the HTML and understand exactly what the app was doing. I also found Angular to be easier to piecewise convert an existing project, since any arbitrary element can be your entire Angular app. This might be possible with Ember, also, but I wasn't able to easily figure out how since the documentation is weaker than Angular's. The biggest problem I had with Angular and our current infrastructure was using the patterns introduced by require.js since Angular has its own opinions about dependency management.
thefreeman 14y ago
I keep wanting to try Ember, but honestly, it drives me crazy every time. Why is there not a simple "quick start" that shows how to get it up and running. You have lots of good documentation but you skip over the most important part!
- seivan 14y ago
  This seems to go against what the ember core guys believe in http://twitter.com/trek/status/302811479135092736 http://twitter.com/trek/status/302811479135092736
  - wycats 14y ago
    O_O A quick start guide definitely does not "go against" what we believe in. At EmberCamp, we had a slide dedicated to improvements we would like to make to the documentation. The first bullet was "Getting Started". http://cl.ly/image/0i3i0X3Q0y3M/Image%202013.02.16%208:59:07%20AM.png http://cl.ly/image/0i3i0X3Q0y3M/Image%202013.02.16%208:59:07... We think we have significantly improved the documentation over the past few months, but know we still have a long way to go.
- tferris 14y ago
  > Why is there not a simple "quick start" that shows how to get it up and running This is what I love about Angular: just go to angularjs.org and right on the landing page you find excellent live code samples and videos guiding you gradually into Angular. Besides, Angular just feels much more intuitive.
- erikpukinskis 14y ago
  Yeah, I've tried to get into Ember a couple times now, and each time I end up ditching because of the documentation. It seemed sparse, and what document is up there seems like it's often out of date. Does anyone know if they've gotten the documentation (including the guides) synced with the API yet?
  - thefreeman 14y ago
darthdeus 14y ago
Ember is awesome, you are dumb if you're not using it.
cgcardona 14y ago
I was at Ember Camp yesterday and I took notes of most of the sessions which I've posted on my blog: 'Ember State of the Union' : http://cgcardona.github.com/2013/02/15/notes-from-the-ember-state-of-the-union-talk/ 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-in-action-talk/ http://cgcardona.github.com/2013/02/15/notes-from-the-ember-... 'UI Patterns' : http://cgcardona.github.com/2013/02/15/notes-from-the-ui-patterns-talk/ 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-contributing-to-ember-session/ http://cgcardona.github.com/2013/02/15/notes-from-the-contri... 'Performance Talk' : http://cgcardona.github.com/2013/02/15/notes-from-the-performance-talk-session/ http://cgcardona.github.com/2013/02/15/notes-from-the-perfor... 'Testing Ember Apps' : http://cgcardona.github.com/2013/02/15/notes-from-the-testing-ember-apps-session/ 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-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-more-from-tooling-session/ 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-optimizing-your-api-for-ember-data-session/ http://cgcardona.github.com/2013/02/15/notes-from-the-optimi... 'ClientSideValidations for Ember' : http://cgcardona.github.com/2013/02/15/notes-from-the-clientsidevalidations-for-ember-session/ 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: [1] http://semver.org/ http://semver.org/ [2] http://emberjs.com/api/ http://emberjs.com/api/ [3] http://emberjs.com/guides/ http://emberjs.com/guides/ [4] http://emberjs.com/guides/routing/ http://emberjs.com/guides/routing/ [5] https://www.youtube.com/watch?v=hod-KX81i7s https://www.youtube.com/watch?v=hod-KX81i7s [6] http://www.w3.org/TR/2010/WD-html5-20100624/acknowledgements.html#acknowledgements http://www.w3.org/TR/2010/WD-html5-20100624/acknowledgements... [7] http://cgcardona.github.com/2013/02/15/playing-around-with-the-ember-inspector/ http://cgcardona.github.com/2013/02/15/playing-around-with-t... [8] http://www.youtube.com/user/wycats/videos http://www.youtube.com/user/wycats/videos

142 points by stevewilhelm 14y ago

If you write single-page web apps, you owe it to yourself to check out Ember.js. The learning curve is a little steep, but once you get up and running you can't beat it for a client side MVC.

scotth 14y ago
Can't beat it? It's good, but Angular.js is definitely a front-runner.
- rxcfc 14y ago
  I think if we're going to start this debate that we need to substantiate the claims on both sides. This is probably not the ideal place for that debate, however.
  - ninetax 14y ago
    On the contrary, I'd love to hear the debate! If not here then where?
    - codygman 14y ago
      here: https://news.ycombinator.com/item?id=5230636 https://news.ycombinator.com/item?id=5230636
      - ninetax 14y ago
        Ah, thank you very much.
- camus 14y ago
  they are very differnt , DI is great but all the directive lifecycle pisses me off sometimes. and dirtychecking on huge collections? without a native Object.observe it is slow.
  - rxcfc 14y ago
    Things like this make me extremely wary of Angular's DI: http://www.alexrothenberg.com/2013/02/11/the-magic-behind-angularjs-dependency-injection.html http://www.alexrothenberg.com/2013/02/11/the-magic-behind-an...
  - wycats 14y ago
    For what it's worth, it's not clear how Object.observe will substantially improve the performance of large collections. For example, if you insert an item at position 0 of a 10,000 item array, Object.observe will publish a change for every item (since they are all moved one item down). It is then up to the receiver of those changes to reverse engineer what exactly happened (which is slow). What is needed is Array observers, which would notify the index of the change, number of items removed, and any items added (the `splice` signature). Ember emulates this, but by using a different API than the normal Array API. I hope that future extensions to Object.observe will support Array observation. As a member of TC39, I worked closely with several members of the Chrome team on Object.observe and hope to work with them again on an Array extension to the spec to make Array observation faster. I yearn for a future where Ember can get good performance without having to ask our users to use an alternative API.
    - wolfhumble 14y ago
      > I yearn for a future where Ember can get good performance without having to ask our users to use an alternative API. Could you explain what you mean by: ". . . ask our users to use an alternative API"? Thanks!
      - sandstrom 14y ago
        I think he's referring to the get/set accessors (e.g. `myObject.set('foo', bar)` instead of `myObject.foo = bar`). Here are some resources: # http://emberjs.com/guides/object-model/classes-and-instances/ http://emberjs.com/guides/object-model/classes-and-instances... # http://jfire.io/blog/2012/04/19/why-ember-dot-js-doesnt-use-property-descriptors/ http://jfire.io/blog/2012/04/19/why-ember-dot-js-doesnt-use-... # http://emberjs.com/api/classes/Ember.Array.html http://emberjs.com/api/classes/Ember.Array.html
- jetako 14y ago
  I chose Ember in part to make use of its sibling framework, ember-data. Is there a relational model abstraction that integrates well with Angular?
tomjen3 14y ago
MVC can be used to build websites, but I prefer something more like MVVM (which may be MS term, I don't know) so I would stick with Knockout.js

camus 14y ago

congrats , Ember.js is a great framework , definetly my first choice for writing complex web apps.

sahat 14y ago

There is an in-depth comparison of two frameworks: Backbone.js vs Ember.js. Link: http://net.tutsplus.com/tutorials/javascript-ajax/game-on-backbone-and-ember/ http://net.tutsplus.com/tutorials/javascript-ajax/game-on-ba...

yiransheng 14y ago
Another comparison from a while ago, which includes eight of the js mv* frameworks: http://blog.stevensanderson.com/2012/08/01/rich-javascript-applications-the-seven-frameworks-throne-of-js-2012/ http://blog.stevensanderson.com/2012/08/01/rich-javascript-a...

namank 14y ago

Why not YUI? I'm so confused at the proliferation of these JS frameworks where everyone literally keeps reinventing the wheel. Excellent as a learning exercise but other than that, what's the point? YUI has been around for so long compared to these. It's mature, it's under active development, very well documented, it has the option of including so many more things if you want, it's modularized,has a devcon every year, releases architectural videos every so often, has a dedicated CDN. Why do you still pick ember or backbone or ...?

ebiester 14y ago
Looking at todoMVC, YUI takes ~400 lines of code to do what Angular does in 135, ember does in ~160, jQuery does in ~160, and even Backbone does in ~350 (and is anyone starting a project with backbone today?). Backbone unpacked, however, is only about 900 lines without spaces and comments. How big is YUI? To be fair, the YUI version has more comments, but it's fundamentally harder to follow too, IMHO. Further, YUI did a poor job of getting tutorials out at the quality of those available today for backbone, ember, and angular. As such, I at least found no approachable way to really get a mental model without working on an existing YUI project with a mentor or reading through a lot of documentation. I had done a simple YUI proof of concept with YUI 2, and went, "this is more work than jQuery" and never went back. So people reinvented the wheel, but they made it better. I'm glad that Yahoo blazed the path, but I'm not convinced it's the better option today.
- alistair77 14y ago
  LOCs aren't a great metric. I'm far more productive with Backbone than with JQuery alone and Angular offers a fundamentally different approach (stuff auto-magically just works) which is brilliant but isn't always easy to customize. I agree about YUI though ;-)
  - ebiester 14y ago
    I get your point about angular -- I tend to think it has a particular use case in mind and does really well for that one. However, my point was that backbone doesn't give you much more than plain javascript itself -- let's not expect to abstract everything away compared to one of the full service frameworks. YUI, however, is aiming to be a full service framework. What is the additional benefit? Now, it's possible that YUI would show itself closer in terms of LOC/complexity to the other frameworks in a larger application. But looking piece by piece, ember and angular just seem to do things more efficiently, more clearly than YUI. And that was my point when discussing LOC.

paullth 14y ago

Havent looked for several months, but the website/docs are really looking great/improved. Well done

tferris 14y ago

Anyone preferring Angular over Ember?

intelekshual 14y ago
Many, at least according to this thread: http://news.ycombinator.com/item?id=5230636 http://news.ycombinator.com/item?id=5230636
prophetjohn 14y ago
Our application is currently jQuery and vanilla JS managed with require.js. I recently led spikes investigating both Angular and Ember. I landed on Angular. I found Ember to try too hard to be Rails when JavaScript is not Ruby. If you've got experience with Rails, Ember would probably be familiar enough that bending JavaScript into that model would be okay. But I think Angular is more geared toward the strengths of JavaScript (and away from its weaknesses). It's also a different kind of framework. Rails is so popular that it's understandable for frameworks to want to follow along that model. But Angular takes a completely different approach, trying to extend HTML. Because of this, Angular apps are incredibly readable. Our UI guy who isn't an engineer was able to look at the HTML and understand exactly what the app was doing. I also found Angular to be easier to piecewise convert an existing project, since any arbitrary element can be your entire Angular app. This might be possible with Ember, also, but I wasn't able to easily figure out how since the documentation is weaker than Angular's. The biggest problem I had with Angular and our current infrastructure was using the patterns introduced by require.js since Angular has its own opinions about dependency management.

thefreeman 14y ago

I keep wanting to try Ember, but honestly, it drives me crazy every time. Why is there not a simple "quick start" that shows how to get it up and running. You have lots of good documentation but you skip over the most important part!

seivan 14y ago
This seems to go against what the ember core guys believe in http://twitter.com/trek/status/302811479135092736 http://twitter.com/trek/status/302811479135092736
- wycats 14y ago
  O_O A quick start guide definitely does not "go against" what we believe in. At EmberCamp, we had a slide dedicated to improvements we would like to make to the documentation. The first bullet was "Getting Started". http://cl.ly/image/0i3i0X3Q0y3M/Image%202013.02.16%208:59:07%20AM.png http://cl.ly/image/0i3i0X3Q0y3M/Image%202013.02.16%208:59:07... We think we have significantly improved the documentation over the past few months, but know we still have a long way to go.
tferris 14y ago
> Why is there not a simple "quick start" that shows how to get it up and running This is what I love about Angular: just go to angularjs.org and right on the landing page you find excellent live code samples and videos guiding you gradually into Angular. Besides, Angular just feels much more intuitive.
erikpukinskis 14y ago
Yeah, I've tried to get into Ember a couple times now, and each time I end up ditching because of the documentation. It seemed sparse, and what document is up there seems like it's often out of date. Does anyone know if they've gotten the documentation (including the guides) synced with the API yet?
- thefreeman 14y ago

darthdeus 14y ago

Ember is awesome, you are dumb if you're not using it.

cgcardona 14y ago

I was at Ember Camp yesterday and I took notes of most of the sessions which I've posted on my blog: 'Ember State of the Union' : http://cgcardona.github.com/2013/02/15/notes-from-the-ember-state-of-the-union-talk/ 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-in-action-talk/ http://cgcardona.github.com/2013/02/15/notes-from-the-ember-... 'UI Patterns' : http://cgcardona.github.com/2013/02/15/notes-from-the-ui-patterns-talk/ 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-contributing-to-ember-session/ http://cgcardona.github.com/2013/02/15/notes-from-the-contri... 'Performance Talk' : http://cgcardona.github.com/2013/02/15/notes-from-the-performance-talk-session/ http://cgcardona.github.com/2013/02/15/notes-from-the-perfor... 'Testing Ember Apps' : http://cgcardona.github.com/2013/02/15/notes-from-the-testing-ember-apps-session/ 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-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-more-from-tooling-session/ 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-optimizing-your-api-for-ember-data-session/ http://cgcardona.github.com/2013/02/15/notes-from-the-optimi... 'ClientSideValidations for Ember' : http://cgcardona.github.com/2013/02/15/notes-from-the-clientsidevalidations-for-ember-session/ 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: [1] http://semver.org/ http://semver.org/ [2] http://emberjs.com/api/ http://emberjs.com/api/ [3] http://emberjs.com/guides/ http://emberjs.com/guides/ [4] http://emberjs.com/guides/routing/ http://emberjs.com/guides/routing/ [5] https://www.youtube.com/watch?v=hod-KX81i7s https://www.youtube.com/watch?v=hod-KX81i7s [6] http://www.w3.org/TR/2010/WD-html5-20100624/acknowledgements.html#acknowledgements http://www.w3.org/TR/2010/WD-html5-20100624/acknowledgements... [7] http://cgcardona.github.com/2013/02/15/playing-around-with-the-ember-inspector/ http://cgcardona.github.com/2013/02/15/playing-around-with-t... [8] http://www.youtube.com/user/wycats/videos http://www.youtube.com/user/wycats/videos