tools as the cause of, not the solution to, all the web's speed problems

Daring Fireball linked to Tools don’t solve the web’s problems, they ARE the problem.

Here's a thought that echoes something that's been on my mind of late:

Still, the native avalanche has made us web developers insecure, and I think the search for ever-longer toolchains that solve ever-more-obscure problems is our answer to this insecurity. It’s the wrong answer, but there you go. (The traditional disdain with which server-side disciplines, especially Java, regard web technology doesn’t help here.) 

We use tools in order to prove that we’re seasoned and mature, and not because they solve problems that we couldn’t solve on our own with some basic knowledge of CSS and JavaScript and spending a few days extra on each project.

He talks a lot about the difference between front-enders and back-enders as well. I've had some enlightening conversations lately, and I think that is a strong factor. The narrative is more complex than "server side people want things so they don't have to think about the traditional web frontend structures of HTML5, CSS, and js" though, because those "back-enders" have a kind of odd alliance with the kids with shiniest tools on the block. (The back-enders see where big parts of the action are moving to, and want in on that, the "shiny tool kids" want the respect and authority the server-siders have enjoyed, and are willing to sacrifice their save-compile-run loop to get that.)

Still: a lot of companies making interesting things have people who are very excited about Angular et al, and because I want to work with these people I need to have fluency in this kind of toolset. I've been inadvertently creating friction at work by asking if we should consider alternative approaches (ranging from no-framework/microframeworks to even more opinion frameworks like ember.js, which in some ways seem more stable than Angular at the moment) but am not doubling down to renew the Angular knowledge I had last year.

So I've been looking for better books and tutorials than I had last year. A stackoverflow on “Thinking in AngularJS” if I have a jQuery background had a point that has stuck with me, in understanding how the Angular view veers from my comfort zone:

1. Don't design your page, and then change it with DOM manipulations 

In jQuery, you design a page, and then you make it dynamic. This is because jQuery was designed for augmentation and has grown incredibly from that simple premise. 

But in AngularJS, you must start from the ground up with your architecture in mind. Instead of starting by thinking "I have this piece of the DOM and I want to make it do X", you have to start with what you want to accomplish, then go about designing your application, and then finally go about designing your view.

An interesting point! I've been thinking that some of my resistance to Angular's paradigms comes from my old CGI-based history, like in the 90s, when all the work was done serverside and then brought to the browser in page-size chunks.  Then, around 2010, I got my first deep work experience using jQuery and CSS to move more of that work to the browser. Man was that fun! We backed away from our initial under-engineered attempts at SPA, but the idea that everything was static except for the info coming from endpoints was empowering.

I still tend to view the DOM as a fundamentally static thing, a view loosely coupled from the controller, with the controller mediating to the single source of truth model at specified points in time (in a kind of event driven way, so very natural to decorate with transitions and animations).

Angular turns its views into basically enhanced versions of the model. To me this seems a little jumpy and skitterish, and I'm not 100% at ease with how the DOM as implied by the unparsed template is utterly different than the DOM I see in the element inspector, but I'm warming up to it as a functional paradigm. 

And that's why that quote feels like a different world to me. Most jobs I'm on, they show me a comp (either image or HTML) of the finished webpage, and say "make this!". Designing from the model on out to the views is not a luxury I've often had. (And in practice, I think only internal-use, Plain-Old-CRUD-ish apps would alllow such a thing, without input from a designer.)

I've been working through thinkster's A Better Way to Learn Angular.js and its been going pretty well. I like that it dips into the core angular docs for some of the lessons.

I think building up this kind of flexibility is good exercise for my brain. That's the silver lining to giving up the feeling of smart I get when I'm making cool stuff from inside my comfort zone.