-
The Community
You’re going to either create your own framework or use someone else’s. The Ember community has thought about a lot of solutions already, saving you time and money. -
The Documentation
Ember used to have a reputation for poor documentation, but now it’s well known that it’s much better (I’m looking at you, Angular). Start with the Ember Guides. I’ll include more resources in a following post. -
The Creators
A core contributor to jQuery, Rails, and other high profile projects, Yehuda Katz is known for high-quality software, and for sticking around for a long time to see the project grow. For the Rails folks in the room, Ember Data and ActiveModel Serializers are a match made for each other. -
The Standards
Ember embraces web standards. Google (and Angular) has a reputation for making up its own way of doing things. Ember uses Handlebars, ES6 modules, Web Components, etc. If another standard comes out, you know it will be adopted by Ember. -
The CLI
The team is really focused on supporting a quick development workflow through tools like Ember CLI. This cuts out a lot of boilerplate. -
The Scalability
For me, Ember is a natural extension of Backbone, without all of the setup and wiring-shit-up. There is a clear separation of concerns, which makes it ideal for a large-scale app. -
The Clarity
Convention over configuration decreases the number of design decisions that you have to make.
Why not Angular?
I’m not trying to single out Angular in particular, other than that the class that I am preparing this blog post for is presenting both. I don’t have any experience with Angular, so I decided to share some quotes from people who have tried it:
Angular killed the idea of the DOM. Various ng-attribute references cluttered the page around and this was mixed with what is called “mustache-esque” template bindings. It was all quite confusing. – Why I Chose Ember JS
Angular’s creator describes it as a metaframework—a framework for creating your application’s framework. Thus, if you get two different Angular apps, their internals will look completely different.
This is not the approach that Ember takes, where you buy into the framework’s conventions. So, one could argue that once you learn the conventions, you’ll spend much less time on boilerplate writing a new Ember app than a new Angular app. This doctrine also belongs to Rails, and it has worked out pretty well for them. –How do we beat AngularJS in the developers mindset?
To dive deeper:
Ember, Part 2: Getting started
Ember, Part 3: 10 resources for getting (and staying) up to date
