Ember.js 1.0 RC1 released
emberjs.com
emberjs.com
'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...
Does anyone know if they've gotten the documentation (including the guides) synced with the API yet?
There was a quick start project I found at one point which looked like what I wanted, but it was not in sync with the latest guides / api so I couldn't use it. Not sure if that has been updated now, but there is no obvious link that I know of and I don't remember where I found it.
edit: here's the quick start project I was talking about. https://github.com/emberjs/starter-kit/ Unfortunately it doesn't look to be up to date.
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.
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...
We think we have significantly improved the documentation over the past few months, but know we still have a long way to go.
I didn't really get rolling with Ember until I started to piece it together at a high level looking at Discourse's source.
Seriously, if your product is a new API, don't even think about writing reference documentation until you have a 2-page "birds eye view" document that explains your jargon and metaphors to a new user. Without that any reference documentation is going to be useless.
I haven't seen it, but based on the screencasts I have purchased, it's probably worth the $12
You can roll your own light-weight layer, and Ember's object system will give you lots of rich functionality. There is also ember-resource[1] and ember-rest[2] if you want something a little less hand-crafted.
[0]: https://github.com/rails-api/active_model_serializers
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 ...?
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.
I agree about YUI though ;-)
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.
Coincidentally, I wrote about earlier this week: http://blog.jerodsanto.net/2013/02/cloc-counts-lines-of-code...
If you like minimal frameworks, like to make your own design decisions and want to build your own framework on top of a library, backbone is great.
If you are just looking for a minimal subset of MVC because you're doing some high-concept app that doesn't fit into the standard web application paradigm, it's worth looking at backbone.
Most importantly, if you're retrofitting an existing application, backbone will be invaluable for years.
The ideas behind it are solid and relevant today and it's not a bad idea to use it. I just believe that if you are starting a web application today, for 95% of the use cases, you are better off sticking with jQuery or moving to Ember, Knockout or Angular.
That isn't to disparage any of the other libraries and frameworks, though.
This is terrible advice. If you can't tell the difference between a procedural app full of jQuery callbacks and a an app modularized with Backbone objects, then I don't think you have had real experience writing apps with either of these libraries.
I haven't figured out how to get a team who is "barely" conversant in javascript productive in an MVC framework just yet, myself.
This "X is old hat, use Y" phenomenon of "hype recycling" is part of a cultural problem that seems particularly endemic to the startup world. There is a lifecycle of "bleeding edge" to "mature" to "abandoned" that never lets up. There is always a newly-hyped library or framework or methodology that's trying to shift people's attention; and rather than refining and evolving the existing stuff into stability and maturity, many devs start new, wobbly, immature projects. But the bleeding edge is fickle, and when the dust settles there are some remaining competitors, but then suddenly the dust rises again and you're urged to abandon everything because the new stuff is in a separate programming language, so everything else is now incompatible; so the cycle goes. It results in a lot of work, and I like the competition and sheer energy of a developer community fired up about something, but I believe there is also a lot of work wasted.
Sometimes I wish software developers were more like engineers, and that people slowed down a bit. As one gets older, one gets to value maturity over novelty, and to see the importance of backwards compatibility, transition paths and careful releasing.
As for Ember, I'm sure Ember is wonderful. I still haven't figured out what design decisions in Backbone drove develpers to create Ember, but I'm not qualified to question it. Either way, Ember and Backbone are both trying to solve the same basic thing: Providing an MVC framework for JavaScript, mostly focused on the browser. As I understand it, Ember wants to be a more complete toolkit than Backbone, which is very simple and minimalistic and leaves things like templating to other libs.
What is interesting is that Yehuda Katz was also behind Merb, which in my mind is a good example of a gratuitous project; Merb was someone reinventing Rails with the goal of being perhaps 10% better than Rails in the areas of performance and modalarity, while at the same time completely incompatible, and a lot of people jumped on the bandwagon. As it turned out, the developers decided to reimplement Merb's conceptual improvements back into Rails and shut the project down.
Again, I'm not qualified to critique Ember, but the Ember/Backbone competition certainly looks, on the surface, a lot like the Merb/Rails situation back in the day. I would love to hear more about why the devs decided to create Ember and not evolve Backbone. If the Backbone devs did not want to go in Ember's direction, that is of course a perfectly acceptable (if unfortunate) reason to start over.
Both Ember and Backbone depend on jQuery, incidentally. Leveraging popular libraries is an important feature of any framework.
Link: http://net.tutsplus.com/tutorials/javascript-ajax/game-on-ba...
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.
Could you explain what you mean by: ". . . ask our users to use an alternative API"?
Thanks!
Here are some resources:
# http://emberjs.com/guides/object-model/classes-and-instances...
# http://jfire.io/blog/2012/04/19/why-ember-dot-js-doesnt-use-...
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.