You’re Fat and I Hate You

So this has happened to me a few times recently (mentioning no names) — I read up on some neat trick or other that somebody’s figured out in JavaScript, and I’m like ooh that’s cool, I wonder how it works. So I follow it up, only to find out that the author doesn’t know how it works, and reading their code throws no light on it either, because most of the work is done by an external framework.

It irritates the hell out of me that so much modern JavaScript development hinges on frameworks. Not because there’s anything wrong with that in pragmatic terms, but because I’m interested in the mechanics of things, and programming with frameworks obscures the mechanics. It’s simply too laborious to work through that convoluted chain of dependencies and see what a script is actually doing. And the code of the framework itself is generally optimized to such an extent that it’s virtually illegible — great for speed and efficiency in practice, but very difficult to read and understand.

Of course, from the point of view of developers using frameworks, that’s exactly the point. The mechanics are supposed to be obscured so that the application is easier and quicker to create. And of course, the actual end-users shouldn’t care at all — just like I don’t care how my car works, I just want it to go.

But if I were a car mechanic I might have a different viewpoint … and here we are! And what we find is that a whole generation of developers are now producing sophisticated applications without a deep understanding of how they work. I guess I probably sound elitist to criticize that, and maybe I am, but it still bugs me, because it makes so much of that development useless to me. I simply don’t care that X has made a better image previewing script using jCloth or whatever — I’m not impressed, because as far as I’m concerned, they didn’t write it; anymore than I would be impressed by someone producing music using the presets on a Casio keyboard (ala Fatboy Slim, though in his case it was a Yamaha keyboard!).

I might still like the music, but I wouldn’t consider them a musician, and wouldn’t be able to talk to them about the finer points of music theory.

What if there’s a neat trick I want to use, or a particular approach that makes sense, but I can’t use it without introducing dependencies into my code — dependencies that bloat the codebase, and slow the application down. JavaScript is already an interpreted language, and frameworks are interpretative environments, so applications written using a framework are essentially using meta-code — code which is interpreted by an interpreted interpreter! How can something which increases the work of the interpretor and the size of the codebase be a good idea?

It all reminds me somewhat of a TV show called The Biggest Loser. The show is like Big Brother for people with chronic weight problems — each week they try to lose weight by crash-dieting and over-exercising, and each week one of them is voted out, with the last remaining person being crowned the biggest loser (great pun huh!). But the show has nothing to do with health or fitness; the program makers don’t ultimately care about the well-being of the contestants, or the bad example they’re setting in encouraging such intensive and unsustainable weight loss. The show isn’t about any of that, it’s just about let’s all laugh at the fat people.

To my mind, framework-driven development is analogous to this. It may produce quick and easy results, but it isn’t really programming, and it’s of no academic interest to me at all. I don’t care if it makes good TV, I care about the substance beneath.

I’m interested in the language itself, and I find it extremely frustrating that so few people are actually writing in it anymore.