We Are Pioneers: the Journey to Ember.js

Any positive post about Ember seems to be float higher on the front page than it deserves...

I dated Ember for a while but I ended up married with Angular.

Ember is really cute and charming. When it works it is all magic - but when it doesn't it is way harder to figure out what is wrong.

So far, Angular seems to have a stronger foundation and will eventually catch up in beauty.

Isn't the text's introduction slightly glorifiyng? It tells the story of the noble settlers who had to fight troubles and sometimes even lost their lives - it leaves out that they actually have slayn all the indigenous people whose country they invaded. Colonialization of North America isn't just some exiting bunch of tales about adventurous pioneers, but actually a quite cruel story of suppression and murder. So maybe you should consider some other entry point for your text.

Grandiosity aside, what's pioneering about Ember.js? AngularJS, Backbone, Meteor and even Dojo and YUI I think all have better claims to being pioneers. As much as people hate Rails and the Rails community for having this attitude, at least Rails had that wow factor when it came out and there wasn't really anything like it out there. Ember.js? What does Ember.js have right now that AngularJS or Knockout or Backbone or whatever didn't have a year ago? AngularJS is both easier to get started with, offers much more flexibility and is much more interesting from a technical standpoint, not to mention that its feature set is much deeper.

This is like Apple's marketing, except without the product and aimed at developers.

I've been building apps for a few years now. I started by taking established projects and making them fit a specific role. Later I started building them from scratch. Now I'm starting to delve into the higher level "theory" behind making stuff like this. I put theory in quotes because it's not really theory, it's just observations made over years of experience, approaching theory from the bottom rather than the top.

What I learned from doing it that way is that there's a level of process abstraction which is higher than "best practices" but lower than pure CS theory. It's the level at which documents like 12factor.net are. The best word I've found that describes it is "opinionated". You want software that's opinionated enough to drive design decisions but not so much that it dictates them.

People are very proud of this sort of understanding because it is hard-won. When you look at 12factor.net, if you haven't been developing for awhile, you might not understand just how useful a document it is. You might be thinking top-down rather than bottom-up. But if you're like me, you've seen lots of anti-patterns in the things you've built and long for a way to get them out of your apps.

That's where frameworks come in. They make decisions for you that cut back on those anti-patterns. Very useful if that's what you're looking for. When I first started building, I found Rails to be too much bloat, too complex, so I used Sinatra. Now I have a large project that I'm finishing up, and I wish now I'd used Rails. You can build an opinionated Sinatra app, but why when you could just use Rails?

You don't think you need someone else to make decisions for you, until you do.