Ember.js or Angular.js?
Which is best overall? Which is best in certain common situations? Which is most enjoyable? Which is more maintainable? Why not ember? Why not angular? What are common "gotchas" for each framework?
103 comments
I've used SC before it was Ember, hated it.
I've been using Angular for a few weeks - LOVE it. It's amazingly quick to build great stuff.
I was on a Skype call with my UX designer the other day talking about how we should display a permissions list: we sent back and forwards a few different sketches, by the time we finished discussing the final sketch I had reimplemented the modal as a radio button, disabling and hiding the checkboxes when the first radio was clicked... at which point I thought, "shit, that would have usually taken 15 minutes to do".
I was on a Skype call with my UX designer the other day talking about how we should display a permissions list: we sent back and forwards a few different sketches, by the time we finished discussing the final sketch I had reimplemented the modal as a radio button, disabling and hiding the checkboxes when the first radio was clicked... at which point I thought, "shit, that would have usually taken 15 minutes to do".
Ember has changed quite a bit from its SC roots. I would probably use Angular over SC myself, but if given the choice to use Ember would much rather use it.
I think deciding on this will be hard and frankly subjective. My suggestion is that you try both for a small project and decide for yourself what makes you feel at home. It should not take more than a couple of days to assess it yourself.
As for me, I decided to go with Ember.js. To be frank the final decision was between Ember and Angular (over all other frameworks) and I felt that getting past the learning curve of Ember, it made me comfortable. Most importantly both are close/past the 1.0 release.
If you do choose Ember, I would recommend the following:
- Watch the peepcode's emberjs cast https://peepcode.com/products/emberjs (and code it up)
- Go through the Emberjs documentation on the site, though very likely you will not know how to build a big app. It is still necessary to hone your fundamentals.
- The 1.0 RC1 that was released yesterday has dependency injection, if that matters to you. My opinion is to just code as little as possible and prefer to stick with the framework's conventions (i.e not use DI).
- Use a sound build tool. I don't have Ruby/RoR background and so preferred to use Brunch.io (http://brunch.io/) - Nodejs pipline. They have a Emberjs skeleton available to get started quickly - https://github.com/icholy/ember-brunch. I believe there is a rake pipeline tool for Ruby/RoR folks as well.
- Ryan Florence recently released a scaffolding/build tool Emberjs - https://github.com/rpflorence/ember-tools. I use this to develop my skeletons and use it with my Brunch.IO setup. It is a good place to start and get past the learning curve. The tool will probably become the go to place for building Emberjs apps sometime later.
I am sure you will find similar tools for Angular.js but I think you just have to try something simple in both and find out for yourself what makes you comfortable with these opinionated frameworks :).
As for me, I decided to go with Ember.js. To be frank the final decision was between Ember and Angular (over all other frameworks) and I felt that getting past the learning curve of Ember, it made me comfortable. Most importantly both are close/past the 1.0 release.
If you do choose Ember, I would recommend the following:
- Watch the peepcode's emberjs cast https://peepcode.com/products/emberjs (and code it up)
- Go through the Emberjs documentation on the site, though very likely you will not know how to build a big app. It is still necessary to hone your fundamentals.
- The 1.0 RC1 that was released yesterday has dependency injection, if that matters to you. My opinion is to just code as little as possible and prefer to stick with the framework's conventions (i.e not use DI).
- Use a sound build tool. I don't have Ruby/RoR background and so preferred to use Brunch.io (http://brunch.io/) - Nodejs pipline. They have a Emberjs skeleton available to get started quickly - https://github.com/icholy/ember-brunch. I believe there is a rake pipeline tool for Ruby/RoR folks as well.
- Ryan Florence recently released a scaffolding/build tool Emberjs - https://github.com/rpflorence/ember-tools. I use this to develop my skeletons and use it with my Brunch.IO setup. It is a good place to start and get past the learning curve. The tool will probably become the go to place for building Emberjs apps sometime later.
I am sure you will find similar tools for Angular.js but I think you just have to try something simple in both and find out for yourself what makes you comfortable with these opinionated frameworks :).
Your comment is among the sanest in this thread, thanks.
The single most important thing you said is: "It should not take more than a couple of days to assess it yourself."
If you are a serious web developer, you should know the basics of both, they are both great in their own way. Every project have its own requirements and sometimes both libraries will not be suitable, sometimes you will want to go with backbone or something else.
I would recommend going to peepcode.com and egghead.io before jumping into the docs.
I will just leave this here and bail out: I have a hunch ember.js will become a default in RoR by the end of this year.
The single most important thing you said is: "It should not take more than a couple of days to assess it yourself."
If you are a serious web developer, you should know the basics of both, they are both great in their own way. Every project have its own requirements and sometimes both libraries will not be suitable, sometimes you will want to go with backbone or something else.
I would recommend going to peepcode.com and egghead.io before jumping into the docs.
I will just leave this here and bail out: I have a hunch ember.js will become a default in RoR by the end of this year.
I suspect in a couple of years time no-one will be using ember.js as it presently is.
They use methods to access properties and hide the actual properties away in an internal array.
This is because ECMA 3 doesn't have get/setters for property changed notifications. It's one of those things you can't shim. ECMA 5 does support get/setters, so once you don't have to support IE8, using it as it presently is will be silly.
It's a ticking time bomb. If you're using ember.js you can't write normal javascript, which is why I think it won't get any serious penetration. Or I hope it doesn't anyway as I've used libraries that do this before and it gets old fast.
They use methods to access properties and hide the actual properties away in an internal array.
This is because ECMA 3 doesn't have get/setters for property changed notifications. It's one of those things you can't shim. ECMA 5 does support get/setters, so once you don't have to support IE8, using it as it presently is will be silly.
It's a ticking time bomb. If you're using ember.js you can't write normal javascript, which is why I think it won't get any serious penetration. Or I hope it doesn't anyway as I've used libraries that do this before and it gets old fast.
I have limited experience with javascript and MVMM's and cannot answer all the questions, but here is what I do know:
Which is best overall? Not enough experience with ember.js to comment.
Common gotchas for angular: It's a very different approach when compared to using jquery for everything. The documentation can seem a bit daunting at first, as described in the popular post about why discourse chose ember.js.
"The documentation was simple to understand
Here’s some text right out of the Angular.JS guides, about a feature called Transclusion.
'The advantage of transclusion is that the linking function receives a transclusion function which is pre-bound to the correct scope. In a typical setup the widget creates an isolate scope, but the transclusion is not a child, but a sibling of the isolate scope. This makes it possible for the widget to have private state, and the transclusion to be bound to the parent (pre-isolate) scope.'" - http://eviltrout.com/2013/02/10/why-discourse-uses-emberjs.h...
A lot of these problems are solved by the excellent tutorial videos at http://www.egghead.io though. I have no affiliation to the site, but it has made a ton of things about angular more clear for me.
Hope this helps!
Which is best overall? Not enough experience with ember.js to comment.
Common gotchas for angular: It's a very different approach when compared to using jquery for everything. The documentation can seem a bit daunting at first, as described in the popular post about why discourse chose ember.js.
"The documentation was simple to understand
Here’s some text right out of the Angular.JS guides, about a feature called Transclusion.
'The advantage of transclusion is that the linking function receives a transclusion function which is pre-bound to the correct scope. In a typical setup the widget creates an isolate scope, but the transclusion is not a child, but a sibling of the isolate scope. This makes it possible for the widget to have private state, and the transclusion to be bound to the parent (pre-isolate) scope.'" - http://eviltrout.com/2013/02/10/why-discourse-uses-emberjs.h...
A lot of these problems are solved by the excellent tutorial videos at http://www.egghead.io though. I have no affiliation to the site, but it has made a ton of things about angular more clear for me.
Hope this helps!
Ha ha, nice way to scare people off angular and justify their decision ;) Transclusions are an interesting feature to cherry pick because a) they're a necessary complexity to enable reusable components (one of angular's greatest strengths), and b) they highlight the steep learning curve required to truly master angular.
I agree that the docs can be a bit vague occasionally, but I think that's only due to the sheer depth of features and flexibility that angular provides. I was a skeptic for a long time (was championing knockout.js), but having used it in both personal and professional projects, I'm a convert.
Angular is a thoroughly well designed library, that gets the hell out of your way.
I agree that the docs can be a bit vague occasionally, but I think that's only due to the sheer depth of features and flexibility that angular provides. I was a skeptic for a long time (was championing knockout.js), but having used it in both personal and professional projects, I'm a convert.
Angular is a thoroughly well designed library, that gets the hell out of your way.
I wasn't trying to scare people off of angular, as it's what I am currently trying to use. I find it to be a very good framework, but also plan on checking out ember.js to see if it provides more for me overall or not.
Yeah, sorry, was referring to the discourse article, not meaning to implicate you.
Can you share what converted you from knockout to to angular? What were the big reasons? What was the tipping point?
A few things really:
1) a good friend recommended angular to me, in pre-1.0 days, the site was horrid, and I just couldn't grok angular. The framework, site and docs have improved drastically over the last year.
2) I was initially against angular's declarative markup style, thou shalt not mix html and code, etc. But after spending a bit of time getting unobtrusive bindings to work with KO [1], and then looking at the angular equivalent functionality [2], I was sold.
3) Having to massage "business-logic" code into ko.observable* (or DS.*) is quite arduous, angular does 2-way binding on plain old JS objects.
4) Angular templates are logic-less and it strongly encourages you to put your logic into your controllers, where it can be easily tested.
In the end KO is a template-binding library, whereas angular and ember are full stack.
[1] http://gratdevel.blogspot.com.au/2012/02/exploring-todomvc-a... [2] http://angularjs.org/#add-some-control
1) a good friend recommended angular to me, in pre-1.0 days, the site was horrid, and I just couldn't grok angular. The framework, site and docs have improved drastically over the last year.
2) I was initially against angular's declarative markup style, thou shalt not mix html and code, etc. But after spending a bit of time getting unobtrusive bindings to work with KO [1], and then looking at the angular equivalent functionality [2], I was sold.
3) Having to massage "business-logic" code into ko.observable* (or DS.*) is quite arduous, angular does 2-way binding on plain old JS objects.
4) Angular templates are logic-less and it strongly encourages you to put your logic into your controllers, where it can be easily tested.
In the end KO is a template-binding library, whereas angular and ember are full stack.
[1] http://gratdevel.blogspot.com.au/2012/02/exploring-todomvc-a... [2] http://angularjs.org/#add-some-control
if you think Angular docs are vague, go check Ember. (what docs?)
_These_ docs:
Ember.JS Guides: http://emberjs.com/guides/
Ember.js API Docs: http://emberjs.com/api/
To be fair there have been a bunch of API changes but as of yesterday Version: v1.0.0-rc.1 is released.
This means that the API for Ember.js should now be much more stable going forward.
The next step is to get Ember-Data to where it's stable and then merge it into Ember.js proper.
Ember.JS Guides: http://emberjs.com/guides/
Ember.js API Docs: http://emberjs.com/api/
To be fair there have been a bunch of API changes but as of yesterday Version: v1.0.0-rc.1 is released.
This means that the API for Ember.js should now be much more stable going forward.
The next step is to get Ember-Data to where it's stable and then merge it into Ember.js proper.
John Lindquist's videos are a godsend when it comes to learning Angular. His videos finally convinced me to switch to doing all of my web development in IDEA (since I had a license anyways) with the AngularJS plugin.
I found out about his videos through the other ones he put on JetBrains TV[0]. If you're looking for an absolute crash course in AngularJS, the ones on JetBrains TV are the best.
[0] http://tv.jetbrains.net/channel/webstorm/angularjs , http://tv.jetbrains.net/videocontent/angularjs-custom-compon...
I found out about his videos through the other ones he put on JetBrains TV[0]. If you're looking for an absolute crash course in AngularJS, the ones on JetBrains TV are the best.
[0] http://tv.jetbrains.net/channel/webstorm/angularjs , http://tv.jetbrains.net/videocontent/angularjs-custom-compon...
Hold on it gets better (Angular Docs):
"To solve the issue of lack of isolation, the directive declares a new isolated scope. An isolated scope does not prototypically inherit from the child scope, and therefore we don't have to worry about accidentally clobbering any properties.
However isolated scope creates a new problem: if a transcluded DOM is a child of the widget isolated scope then it will not be able to bind to anything. For this reason the transcluded scope is a child of the original scope, before the widget created an isolated scope for its local variables. This makes the transcluded and widget isolated scope siblings."
Data-binding and re-usability should not be that hard.
"To solve the issue of lack of isolation, the directive declares a new isolated scope. An isolated scope does not prototypically inherit from the child scope, and therefore we don't have to worry about accidentally clobbering any properties.
However isolated scope creates a new problem: if a transcluded DOM is a child of the widget isolated scope then it will not be able to bind to anything. For this reason the transcluded scope is a child of the original scope, before the widget created an isolated scope for its local variables. This makes the transcluded and widget isolated scope siblings."
Data-binding and re-usability should not be that hard.
Actually that's the only bit confusing part of the documentation (which now everyone is quoting to troll Angular).
No. Please read this entire document on directives, which are a front-and-center feature of Angular: http://docs.angularjs.org/guide/directive. The transclusion snippet is pretty representative of this entire document.
Pity Google don't take the hint and make it more readable/understandable then.
It's really not so bad, I'm in no way an angular expert, but reading that passage (even out of context), is not beyond the realms of comprehension.
I think it says what it needs to say in the context of the surrounding information, no more, no less.
I think it says what it needs to say in the context of the surrounding information, no more, no less.
I haven't used ember.js, but have been getting my teeth into angular.js over the past couple of months. Overall, I've been very happy with it.
What I liked:
- Relative simplicity and very little code for most common tasks (showing/hiding content, AJAX and JSON support, breaking down the UI into components / areas).
- Great testability, thanks to relatively clean separation of concerns.
- The two way databinding support is awesome and works well. This does away with lots of the usual boilerplate.
- Templating is very straightforward.
- No performance issues to report. But from what I can gather, Angular a bit like the Swing framework - it's possible to shoot yourself in the foot and write poorly peforming applications. (Haven't managed to do that yet ;))
What I'm struggling with:
- Working with directives is complicated. They are the only way you can integrate with other javascript components sanely. Specifically, I ran into some issues with how to make the databinding work between directives. Still wrapping my head around how that bit works.
- It took a while before I was able to get my unit tests up and running (most example test suites were out of date with the current way of doing things)
- I have some (minor) issues with how things are named. There are two kinds of 'Controllers', for example, which are used in very different contexts (in the DOM, and in directives). Angular's 'controllers' are actually closer to models IMHO (they are where you manipulate state) than controllers.
What I liked:
- Relative simplicity and very little code for most common tasks (showing/hiding content, AJAX and JSON support, breaking down the UI into components / areas).
- Great testability, thanks to relatively clean separation of concerns.
- The two way databinding support is awesome and works well. This does away with lots of the usual boilerplate.
- Templating is very straightforward.
- No performance issues to report. But from what I can gather, Angular a bit like the Swing framework - it's possible to shoot yourself in the foot and write poorly peforming applications. (Haven't managed to do that yet ;))
What I'm struggling with:
- Working with directives is complicated. They are the only way you can integrate with other javascript components sanely. Specifically, I ran into some issues with how to make the databinding work between directives. Still wrapping my head around how that bit works.
- It took a while before I was able to get my unit tests up and running (most example test suites were out of date with the current way of doing things)
- I have some (minor) issues with how things are named. There are two kinds of 'Controllers', for example, which are used in very different contexts (in the DOM, and in directives). Angular's 'controllers' are actually closer to models IMHO (they are where you manipulate state) than controllers.
From Addy @ - http://coding.smashingmagazine.com/2012/07/27/journey-throug... ::
I want something flexible which offers a minimalist solution to separating concerns in my application. It should support a persistence layer and RESTful sync, models, views (with controllers), event-driven communication, templating and routing. It should be imperative, allowing one to update the View when a model changes. I’d like some decisions about the architecture left up to me. Ideally, many large companies have used the solution to build non-trivial applications. As I may be building something complex, I’d like there to be an active extension community around the framework that have already tried addressing larger problems (Marionette, Chaplin, Aura, Thorax). Ideally, there are also scaffolding tools (grunt-bbb, brunch) available for the solution. Use Backbone.js.
I want something declarative that uses the View to derive behavior. It focuses on achieving this through custom HTML tags and components that specify your application intentions. It should support being easily testable, URL management (routing) and a separation of concerns through a variation of MVC. It takes a different approach to most frameworks, providing a HTML compiler for creating your own DSL in HTML. It may be inspired by upcoming Web platform features such as Web Components and also has its own scaffolding tools available (angular-seed). Use AngularJS.
I want something flexible which offers a minimalist solution to separating concerns in my application. It should support a persistence layer and RESTful sync, models, views (with controllers), event-driven communication, templating and routing. It should be imperative, allowing one to update the View when a model changes. I’d like some decisions about the architecture left up to me. Ideally, many large companies have used the solution to build non-trivial applications. As I may be building something complex, I’d like there to be an active extension community around the framework that have already tried addressing larger problems (Marionette, Chaplin, Aura, Thorax). Ideally, there are also scaffolding tools (grunt-bbb, brunch) available for the solution. Use Backbone.js.
I want something declarative that uses the View to derive behavior. It focuses on achieving this through custom HTML tags and components that specify your application intentions. It should support being easily testable, URL management (routing) and a separation of concerns through a variation of MVC. It takes a different approach to most frameworks, providing a HTML compiler for creating your own DSL in HTML. It may be inspired by upcoming Web platform features such as Web Components and also has its own scaffolding tools available (angular-seed). Use AngularJS.
I tried both in similar circumstances (coming from a long backbone background), all I can say is I personally found with Ember.js (around august 2012):
- more boilerplate
- learning curve was much steeper.
- the documentation confused me, it turned out there were many slight diferences between 0.9.xxx and 1.xxx. This "gotcha" is probably rectified by now
I tried Angular.js next (this month) and "got it" immediately: - testing is easier - writing dom manipulation is easier (ie directives) - the documentation/seed projects are great - angular-ui project is cool
In that last 6 months I imagine Ember has improved, I also feel like if I came to it now Id pick it up quicker having gone to all this effort
I tried Angular.js next (this month) and "got it" immediately: - testing is easier - writing dom manipulation is easier (ie directives) - the documentation/seed projects are great - angular-ui project is cool
In that last 6 months I imagine Ember has improved, I also feel like if I came to it now Id pick it up quicker having gone to all this effort
> This "gotcha" is probably rectified by now
It's not. The guides published on emberjs.com apparently track the master branch on github, so are regularly out of sync with the version offered for download on the front page, and at the moment there's a third version bundled with the starter kit. This completely tripped me up when I tried to get off the ground a couple of weeks ago, because things that were described as working in the guides just didn't, and it wasn't clear what I'd got wrong.
EDIT 'cos noprocrast kicked in at the wrong moment: Add to this a release policy of stuffing new functionality in every minor release, and you've got documentation that, for someone completely new to it, who doesn't know what they don't know, feels like a minefield. The one thing you want as a beginner is documentation you can trust, and Ember just doesn't provide that yet.
To learn enough get off the ground, I ended up writing an "assume you know nothing" tutorial (https://github.com/regularfry/website/blob/master/source/gui...), which I've submitted back to emberjs.
It's not. The guides published on emberjs.com apparently track the master branch on github, so are regularly out of sync with the version offered for download on the front page, and at the moment there's a third version bundled with the starter kit. This completely tripped me up when I tried to get off the ground a couple of weeks ago, because things that were described as working in the guides just didn't, and it wasn't clear what I'd got wrong.
EDIT 'cos noprocrast kicked in at the wrong moment: Add to this a release policy of stuffing new functionality in every minor release, and you've got documentation that, for someone completely new to it, who doesn't know what they don't know, feels like a minefield. The one thing you want as a beginner is documentation you can trust, and Ember just doesn't provide that yet.
To learn enough get off the ground, I ended up writing an "assume you know nothing" tutorial (https://github.com/regularfry/website/blob/master/source/gui...), which I've submitted back to emberjs.
Thats a shame, when using Ember I really wanted to like it but just ended up console.logging sooo many object to see what was possible/different from the guides. Obviously theres a lot of people out there who "get it" in a way that I can't, judging from all the pro-ember comments
This was only true briefly. The guides on emberjs.com reflect the currently released version, 1.0 RC. Since we've hit RC the APIs are now frozen.
I checked the dates. I tripped over the docs not matching the download version on January 7th. I found non-matching versions yesterday. It's possible that both times I decided to look at it I got unlucky, I guess.
I'm glad the APIs are frozen, I was worried there'd still be creep through the RCs.
I'm glad the APIs are frozen, I was worried there'd still be creep through the RCs.
We were in the middle of the release yesterday. If anything is still not matching, please let us know so we can correct it.
Most enjoyable thing for me (and great in very common situations) in Angular.js is the two-way databinding and the "ng-repeat" thing. These things are easy and lie on the "flat" part of the S-shaped learning curve.
Also that there is no templating system - I always disliked having to learn and use and debug another abstraction layer (Mustache/Handlebars or Razor with MVC etc.).
The biggest "gotchas" with these frameworks will typically be the problem of having to wrap your head around a few new and unfamiliar concepts and syntax that take a while to "grok". (On the other hand, it's NOT difficult in a objective sense, like some advanced mathematics that not everyone is capable of doing, so, to anyone reading these JS framework-threads on HN, please end up encouraged to try them out yourself.)
Learning one framework will greatly help your understanding of the other, so I'd say just pick one and decide later which one is "best".
Also that there is no templating system - I always disliked having to learn and use and debug another abstraction layer (Mustache/Handlebars or Razor with MVC etc.).
The biggest "gotchas" with these frameworks will typically be the problem of having to wrap your head around a few new and unfamiliar concepts and syntax that take a while to "grok". (On the other hand, it's NOT difficult in a objective sense, like some advanced mathematics that not everyone is capable of doing, so, to anyone reading these JS framework-threads on HN, please end up encouraged to try them out yourself.)
Learning one framework will greatly help your understanding of the other, so I'd say just pick one and decide later which one is "best".
I have enormous confidence in the capabilities of the team working on Ember. jQuery, Sproutcore, Rails core team members. If you're a Rails developer, the existence of active_model_serializers as a quasi-standard for how JSON is shuttled between tiers suggests that Ember has taken a position of strong thought leadership on a lot of things that other frameworks just don't have the reach to do.
Also, the recent Peepcode screencast on Ember is brilliant.
Also, the recent Peepcode screencast on Ember is brilliant.
I think the capabilities of the Angular team are quite respectable as well. Speaking of "reach" and thought leadership makes think of the fact that these guys are working at Google! This seems to have several positive aspects:
a) Possibly a more solid stance on development (stable APIs, not ditching a project and rewriting (Sproutcore -> Ember). Sorry if I simplify too much here.
b) Being a little "strategic" for Google: In this podcast [1] Igor Minar seems to suggest that they have some influence with other people at Google who work on web standards.
Logic: Google goes great length to optimize Chrome performance - therefore needs to understand how modern websites work, therefore may want to influence how modern web development is done (through their own js framework) so that the Browser can optimize better etc.
c) Also note the existance of a Chrome extension [2] for displaying and debugging Angular.js models in the browser.
Logic: Google wanting to promote their browser - therefore adressing important multiplicators like web developers with useful tools for development, leading to more websites being developed, tested primarily on Chrome, making use of Chrome features etc.
Do you agree? I haven't heard too much commentary on the "big picture"!
[1] http://basementcoders.com/2011/08/episode-41-interview-with-... [2] https://github.com/angular/angularjs-batarangfor Chrome helping with displaying
a) Possibly a more solid stance on development (stable APIs, not ditching a project and rewriting (Sproutcore -> Ember). Sorry if I simplify too much here.
b) Being a little "strategic" for Google: In this podcast [1] Igor Minar seems to suggest that they have some influence with other people at Google who work on web standards.
Logic: Google goes great length to optimize Chrome performance - therefore needs to understand how modern websites work, therefore may want to influence how modern web development is done (through their own js framework) so that the Browser can optimize better etc.
c) Also note the existance of a Chrome extension [2] for displaying and debugging Angular.js models in the browser.
Logic: Google wanting to promote their browser - therefore adressing important multiplicators like web developers with useful tools for development, leading to more websites being developed, tested primarily on Chrome, making use of Chrome features etc.
Do you agree? I haven't heard too much commentary on the "big picture"!
[1] http://basementcoders.com/2011/08/episode-41-interview-with-... [2] https://github.com/angular/angularjs-batarangfor Chrome helping with displaying
a) Are you proposing that Ember should have stayed SproutCore? To date, Ember has been far more successful than SproutCore and the split has enabled us to make progress that could not have been made otherwise.
b) The Ember developers also have influence over those who work with web standards too. Yehuda Katz, of the Ember Core Team, is a member of TC39 and also W3C TAG. We regularly meet and converse with developers both for Chrome and Firefox. Furthermore, Chrome is not going to implement features that are only useful for Angular. Anything they implement that benefits Angular is also provided to be useful to a broader audience. In many cases, those improvements are also useful to Ember.
c) As announced at EmberCamp yesterday, there is also an Ember Chrome extension in development.
b) The Ember developers also have influence over those who work with web standards too. Yehuda Katz, of the Ember Core Team, is a member of TC39 and also W3C TAG. We regularly meet and converse with developers both for Chrome and Firefox. Furthermore, Chrome is not going to implement features that are only useful for Angular. Anything they implement that benefits Angular is also provided to be useful to a broader audience. In many cases, those improvements are also useful to Ember.
c) As announced at EmberCamp yesterday, there is also an Ember Chrome extension in development.
Thanks for the information!
There is a free alternative for angular: http://egghead.io/
There is also a paid screencast by railscasts http://railscasts.com/episodes/405-angularjs and if you want a good rails integration you should check this https://github.com/patcito/angularjs_scaffold (mine).
Looks like the peepcode screencast is paid:
https://peepcode.com/products/emberjs
I suppose you'll say it's well worth the money? Anyone else bought/watched this screencast?
https://peepcode.com/products/emberjs
I suppose you'll say it's well worth the money? Anyone else bought/watched this screencast?
I bought it too. It's definitely worth $12. Code School is also planning a course on Ember.js to be released in the coming months. It will be a paid (subscription) course as well.
I did notice that Ember.js ran quite slow in my local environment. I'm curious if there's something I could do to speed it up in development. Having played around with Discourse, I'm certain speed isn't a problem in production.
I did notice that Ember.js ran quite slow in my local environment. I'm curious if there's something I could do to speed it up in development. Having played around with Discourse, I'm certain speed isn't a problem in production.
You haven't really answered any of the OP's questions.
This is a good post on why Discourse chose Ember: http://eviltrout.com/2013/02/10/why-discourse-uses-emberjs.h...
Indeed, great post. I'm really interested in seeing perspectives of those who've used both though, hopefully those mysterious people exist ;)
Neither. Small modularized CommonJS files that serve the need of what you are doing is always faster to write and easier to load in your head than large frameworks that you never fully understand. Learn to use npm and use it well.
To people saying "backbone", stop. Backbone is a tiny abstraction that pretty much does nothing; It's the worst of both worlds: You have to use fake getters/setters but the framework is absolutely unhelpful.
Angular is more developer friendly as it avoids crappy string templates and let you program to POJOS; Programming with POJO in Javascript circa 2013 has a big performance cost that might be very noticeable in some cases (Mobile, low spec devices, sites with a lot of interaction/server pushes). Basically Angular simply DOES NOT scale by design, but 90% of websites will still be kind of ok (This gray line is exactly why I don't use Angular :) ).
Angular is more developer friendly as it avoids crappy string templates and let you program to POJOS; Programming with POJO in Javascript circa 2013 has a big performance cost that might be very noticeable in some cases (Mobile, low spec devices, sites with a lot of interaction/server pushes). Basically Angular simply DOES NOT scale by design, but 90% of websites will still be kind of ok (This gray line is exactly why I don't use Angular :) ).
From what I've seen for the most part they both try to accomplish the same thing. Both will require time to learn and work into your application. A lot of the comments I read are from people that are anti-google or question angular because of its google beginnings, so they are anti angular and because ember is created by a rails developer it integrates better with rails.
Just go through the egghead tutorials then go over ember documentation and then make a decision. I don't think you can go wrong with either one.
Just go through the egghead tutorials then go over ember documentation and then make a decision. I don't think you can go wrong with either one.
As a relative beginner - "It's a very different approach when compared to using jQuery for everything" — is a bit misleading. They're both very different to jQuery (or Backbone/Spine - which are beautifully simple).
Totally anecdotal: - Backbone I learnt straight away and have been progressively writing better code for around a year. It gives you enough rope to hang yourself but you can usually see what you've done and refactor. Which is nice. - Ember I've been trying to learn a couple of times for the past year. Keep trying. Find a tutorial. It's out of date. Get frustrated. Try again. Find another one. It's poorly written. Try Again. Find another one. Can't get something to work and Ember is too much of a blackbox to debug. Give up.
The docs on the site are getting better (but still suck) - the PeepCode tutorial was great (not the Play By Play with Yehuda; don't waste your money on that) - but it still only did relatively trivial things. Would be great if PeepCode did a Play By Play with a Rails API and relational data etc.
- Angular scared me for ages too - the docs, as with Ember, are written by people who know how to use the framework for people who know how to use it already. Then Egghead.io happened. Wow. The concepts actually aren't that hard!
I think what the community sorely needs is a good Ember teacher - one that isn't patronising or aimed at computer scientists!
Totally anecdotal: - Backbone I learnt straight away and have been progressively writing better code for around a year. It gives you enough rope to hang yourself but you can usually see what you've done and refactor. Which is nice. - Ember I've been trying to learn a couple of times for the past year. Keep trying. Find a tutorial. It's out of date. Get frustrated. Try again. Find another one. It's poorly written. Try Again. Find another one. Can't get something to work and Ember is too much of a blackbox to debug. Give up.
The docs on the site are getting better (but still suck) - the PeepCode tutorial was great (not the Play By Play with Yehuda; don't waste your money on that) - but it still only did relatively trivial things. Would be great if PeepCode did a Play By Play with a Rails API and relational data etc.
- Angular scared me for ages too - the docs, as with Ember, are written by people who know how to use the framework for people who know how to use it already. Then Egghead.io happened. Wow. The concepts actually aren't that hard!
I think what the community sorely needs is a good Ember teacher - one that isn't patronising or aimed at computer scientists!
> I think what the community sorely needs is a good Ember teacher
I think what we really need is a tool to go around and mark outdated blog posts as outdated. There's also this: http://www.embercast.com/. Not sure where it's going.
I think what we really need is a tool to go around and mark outdated blog posts as outdated. There's also this: http://www.embercast.com/. Not sure where it's going.
I've used Angular and really enjoyed developing with it. You get results really fast. It feels like a more organized Knockout.js (which is also great).
Personally, I have found Angular JS very comprehensive. I have used bits of Backbone, Ember and Angular and have found Angular pretty good.
Related query: I've just started with some JS MVVM frameworks, and I was wondering if any of them can "reverse bind" ie. enable you to render part of your templates on the server and utilise data from that based on a template to recreate models. The idea is to make the initial load snappy and to help with SEO (only one or two web crawlers actually execute JS afaik)
If there is a particular data model that you want, there's no shame in just passing it directly inside the container of the view. Given a Handlebars template on the server like:
It comes in handy for progressive enhancement.
<div class="profile-widget" {{#if serverEnv}}data-model="{{jsonStringify profileModel}}"{{/if}}>
<span class="name">{{name}}</span>
<span class="phone">{{phone}}</span>
</div>
It comes in handy for progressive enhancement.
DerbyJS, Metor, or you can extend Backbone Views to read a model from the DOM on initialization if the model is empty (granted you'd have to custom code the DOM-reading parts for each model that you plan on loading this way)
Airbnb is working on something similar as well using Node+Backbone but it's not available yet. They said they're planning on open sourcing it eventually but we'll have to wait a few months. http://nerds.airbnb.com/weve-launched-our-first-nodejs-app-t...
Airbnb is working on something similar as well using Node+Backbone but it's not available yet. They said they're planning on open sourcing it eventually but we'll have to wait a few months. http://nerds.airbnb.com/weve-launched-our-first-nodejs-app-t...
I believe almost all of them have this capability. I know angular has templates and you can put dynamic data in those templates. The dynamic data can be loaded from anywhere. I'm not aware of any MVVM that doesn't allow you to do this, unless I misunderstand what you are saying.
I guess I wasn't clear enough.
You're talking about data -> template binding. I'm talking about the reverse, where some data (as a model) is recovered from a partial server-side render of the page, based upon the "patterns" described in the templates.
For example, if Angular did this (I don't think it does), it could traverse the generated HTML and compare it with the original template to figure out what's what.
You're talking about data -> template binding. I'm talking about the reverse, where some data (as a model) is recovered from a partial server-side render of the page, based upon the "patterns" described in the templates.
For example, if Angular did this (I don't think it does), it could traverse the generated HTML and compare it with the original template to figure out what's what.
I haven't explored what your describing, but I'm using a different solution. I'm adding backbone to an existing project and added some server side code that outputs the current model object as json in a <script> tag in the html page. This is passed to a new backbone model instance.
You can pass the initial data as a json object directly with the server response.
I'm using Rails, and https://github.com/gazay/gon gem does it for you nicely.
I'm using Rails, and https://github.com/gazay/gon gem does it for you nicely.
Take a look at source code examples of Angular and Ember Todo apps: http://addyosmani.github.com/todomvc/
Some interesting facts about Todo apps:
Angular.js: 10 requests, 41.94kb transferred.
Ember.js: 17 requests, 334.12kb transferred.
Some interesting facts about Todo apps:
Angular.js: 10 requests, 41.94kb transferred.
Ember.js: 17 requests, 334.12kb transferred.
If by interesting you mean totally misleading, then sure!
The Ember.js version included is unminified, and the number of files reflect several small files rather than one big file. The goal of TodoMVC is to compare code style.
But sure, we'll submit a pull request to TodoMVC to use the minified version of Ember.
The Ember.js version included is unminified, and the number of files reflect several small files rather than one big file. The goal of TodoMVC is to compare code style.
But sure, we'll submit a pull request to TodoMVC to use the minified version of Ember.
My doubts:
- If a great amount of my functionality isn't covered by the directives - say my app does the bulk of interactions with Raphael.js instead of forms/checkboxes - is Angularjs still worth to include, or should I go with something lighter?
- (similar) If I'm going to use a lot of jQuery plugins or external libraries, say jPlayer + D3.js + jQuery File Upload, etc - is Angular gonna get in my way when using them?
In other words, would you write those frontends with AngularJS? (Perhaps we should ignore the very short load-time requirement...)
- If a great amount of my functionality isn't covered by the directives - say my app does the bulk of interactions with Raphael.js instead of forms/checkboxes - is Angularjs still worth to include, or should I go with something lighter?
- (similar) If I'm going to use a lot of jQuery plugins or external libraries, say jPlayer + D3.js + jQuery File Upload, etc - is Angular gonna get in my way when using them?
In other words, would you write those frontends with AngularJS? (Perhaps we should ignore the very short load-time requirement...)
- Facebook
- Gmail
- Soundcloud
- Twitter
- Youtube
- WolframAlpha
- Reddit
- Google Spreadsheet
- Amazon
- BackpackHere is a youtube frontend that was written with angular.js: http://toogl.es/#/browse
Sorry, I can't comment on the others.
Sorry, I can't comment on the others.
For me, Angular displays the right balance beween complexity and ease of use. After getting past some of barriers (the transclusion docs could be more easily explained, specially with some images), I find it pretty easy to use, and it's great for complex apps. Never used Ember though, after using Spring for so long, dependency injection comes naturally.
Some people mention Backbone, I think it's great if you're very comfortable with JS, otherwise you'll end up replicating bits of other frameworks by hand or using lots of 3rd parties (ex: databinding, validation, complex model interaction, view cleanup).
Anyway, take a few days to get the feel of each and choose according.
Some people mention Backbone, I think it's great if you're very comfortable with JS, otherwise you'll end up replicating bits of other frameworks by hand or using lots of 3rd parties (ex: databinding, validation, complex model interaction, view cleanup).
Anyway, take a few days to get the feel of each and choose according.
Ours is basically a CRUD App, i tried to build it in Ember.js but gave up after not finding an step by step getting started (like the one in angularjs homepage),
after that i started to learn angular, it had an step by step guide and working with ng-repeat was such a bliss, we were able to launch a simple billing system in about 5 days using angularjs, egghead videos help me whenever i find something difficult to implement (like 2 way binding between controller and a directive)
after that i started to learn angular, it had an step by step guide and working with ng-repeat was such a bliss, we were able to launch a simple billing system in about 5 days using angularjs, egghead videos help me whenever i find something difficult to implement (like 2 way binding between controller and a directive)
I actually really like the KnockoutJS + SammyJS approach to building single page apps. Angular is probably closer to that approach.
MVVM is awesome and will save you a lot of time IMO.
MVVM is awesome and will save you a lot of time IMO.
We're currently using Sammy + Knockout on https://circleci.com, and it is nice, but adding observables everywhere is annoying. I'd love to hear from anyone who moved from this to Angular or Embed?
Ember is object-oriented, angular is functional(ish).
This is one of the key issues folks seem to skip past when discussing the differences.
I'm not familiar with the maintainers of Angular and their backgrounds, but with Ember you can expect solutions that mimic the methodologies you'd otherwise find in Rails. I'm particularly referring to OO in this case.
I'm not familiar with the maintainers of Angular and their backgrounds, but with Ember you can expect solutions that mimic the methodologies you'd otherwise find in Rails. I'm particularly referring to OO in this case.
Uninformed opinion:
I looked at angular.js and understood how to use it pretty quickly , with ember.js there seems to be a lot more framework-yness to it.
I looked at angular.js and understood how to use it pretty quickly , with ember.js there seems to be a lot more framework-yness to it.
The biggest + for me with Ember is the community around it. I have felt like I've grown with the community in the past few months as I've learned the framework. The freenode channel is usually active with lots of help available.
It would be unfair for me to compare this experience to Angular though because I haven't been so deeply involved with it.
It would be unfair for me to compare this experience to Angular though because I haven't been so deeply involved with it.
None.
Backbone + underscore + jQuery.
Unless you really have to have a framework.
The combination of the above will have you writing in JS rather than in framework X.
Backbone + underscore + jQuery.
Unless you really have to have a framework.
The combination of the above will have you writing in JS rather than in framework X.
If using Backbone, then https://github.com/marionettejs/backbone.marionette is a MUST. It would cut down on lot of code and it makes code more cleaner.
In addition, switch to CoffeeScript.
I'd also add the question "Which is more flexible?". Last thing I want is to pour weeks and weeks into a framework to discover that I have to be a witchdoctor to bend it to my will when I want to do anything even just slightly out of the ordinary.
I want to learn Ember, but the official docs are confusing, and the tutorials are outdate, are there any YouTube videos or any other of tutorial on Ember?
The docs are actually quite good now. As we've just released 1.0 RC, the API is also frozen which will help the docs improve even further.
The guides are good, but I'm missing the whole put it all together to make a real app tutorial type level of documentation. Can you point me to something like that?
The recent peepcode ember video pulls things together nicely, but of course it's not free. https://peepcode.com/products/emberjs
Also there is a great example project available here: https://github.com/dgeb/ember_data_example
Also there is a great example project available here: https://github.com/dgeb/ember_data_example
Maybe TodoMVC would help?
https://github.com/addyosmani/todomvc/tree/gh-pages/architec...
https://github.com/addyosmani/todomvc/tree/gh-pages/architec...
I don't get it, why not just play around with examples, look at the source, destruct it and understand how it works? This is efficient.
You're exactly like most of my friends who want video2brain alike materials to teach them stuff they don't want to study on their own. No offense :)
You're exactly like most of my friends who want video2brain alike materials to teach them stuff they don't want to study on their own. No offense :)
Angular worked far better for me
Angular, hands down.
backbone.js
ok here is my take :
AngularJS :
+ MVVM : databinding
+ Dependency Injection, so no global state, and loose coupling
+ Well organised into services , view models ,directives , filters , ...
- forget any projects that are animation/transition between views heavy, you'll fail
- doesnt play well with some other frameworks ( requireJS, jQuery mobile , even phonegap ...)
- is slow when dealing with a lot of data.
- no control over dom objects lifecycle
- the doc sucks
- if you dont understand Dependency injection , dont use it.
- will not scale if javascript dont get some new structures , dirtychecking is insane given javascript performances.
Ember: + fully event driven
+ plays well with other libraries
+ less magic than angular
+ full control over DOM lifecycle
- the doc sucks but less than angularJS one
- more verbose than AngularJS
- unstable API
I built apps in both langages. like that one :
http://markme.alwaysdata.net/
I prefer Ember but have no problem using Angular when I have to.
AngularJS :
+ MVVM : databinding
+ Dependency Injection, so no global state, and loose coupling
+ Well organised into services , view models ,directives , filters , ...
- forget any projects that are animation/transition between views heavy, you'll fail
- doesnt play well with some other frameworks ( requireJS, jQuery mobile , even phonegap ...)
- is slow when dealing with a lot of data.
- no control over dom objects lifecycle
- the doc sucks
- if you dont understand Dependency injection , dont use it.
- will not scale if javascript dont get some new structures , dirtychecking is insane given javascript performances.
Ember: + fully event driven
+ plays well with other libraries
+ less magic than angular
+ full control over DOM lifecycle
- the doc sucks but less than angularJS one
- more verbose than AngularJS
- unstable API
I built apps in both langages. like that one :
http://markme.alwaysdata.net/
I prefer Ember but have no problem using Angular when I have to.
> forget any projects that are animation/transition between views heavy, you'll fail
Animation is coming to the next version. It's already possible but you have to do it yourself.
> doesnt play well with some other frameworks ( requireJS, jQuery mobile , even phonegap ...)
* https://github.com/tigbro/jquery-mobile-angular-adapter * http://briantford.com/blog/angular-phonegap.html
> is slow when dealing with a lot of data.
It's fast enough not to be noticeable by humans unless you're batman as explained by Angular creator: http://stackoverflow.com/questions/9682092/databinding-in-an... . Object.observe will make it fast even if you're batman.
> no control over dom objects lifecycle
There is control actually (see digest, apply etc).
> the doc sucks
The guides are actually pretty good and http://egghead.io/ free screencasts are awesome.
Edit: Google is going to sponsor the author of egghead.io videos! https://twitter.com/eggheadio/status/302494160982781953
> if you dont understand Dependency injection , dont use it.
You don't have to understand DI to use it. I know I didn't.
> will not scale if javascript dont get some new structures , dirtychecking is insane given javascript performances.
Again, read this http://stackoverflow.com/questions/9682092/databinding-in-an...
Animation is coming to the next version. It's already possible but you have to do it yourself.
> doesnt play well with some other frameworks ( requireJS, jQuery mobile , even phonegap ...)
* https://github.com/tigbro/jquery-mobile-angular-adapter * http://briantford.com/blog/angular-phonegap.html
> is slow when dealing with a lot of data.
It's fast enough not to be noticeable by humans unless you're batman as explained by Angular creator: http://stackoverflow.com/questions/9682092/databinding-in-an... . Object.observe will make it fast even if you're batman.
> no control over dom objects lifecycle
There is control actually (see digest, apply etc).
> the doc sucks
The guides are actually pretty good and http://egghead.io/ free screencasts are awesome.
Edit: Google is going to sponsor the author of egghead.io videos! https://twitter.com/eggheadio/status/302494160982781953
> if you dont understand Dependency injection , dont use it.
You don't have to understand DI to use it. I know I didn't.
> will not scale if javascript dont get some new structures , dirtychecking is insane given javascript performances.
Again, read this http://stackoverflow.com/questions/9682092/databinding-in-an...
> Object.observe will make it fast even if you're batman.
Additionally Object.observe will make Ember way of the data binding obsolete. So there will be another big Ember API change in near future.
Object.observe adoption for Angular apps will be transparent. Only the framework code will be updated. Maybe it is already updated.
Additionally Object.observe will make Ember way of the data binding obsolete. So there will be another big Ember API change in near future.
Object.observe adoption for Angular apps will be transparent. Only the framework code will be updated. Maybe it is already updated.
"You don't have to understand DI to use it. I know I didn't."
LOL...me neither. I also don't get how someone could do anything beyond "Hello World" and not use DI as it seems to be pretty integral to how Angular works.
LOL...me neither. I also don't get how someone could do anything beyond "Hello World" and not use DI as it seems to be pretty integral to how Angular works.
> * https://github.com/tigbro/jquery-mobile-angular-adapter * http://briantford.com/blog/angular-phonegap.html
that's what i'm saying i should not need an adapter for these libraries , i dont need them with Ember or Backbone
that's what i'm saying i should not need an adapter for these libraries , i dont need them with Ember or Backbone
You don't need them but they make it more convenient. There's one for ember too https://github.com/LuisSala/emberjs-jqm
Prior to the 1.0 RC, Ember's API changed a lot because we were seeking for the best abstractions. We didn't want to lock ourselves in when there was a better way to do things. Now that we've hit 1.0 RC, the API is generally frozen. We'll only break existing APIs in exceptional cases. Once 1.0 Final is release we'll be sticking to SemVer.
I know we use Angular with RequireJS in a few of our apps. We require in all of our libraries (jQuery, Bootstrap and Angular) before creating the application module.
We haven't found speed to be a problem yet. We used to use CanJS, and I can tell you that handling the same amount of data, Angular is faster, even with fairly complicated filters in place.
I do agree that Angular requires you to let go of the "jQuery way" of approaching DOM manipulation, which throws jQuery-coders for a loop. It's a downside not to be able to plop in a jQuery plugin. Then again, considering some of the plugins I've encountered, that might not be a complete loss. Also, the Angular-UI team is doing a heck of a job of replicating the most common plugins as Angular native directives.
We haven't found speed to be a problem yet. We used to use CanJS, and I can tell you that handling the same amount of data, Angular is faster, even with fairly complicated filters in place.
I do agree that Angular requires you to let go of the "jQuery way" of approaching DOM manipulation, which throws jQuery-coders for a loop. It's a downside not to be able to plop in a jQuery plugin. Then again, considering some of the plugins I've encountered, that might not be a complete loss. Also, the Angular-UI team is doing a heck of a job of replicating the most common plugins as Angular native directives.
> - unstable API
Seeing as Ember just hit 1.0 RC, the API should now be pretty stable. It's been pretty bad the last few months though.
Also, with a stable API, the docs will hopefully see significant improvement.
Seeing as Ember just hit 1.0 RC, the API should now be pretty stable. It's been pretty bad the last few months though.
Also, with a stable API, the docs will hopefully see significant improvement.
- forget any projects that are animation/transition between views heavy, you'll fail
Why? How is it different from using jQuery without Angular?
Why? How is it different from using jQuery without Angular?
you have a list , each time you remove elements on the list ,you want to fade out elements that are being removed for 0.5 secs. Explain me how you would do that.
Just create a custom binding (or whatever it is called, using knockout terminology here) which fades it via a jQuery fadeOut?
nope , you have very little control over how angularJS destroy dom nodes.
You are partially right... partially wrong.. You lose control for it only when you use ng-repeat.. you could alternately write your own repeat directive that does animations for adding or removing..
If your are not yet in a state to write this level of a directive yourself, you still have a few options. I remember someone had written a fadey directive that does fading animation, there is also a fork which does animation with ng-repeat. And if you can wait, this fork will be merged into the core angular , hopefully soon...