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 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:
- 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.
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.
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.
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  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  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"!
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.
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.
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.
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 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.
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 , and then looking at the angular equivalent functionality , 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.
"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.
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. If you're looking for an absolute crash course in AngularJS, the ones on JetBrains TV are the best.
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.
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.
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".
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:
- 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.
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
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.
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.
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
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).
- 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!
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)
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)
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.
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.
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.
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.
you obviously never wrote a "fat" client and had to maintain it : at some point you need some kind of framework to make sense out of the "small modules" mess. And CommonJS doesnt solve dependency injection issues.
- 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...)
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.
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.
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.
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.
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)
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.
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.
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...
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.