I've been working on AngularJS projects for a while now, and a friend recently told me about EmberJS. Here are some reasons why I've chosen to stick with Angular instead of giving this new framework a shot.
Here's the thing- I didn't even know Ember was really a thing until after I learned Angular. Angular is not easy, and there are quite a lot of concepts to wrap your head around. However, I took the Angular 102 class at New York Code & Design Academy, and this really opened my eyes to how to correctly use things like custom directives, factories, services, etc. to build the things you need to build. Moving from one framework to a different one involves a major revamping of your skills and time relearning how to approach building a web app- a huge amount of work for something that might not eve pay off.
Ember enthusiasts act like it's catching on like wildfire and developers are flocking from everywhere to become Ember devs. Well... not so much. Sure, things may change, but as of the writing of this post Ember is still being dominated by Angular in terms of google searches, stack overflow tags, and production apps out in the wild. Take a look at the charts for yourself.
Yahuda who? One of the main contributors to Ember has also build jquery and ruby, two frameworks that kind of make me want to vom just thinking about them. I'm sure he is a great dude (athough I really hope Ember is nothing like jquery), but the Google Angular team just has so much more behind them in terms of really being able to put in the time (and money) to build a truly remarkable framework. You can tell Misko and the others are really passionate about the framework. It's a double-edged sword being backed by a profit-maximizing company. For example, look how Adobe basically blasted actionscript 3 in the face with a shotgun. It will be interesting to see what happens with Angular in the long run, but I believe the core team (and company as a whole) are passionate enough to keep Angular going for many years to come. Ember, on the other hand, seems to be a hipster two-way data binding framework, and it's users will constantly get into arguments trying to prove why it's "better than Angular".
Back in the day I used to say that Actionscript 3 was like poetry. It really was a joy to from a coder's point of view to write as3 code once you knew what you were doing. As I become more familiar with Angular I can sense the same feelings beginning to settle in. After looking at some Ember code, my initial reaction is, "ew". It seems Ember adds a whole lot more characters to the html markup. Also, the framework is dependent on Handlebars, so you're using those doubly curlies all over the place. I also actually like the directive, factory, and service naming conventions of Angular so the ruby/cocoa names of things in Ember seem a little foreign to me. I actually know a few people who have worked extensively with both Angular and Ember. They say you can build whatever you want in both, but Angular's syntax is like a nice home-cooked italian meal while Ember is a bunch of cocoa powder and milk thrown into a blender. If you don't believe me, try them both! (and do let me know which syntax you prefer).
Towards the end of my flash days I started really egtting involved wiht FlexUnit. I had been reading about TDD, eXtreme programming, and various unit testing techniques. I was glad to see that Angular from the beginning was built with unit testing in mind. It has karma, protractor, and uses the popular Jasmine test library. Ember got a lot of heat from the community for not being set up properly for testing. They now recommend QUnit. QUnit?? What is this, .NET? Haha. Well, QUnit really isn't that bad as it's pretty close to JUnit and the classical XUnit frameworks in it's syntax, but I just started getting used to the BDD style of "describe - it" testing frameworks. :)
At the heart of both Angular and Ember is two-way data binding. Commonly in Angular, developers are warned that when you should not have more than 2000 bindings at a time or this can noticeably slow down the response time in your browser. When I first heard that I thought, "ok. That's a shit ton of bindings. I doubt I'll really ever need that many". But then Ember comes along and says, "Oh btw guys. In Ember there is no limit to the number of bindings you can have here!". That sort of makes you want to go back to the angular team and say, "guys, what the heck are you doing?". They've had this debate many times, and it really just comes down to better performance in different situations. However, the 2000 binding limit on Angular really seems to be a feather in Ember's cap as they prance around calling themselves, "the JS framework for LARGE applications". It will be interesting to see in Angular 2 if the creators decide to impose this 2000 limit still or if they try to bring things up to the same level as Ember in this particular area.
The posts on this site are written and maintained by Jim Lynch. About Jim...