Monday, May 18, 2015

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.


  1. Interesting, but there's so much in that article on quirksmode that I disagree with.

    First, is his usage of the word "tools". That has a pretty standard meaning in development, but when we uses it, it sounds like he just means "frameworks and libraries." Because if "tools" are what is making the web slow, then I assume he's NOT talking about IDEs, build scripts, test harnesses, etc. Those are tools, and have nothing to do with the web being slow, and don't require end-users to "download and execute" anything. So while maybe I'm just being pedantic, his terminology derails his argument from the beginning.

    Second, tools (using his meaning, "libraries and frameworks") aren't the problem themselves. Poor architecture and design is the problem. Is that related to specific libraries? Sometimes. Often it's just stupid design choices. (for example, yes, Angular is slow. So blame Angular, and use something else. But the knee-jerk reaction of "oh no, tools!" is oversimplified nonsense.)

    Third, I don't think that the crazy push actually comes from back-end developers. Most back-end developers that I've dealt with repeatedly mock the world of ever-growing and changing javascript frameworks. Most would be happy to churn out a simple html-based web page with a little bit of javascript to "make stuff work". They laugh at the hipsters with their 47 javascript frameworks and 30 different npm modules that you have to install just to make a simple dynamic website.

    The part I do agree with is the 2nd half of his solution: "Teach the newbies proper web development." But once you understand the principles, why throw out tools if they are used properly? Would he advocate throwing away compilers also, and make everyone write code in assembly (it's faster, right? and we've run into slow programs because of slow languages and frameworks. So let's throw away ALL the tools, and write everything in assembly!)

    I just think he's a bit off his rocker, honestly.

    1. Nathan, thanks for your thoughtful response. I agree with several points of your critique of the (and when I've been posting links to my own blog, I've been disclaiming it a bit)

      He IS sloppy - or perhaps literally speaking a different language, a bit - about the use of "tools". Similar for "slow". (And "render speed" seems to be on some folks mind, like Gruber et al, and the people who dig React, to a degree that has not been on my radar in terms of stuff I've had to worry about, except in one isolated case of a MASSIVE table of data) But I also think there's a high level of correlation, of the use of heavier tools (preproccesors, lints, harnasses) and the use of more abstracted frameworks... and similarly between heavy frameworks and render times.

      And maybe I project my own thoughts too much onto his, but I see his talk of libraries/frameworks as parallel to my preferences for microframeworks that are easier to mentally model and keep track of. He and I are both a little concerned about another knee-jerk "more abstraction and complexity will make this easier" line of thinking that seems prevalent.

      I disagree with your about the "back-end dev" push, a bit; I have seen a lot of server-siders who are like "I don't want to learn HTML and CSS and js patterns to do this!" and therefore fall for the allure of a framework that promises to abstract that away. (Ext.js comes to mind for this; other frameworks like Angular sort of split the difference)

      Re: throwing away the tools after teaching newbies properly... I think the argument for doing that is about keeping things simple, and clean, and easy to mentally model. Which I think can lead to greater maintainability in the long run. That's some of why I tend to err on bespoke solutions over framework of the month; when I go back to debug some framework of the month, there's so much more I have to remember to fix it, and if it's coding in a declarative way, the stack traces and maybe even the DOM structure is going to be much harder to trace to the root of the problem.

      I think the "so lets write in assembly!" is a bit of a strawman / slippery slope argument that I've seen elsewhere and kind of resent. (Along with the coffescripter's "js is the asm of the web and if you're coding in it you're doing it wrong) DOM + js is wonderfully expressive, and combined with a good library or two to simplify some tasks can get SO much done.

      It's funny how I see stuff like Angular and, going deeper, Grails, at these nifty protoypers that have a sweet spot of CRUD, but the coolness of those early lessons is paid for later by all the moving parts and syntaxes they insist on for mastery. And that CRUD stuff is pretty easy to do in other ways.

      Of course the other argument for frameworks is that it gets teams solving the same problems in the same way, but man.. in Angular land, it seems like there's always about 4 or 5 ways of doing something, and to read other people's code you have to be fluent in all of them...

  2. I agree that my statement about assembly is a bit of a straw man. But I was reacting to his over-zealous statement of "throw out the tools" (in contract to your reasonable statement of "combined with a good library or two to simplify some tasks can get SO much done.") My point is that his hyperbole detracts from his argument in the same way that saying "just use assembly" does.

    I do also completely agree about your statement about frameworks and their CRUD sweet spot that eventually causes more headaches. That was our experience attempting to use Angular for a bigger project. But effective programming is all about picking the right level of abstraction, and his saying "don't use any abstractions!" isn't always the right answer any more than Angular is.

    And you might be right about back-end developers, I guess. Some of us are used to languages with UI toolkits/apis that aren't quite as painful as the web :)

    Either way, thanks for a reasonable and interesting discussion -- those don't always happen here on the internet :)

    1. Yeah, I do wonder if he's a hardcore "pure js" minimalist (and I've seen some interesting tutorials about "how to do basic queries without jQuery, now that browsers have matured a bit") or taking a less extreme stand on the frameworks vs libraries spectrum - whether you write the code that calls the package, or you write the code that the code in the package calls...

      Boy, I hear at least as many people saying "yeah Angular was too much and a headache when we went to use it" than "no we dig it" - but I do have a few really strong fans of it, so I'm hopeful. (On the other hand I know even Wicket has its fans, so there's no accounting for taste ;-)

      Sometimes the Angular/CRUD sweetspot reminds me of small companies in the 90s who'd make great bank just writing little Access or MS-SQL wrappers with trivial VB Frontends.

      I do appreciate the tone of this discussion, definitely, thanks for taking the time to comment in the first place... sometimes writing a non-superstar blog feels like yelling in the wilderness.