Thursday, January 12, 2012

on smaller frameworks

(This is a response to Gordon L Hempton's blogpost Javascript Frameworks Are Too Small)

Interesting article link you posted. Why don't we have as many layer of abstractions for web development? One answer might be, each of levels Queru describes is built on a REALLY reliable and well-engineered level beneath it, and there isn't that kind of solidity under JS/HTML5. But I think the other answer is: it's not necessary, at least for a certain kind of developer.

I can't even tell you how foreign I find your proclamation given the choice between two frameworks with equally well-written code, I would probably opt for the larger framework

There's a valid outlook that's the opposite of this: it says, I want to learn as little new as possible to get the job done, to minimize the mental load my tools are causing me. Toolkits with lots of abstraction often don't have good power/weight ratios; they're not much more expressive than more basic toolkits, but there's a lot more you new unique knowledge you have to keep in your head to use them properly (lest you become one of those Microsoft-y types, who can do decent stuff but have NO idea what's going on under the hood, or how to fix it when it goes wrong in a deep way.)

I think more abstract toolkits tend to program in nouns... "configure me correctly/learn which of my calls will do your bidding, and I'll do all the "tough work" and you can keep commanding on high rather than dirtying your hands in the trenches". But the cost of that comes in debugging, where suddenly the result of your bug is more likely to be farther away -- "physically" in the files, mentally in the abstraction -- than if you kept your toolbox nice and light and focused on the solving the problems that are actually a pain in the butt to keep resolving. (jQuery being one of the shining examples of awesomeness for the latter.)

I agree that "a larger amount of energy goes towards dealing with the frameworks involved, rather than the problem being solved" but not in the sense you mean: finding people who know the intricacies of a new stack, or training up people to get that knowledge, is the expense...


  1. It is dangerous to treat "learn as little new as possible to get the job done" and "minimize the mental load my tools are causing me" as the same thing. They are not.

    There are things that take effort to learn that will simplify your life once you do; there are things that take effort to learn that just make things worse. There are things that come easily and natural that are also simple and clean, and there are things that are easy to do that lead to terrible messes and unintended consequences.

    There's a great talk I watched the other day by Rich Hickey called "Simple Made Easy"; if nothing else, it's worth watching for his definitions of "simple" and "easy".

    I'm not entirely convinced that absolute simplicity is always the best goal at every level of programming, but the presentation gave me a lot of food for thought. (I've got a blog post of my own to write about that.)

  2. I'll try to get time to watch the video!

    I think w/ the simple easy dichotomy, it gets into the specifics of what's core (CSS,HTML5,jQuery) and what pretends to simplify by submerging the complexity...