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. One of the main contributors to Ember.js bragged about how great Ember was because it was very close syntactically to cocoa and ruby. Ok... I have never really used cocoa or ruby, particularly because of the weird syntax (and poor performance in the case of ruby, but that's for another post). It seems to me like that these few people were comfortable with cocoa and ruby so they tried to force a square into a circle hole by trying to make javascript/html development like these other languages. Angular by contrast tries to extend html and javascript to give you a better coding experience for web development without trying to make it like an existing language or platform. 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. :) I think it's pretty hilarious that when the Google Angular Team announced that they were making a version 2.0 and that it would be a complete rewrite of the framework there was an overwhelmingly negative response from developers. The naive coder was saying, "What the hell? I just learned all that Angular crap-ola and now you're throwing it all out the window for something else??" Well, not quite. Although there will be differences, I think many of them will be under-the-hood and involve improving performance of the framework (including a react-like virtual-DOM). If you are using best practices in Angular 1.X (like Controller as syntax) then you shouldn't have too much trouble moving over to Angular 2. I'm also interested to see how the "one codebase, deploy anywhere" promise for angular 2 will work. I wonder if it somehow works with Ionic. Having a truly universal web app that can be quickly packaged for app stores, TV's, and other devices would be really, really awesome. And finally, I'll admit that when I started taking web development seriously I was coming from an as3/java/c# background- all statically typed languages. When I got into the Angular 1.X world, everything was in Javascript so I sucked it up and got comfortable with Javascript. Although I don't miss the data types too much, I am still interested in using Typescript more in the future. 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.
0 Comments
Your comment will be posted after it is approved.
Leave a Reply. |
AuthorThe posts on this site are written and maintained by Jim Lynch. About Jim...
Categories
All
Archives
March 2023
|