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.
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.
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.
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.
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.
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.
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 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.
I should restate: if someone started with backbone on a project, there's no reason to pull it out and restart with ember. It has its advantages for a certain type of project and a certain type of developer today.
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.
> for 95% of the use cases, you are better off sticking with jQuery or ...
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.
It depends. Are you doing single page apps? jQuery is awful advice. Are you doing internal 2007-style internal apps with only a small amount of interaction? I'd argue jQuery is a cost-effective way to get a project out.
I haven't figured out how to get a team who is "barely" conversant in javascript productive in an MVC framework just yet, myself.
It's not true. A lot of people are perfectly happy with Backbone.
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.
It all depends on what kind of app you're writing. If you're happy with whatever solution you're using then it's foolish to change just for the sake of change. However, I've known multiple developers who started with Backbone and then found that it wasn't able to meet their needs and then switched to Ember. Zendesk is one such example. The goals of Ember are actually very different from Backbone. Furthermore, living on the bleeding edge with others is better than living on your own bleeding edge by yourself with a ton of code that you rolled on your own.
Oh, sure. Changing libraries/frameworks in order to satisfy one's requirements -- or for quality reasons, or for any other good reasn -- is completely justified. It's the habit of chasing whatever is today's new hot thing that I dislike, and similarly, the habit of dismissing yesterday's favourite as being old hat.
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.
Thanks. I don't have time to watch the talk right now, but skimming through it, it sounds like a view layer like you describe could perceivably be bolted on top of Backbone, at least if one added support for attribute-level bindings?
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.
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!
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?
The guides are synced with the API now. But I feel like you essentially need to read every section before you can get a feel for how to put together an application.
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.
> 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.
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".
Amen. I know zilch about ember specifically. But this kind of thing is endemic in the tech world (even more so on the business side of things where people allocate budgets to line items like "docs").
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.
ember-data is a completely separate project that is still under heavy development. You can use ember without touching ember-data, and unless you are on the happy path of Rails with the active_model_serializers[0] gem, I would recommend not using ember-data.
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.
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...
66 comments
[ 3.3 ms ] story [ 148 ms ] threadFor 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-...
# http://emberjs.com/api/classes/Ember.Array.html
Link: http://net.tutsplus.com/tutorials/javascript-ajax/game-on-ba...
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.
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.
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
[1]: https://github.com/zendesk/ember-resource
[2]: https://github.com/cerebris/ember-rest
'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...