thinking about angular and verbs and nouns and oo

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.

But of course, that's where Angular disagrees. Angular wants to be your UI's world and own your stacktraces at all times. It will invent new and arcane syntaxes at the drop of a hat. Sometimes I worry people who come to Angular without doing a lot of browser based UI work might not realize how easy some of the things Angular promises to make easy already are. (For a nice rant along these lines, check out Code of Rob's You Have Ruined Javascript that was making the rounds a few weeks ago.)

So that's one of my beef with Angular. The other one I have is this: it really tightly couples the DOM and the Javascript. It views the two, amalgamated, as the conceptual "View" of MVC. It's your nouns (visible in the DOM; less visible with scope variables) and your verbs all together in one big stew. I finally realized that my conception is that the DOM is rightly more static than that; the DOM should be more decoupled from the Javascript, with information only flowing two and from the underlying code in easy-to-track, specific points, not all over the place with a heap of watched variables and HTML snippets that kind of sort of know how to build themselves from that shared scope memory.

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.
*** Wicket assumed Java engineers were just PETRIFIED of learning even the most basic javascript, but were fine with html, so you'd have to make these carefully parallel nested Java/nested div HTML structures, and god help you if you wanted to make your own widget, you'd have to become master of this byzantine 7-step request/response lifecycle process.
**** 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.