Wednesday, April 30, 2014

Embular Part 3 - What's Great About Ember

Ember also has a long list of what's great about it. It's a list that should be well known, but I feel at times that Ember fans just stink at explaining Ember's merits. Particularly to Angular fans. As I've stated above, my experience with Ember isn't as comprehensive as it is with Angular, but there are a few things about Ember that I absolutely revere and I'm excited to tell anyone who will listen:

Two way binding that doesn't allow you to write untestable code. Yeah, we've got this "two-way binding" thing in every framework these days. But where Ember shines is it forces you to write testable code. By this I mean it doesn't allow for logic in your views the way some other frameworks like Angular do. That means that everything you bind to in your view is exposed as a single, unit-testable property somewhere.

Convention over configuration. Ember uses convention to help the developer organize their code. In Ember 1.5+ this means using ES6 modules so you even know where your files are and what they're named. For example, a route named "test" would automatically look for a "test.js" file under the controllers directory, and a "test.hbs" Handlebars template under the templates directory. Likewise with files for models and the route itself. Convention over configuration means that the one stupid developer, on that other team that you hate dealing with, that always names things in stupid ways, is forced not to be a big, stupid, dumbface.

Adherence to standards. Ember developers have gone to great lengths to try to make sure Ember is moving itself, and your application's codebase towards web standards. For example, custom components are named in a convention that complies with the W3C's web components draft. Having worked with an Ember core team developer, I can tell you that their concern with future-proofing your application by trying to adhere to standards is obvious.

Ember polyfills ES5 (and ES6) functionality where it can. So if you're in a crappy browser, Array.prototype.forEach, map, reduce and filter now all work! This is in contrast to doing things like using angular.forEach, underscore/lo-dash's _.each or JQuery's $.each functions. Frankly, it's just better practice.

Extremely robust routing OOTB. Ember's routing is just flat out better than anything else I've seen out there. Better than Angular's ngRoute, better than Sammy.js, better than ui-router. It's really, really good. I've even heard rumblings that Angular might use Ember's router in the future, but that could just be gossip.

Ember solves problems and wires things up for you. What I mean by this is that in other frameworks, like Angular, you're going to have to wire quite a few things up by hand. In Ember when you add a route named ‘smith’, it’s automatically going to look for a controller either named SmithController or in the appropriate file (if you’re using Ember 1.5’s ES6 modules). This goes the same for a smith template, or a SmithRoute, etc. But none of those things are required, they’re also stubbed in for you automatically. It’s also going to look for a client-side route path “/smith”.

NEXT: Embular Part 4 - How Angular Should Be More Like Ember


  1. > Frankly, it's just better practice.

    Arguably, it's a better practice to let an application developer choose which polyfills they want to use, except for cases where we have no choice (this is coming up in Angular 2.0 to some degree, due to wanting to use the Shadow DOM or ES6 promises, etc)

    There are some conveniences to bundling it all into the framework, however for things like ES5 collection methods, there are tons of implementations and preferences between different shops of which ones to use, and why.

    It is true that angular.forEach likely should have never been exposed, though, except it is needed by some of the other core modules, rather than implement it again

    1. And, needless to say, I'm not trying to start any like flamewar or anything, but some extra perspective on different things, that's all :)

  2. I don't disagree with anything you've said. Which might be because technically you never disagreed with me.

    Pretty hard to start a flame war by elaborating on a point. ;)

  3. "Convention over configuration means that the one stupid developer, on that other team that you hate dealing with, that always names things in stupid ways, is forced not to be a big, stupid, dumbface."
    I see what you did there ^-^

  4. The folder conventions that you are talking about is default in ember or I need to use something like ember-cli?

    1. That's specific to Ember-CLI, however Ember is still obviously *very* convention-based even without Ember-CLI (checking for specifically named things on the application, etc)


This form allows some basic HTML. It will only create links if you wrap the URL in an anchor tag (Sorry, it's the Blogger default)