You are here
Heretic: Our Reverse Angle on AngularJS
There’s a lot of developer buzz around AngularJS, and rightly so. Angular has pretty cool features right out of the box that can save web devs bunches of time. Two-way data-binding, dependency injection, and modularity are just some of the big features being touted for this framework. After scrolling through dozens of blog posts and articles discussing the benefits of Angular, we decided to take a look to see how it could fit into Enspire project workflow. Verdict: AngularJS needs some of its pointier angles filed down before it joins our toolbox. Why? Read on.
Intangibles
-
Parts of the Angular framework are described as “magic”. Maybe this term is used to abstract away some of the framework’s complexity. Or maybe we’re just grouches, but calling something “magic” implies that what goes on behind the scenes is unknowable, or too complex to convey to users of the framework. This is a problem with any open-source framework that is as complex as Angular, because it can make it hard to find shortcomings or areas where the framework doesn’t line up with project need. In the end, that can make a dev’s life harder. This feeds into our second concern:
-
There are very few people actually talking about limitations of AngularJS. Sure, there are plenty of people out there saying that Angular sucks (possibly, because it is unfamiliar). We actually think Angular is pretty cool and some of the things it can do take some of the burden off the shoulders of coders using it. But all frameworks have shortcomings. The fact that it is hard to find objective information regarding Angular’s pitfalls – perhaps because it’s new – makes it hard to evaluate the framework.
-
Getting started with Angular is almost insanely easy: download the library, add it to your app, do a tutorial, and bang you can use Angular. Ok, ok – almost every framework or library touts how quick it is to get started building apps. That leaves something very important out of the conversation, however. It takes a good deal of familiarity with AngularJS to build a medium to large app that doesn’t look like spaghetti (I’m looking at you directives). This makes it more costly, both in time and resources, to get new developers ramped up on a project which uses Angular and can present a barrier to entry for otherwise qualified developers.
Tangibles
-
The documentation is terrible. Quite a few people have mentioned this, and it really should be one of the things Google addressed prior to releasing the framework as 1.0. Word on the street is that documentation has been getting better and by 2.0 should be fantastic. But that doesn’t help now.
-
The two-way data binding which Angular is capable of is at once pretty cool and a potential nightmare. Having two thousand pieces of data rendered on the page seems like a large number and an argument can be made that having that much information displayed at once is bad UX and rightly so. Except that there are cases where you might have a great deal of information hidden until needed or even some large tables, grids, or other dynamic visualizations which easily hit two thousand discrete pieces of data very quickly. This is not something we would expect to encounter with every project but is a crucial bit of information when deciding which stack to use.
-
Directives are also a really cool feature of Angular and a necessity if you plan on building anything with more than a modicum of complexity. Directives can be hard to figure out, even using the documentation, but are what really drives the time-savings when using Angular. The main problem I see with using directives is that it is difficult to tell when a directive has completed (for something like an animation) without using something hacky like a timeout. It may not look to bad from a pasta point of view, but if you want consistency across the widest range of browsers and devices then this is really a no-go solution.
There are other issues with Angular including how the router works, lack of support for accessibility, 3rd-party library headaches, and consistency with TDD. But those can be worked around for the most part. I hope to find myself working with Angular one day on the right project, but for now there are a few roadblocks making it difficult for us to do so.
Link to story on the Enspire blog: http://www.enspire.com/heresy-reverse-angle-anglularjs/