Credit for this post goes entirely to Yehuda Katz_

A couple weeks ago, I took the plunge and switched to Ember (Ember 1.4.0, to be precise). It wasn’t the first time I tried to make the switch, and I had pretty much written it off entirely.

Why? Because the past few times I tried switching to Ember, I took the advice of a master Ember user, and quickly sunk into the quicksand of trying to learn a new tool. In every prior attempt, I gave Ember a few days before I gave up. And every time, I managed to get virtually no work done the entire time, spending about 90 percent of my day fighting with my framework (a more charitable way to put it would be “learning my new framework").

Invariably, the master Ember users that were helping me make the switch would encourage me to stick it out. “If you just give it a few weeks, you’ll never want to switch back.”

The trouble was, I had work to do. I could only switch platforms if the new platform did not significantly impede on my day-to-day work. I can already hear the responses: "That’s simply impossible. It’s a new JS framework designed for advanced users. You’ll just have to put up with the pain until you get used to it."

Here’s the thing, though: I didn’t really have to put up with a huge amount of pain when switching to Angular or Knockout for the first time. In fact, it was downright pleasant.

The last few times someone tried to get me to switch to Ember, I issued them a simple challenge.

Can you tell me a way to switch that will not significantly reduce my productivity for the first few weeks.

It wasn’t a challenge that was intended to fully shut down discussion. When I really thought about it, Angular wasn’t doing all that much for me. It was a glorified jQuery wrapper which had working two-way binding and understood basic templating (most of the time).

I don’t actually use "components" all that often, or all that many "bindings". I don’t mind the extensibility of Angular, but I’m not a hardcore Angular hacker myself, meaning that I’m ok with any framework that has the same level of extensibility that Angular has (namely, all of them).

Despite what I considered a relatively reasonable request, my challenge was met with disdain and even anger by most of the people I talked to. “If you feel that way, Ember probably isn’t for you.” “You’re learning a new FRAMEWORK for God’s sakes. Of COURSE there’s going to be a learning curve.”

I had written off the entire sorry affair.

A few weeks ago, Rob Sullivan told me that he was playing with Ember. His explanation was that he had seen a number of people be really productive with it, and he was curious. Rob Sullivan is definitely willing to put up with more pain to learn something new than I am, so I issued the same challenge to him.

Perhaps because he wasn’t steeped in hardcore Ember hacker lore, he didn’t angrily dismiss the entire premise of my question. Thinking about it a bit more, I realized that most of the people who had tried to get me into Ember had suggested that I dive in head first. “First thing: unlearn what you know about MVC.” “Don’t use the DOM directly. Force yourself to embrace Ember's conventions.”

Rob convinced me to use Ember for the first couple of days pretty much exactly as I use Angular (with the exception of having to deal with weird routing issues and minification). I installed Grunt with grunt-contrib-handlebars, grabbed the most recent Ember builds, and was off to the races. (I should note that I installed topfunky’s Fire Up Ember screencast, which definitely helped with a very common workflow that I find it hard to live without).

For the first day, I clunked around by using commons sense, clicking and highlighting things, and spending most of my time in trying to get Ember to load up. It was slightly less productive than Angular, but mostly in the range of what I’d expect switching to a new Javascript MVC Framework. In short, while I felt a bit out of sorts, I was able to get plenty of work done that first day.

As the days went on, I learned a few commands here and there. The first big one for me was Router.resource as in MyApp.Router.resource("user") (it means: "create some REST-y routes even though we're on the desktop"). This singlehandedly made up for most of the productivity losses I was feeling from learning a new tool. Throw in Ember.compute.any, Em.A(), Ember.$.getJSON(..), MyController.reopenClass(..) and DS.RESTSerializer.extend and I was already quite a bit more productive than I had been in Angular.

Sure, I’m still plodding around in some cases, but only a handful of days later, using Angular for anything feels clunky (most commonly, I try to use $scope or ng-app).

I was able to get here because I banged my head against the wall until I saw stars and a little blood, and a whole slew of other common idioms, instead of grinding to a halt and trying to switch all of my practices at once.

To those who would say “that’s obvious; of course you learn Ember incrementally”, I would simply say that having spoken to a number of Ember users in the past, I never got that advice. Instead, I got a lot of advice about forgetting what I know about MVC, my "Road to Damascus Moment", how "URLs are more important than anything", and "Angular sucks how could you like it". People just couldn’t stomach the idea of me continuing to use an outmoded practice (like $.getJSON()) when Ember had much better tools available just a (huge volume of) memorization away.

To those who are considering using Ember, my recommendation is to use The Latest Version and get some ice, some bandages and a tall bottle of Maker's Mark. Very quickly, it will become obvious that there’s a better way to do all kinds of things, and you can pile on the newly found efficiency once you’ve successfully made the switch without losing the ability to do work in the short-run

Note: This is an (very, very slight) alteration of an original post by Yehuda Katz: Everyone Who Tried to Convince Me to use Vim was Wrong