April 17, 2016 Log No. 601
Directives, Transclusion, and Scoping, Oh My
Recently I had to learn some Angular to work on (and eventually build a scaled-down demo of) a work project. Having done most of my prior projects in Backbone and with most of my current focus on React, the Angular angle (heh heh) was a bit of uncharted territory. Nevertheless, always fun to learn something new, right?
Well, kinda.
Angular is…not the most intuitive to learn right away.
My first impression was just that the terminology sounded like a rocket scientist came up with it. “Directive”? “Transclude”? What was wrong with simple one syllable words? But ok I could overcome the somewhat dubious vocabulary. What about functionality?
As I found out, Angular’s setup is kind of a double-edged sword. It does a lot for you, no mistake–its implicit 2-way bindings can be very helpful when initially getting variables into a view. But as with most things that require minimal configuration out of the box, there’s a relatively rigid underlying structure that makes customization more troublesome. Angular seems to heavily enforce its version of “MVC” (split out across directives, views, controllers, and services), more so than Backbone (which has an MVC structure you can use, but don’t necessarily have to) or React (which, in vanilla form, seems to be mostly view logic), so that moving beyond simple ‘variable output to screen’ took me some time. Communicating between controllers and tracking state didn’t seem entirely intuitive, mostly because of how much emphasis Angular puts on scoping. (Even now, I haven’t settled on a efficient way to debug Angular, aside from console.logs and alerts. It’s near-impossible tracking down where a variable is in the scope. And there doesn’t seem to be a good Chrome debug tool even now, much to my surprise.) So, needless to say–there was a fair bit of trial and error.
But that’s not to say Angular is definitively worse than other front-end frameworks I’ve used. There were some pretty cool out-of-the-box features too, the 2 of which I appreciated the most being filtering and sorting. Those worked way easier than I expected, and defining custom filters and sorts also wasn’t difficult. The 2-way binding was actually very snazzy and made attaching functions to events even easier than the other frameworks, to the point where it took some time getting used to regular JS .bind again. The ability to use regular html and just inject directives into the tags made the code easier to get into and understand as well–for me, I know a lot of people hate reading/writing html for whatever reason!
So I ultimately made my peace with Angular after a stressful first few days and was able to work through the project at a steady clip thereafter. But there definitely was a marked mindshift from the React components I was working on before–and am now back to. That just goes to show how different major front-end frameworks can be. And I didn’t even touch on Angular 2 yet, which is, as far as I’ve heard, almost completely revamped. But yeah, it was fun to try out something new.
Discussion Jump to comment form