I admit, angular.js has not come as easily to me as I would have liked.
So it bums me out, because the ability to pick up new technology is important.
On the other hand, some technologies just work better for me* and besides it's not like it's the first platform I was a bit slow to pick up. And on the third hand: some technologies just aren't that great (and some have fallen into the wastebin of history) and maybe I should trust my instincts.
EJB 1.0 sticks out in my mind as one of those.** "Wicket" for doing Web UIs in Java was another one.***
But Angular has a lot of industry momentum, and a few of my friends REALLY dig it. More importantly, my company seems dedicated to it right now, so I need to dig in. So my excuse for this rant is maybe by isolating the differences between Angular and how Kirk Thinks Things Should Be Done I can reset to a beginner's mind and set aside those blocking assumptions.****
In general, coding seems to divide into two camps: programming via verbs, and programming via nouns. The first camp is good old "imperative programming"... tell the computer step by step what to do. The end goal of the second camp is declarative programming: tell the computer what you're trying to do in broader terms, and let it work out the details of how to do it.
(For a while, "Object Oriented Programming" seemed the main path to that promised land. And OO was *so* assumed to be The Way, that when I saw this piece in the early 2000s, it was kind of a revelation: Object Oriented Programming Oversold. That site looks like a Dr. Bronner's Soap level of rant, but I think it has some truth: my strongest take away from that was while OO is good for some things, the assumption that it was the ultimate way of coding the universe sometimes came at the cost of industry focus on other technologies, like relational databases. And also, it's ok to challenge some industry assumptions.)
So some engineers prefer to look and see if someone else has solved their problem already with a reusable solution. I find a problematic synergy often results: there's a good chance that if it solves your problem, it's a solution that solves about a dozen other people's problems as well. And so there's some complex level of configuration to bend it to your will. So you've had to spend time understanding the problem AND a new configuration syntax - and God Help You if the thing still can't do QUITE what the requirements describe, because now you have to dive into a giant heap of someone else's code that's solving your problem as well as those twelve other folks.
And then when things go wrong: if you've done this programming of "set up your nouns" and then things go wrong, your stack trace is going to be a hopeless mess of someone else's code, abstracted out to high heaven, with the actual controlling bits tucked away in some memory structure, somewhere. A stacktrace - that critical tool for most debugging - is a pile of verbs: do this, do this, do this, and when that "this" is a verb related to your task at hand, you're in much better shape.
You can get around this, though, when the widgets you adhere to a Unix philosophy of "do one task, do it well" for your widgets, but keep the main program flow to yourself. Outsource those difficult bits, but always keep a firm grip on the main control flow, is my advice.
When I was working with jQuery and the DOM directly (using templating as a "do one thing, do it well" add-on, not the fundamental engine of control), it was very natural to put in animations and to do good user input cleaning, because everything happened as transitions: verbs that update nouns. Angular can do both these things, but IMO it doesn't happen as naturally. It took me a while to get my head around you could have different structures for the server communication and the interaction with the DOM (basically DTOs) because I think Angular likes to pretend it's this world where there's just nouns making the UI in the front, talking with the server in the back.
Alright, enough rambling. I need to clear my thoughts and return to a beginner's mind and try to see thing like an Angular person would... but it ain't gonna be easy. (Angular has a notorious learning curve and man am I feeling it) Sometimes it's weird: every time I witness someone tracing through some Angular, it strikes me as being more difficult for them than tracing through more normal code would have been. Yet somehow, once all the dues have been paid and the kool-aid drunk, all these negatives add up to a positive of a more sustainable and flexible code base.
* I can't even tell you how empowering my deep dive into CSS and JQuery in 2010 was.
** I knew I was in trouble when the book I was reading said something like "the EJB development team will generally consist of 5 people"... they tell me later versions got a little better.
**** Did I mention I have nigh-superhuman abilities to rationalize my personal preferences? But again, it's hard for me to isolate my biases and protective beliefs from the hard-won intuition born of two decades of programming.