Infrequently Noted

About a year ago, I tried to invite PPK to the Dojo project. He declined at the time, stating that he doesn't find libraries useful, which seemed a reasonable thing to say. If it doesn't fit his tastes, so be it.

Today, however, he went a step further (via ajaxian), stating that neither client side nor server side programmers are qualified to write the coming generation of responsive webapps. From a semantic standpoint, I think I might agree: if someone considers themselves just one or the other, they won't be able to do it. But I don't think that's his point, and on that point I think he's dead wrong. I think Mark Wubben and Bob Ippolito's comments on the ajaxian post are dead on.

Sure, JavaScript isn't a "fun" language unless you magically wind up using it in a non-browser environment (in which case you should probably be using Python anyway), but to do "real engineering" in a browser, you need a "real engineer" on the client side. Someone who gets HTTP, JS, DOM, whatever your server-side language is, and can shoot the shit about TCP/IP stack config paramaters on whatever your server-side OS happens to be.

Anyone who can credibly claim to have written a non-trivial amount of idiomatic JS (can you explain a closure? how does prototype inheritance differ from class-based inheritance?) probably fits this bill, and if not, they already show the ability to pick up difficult concepts and will be able to fill in where they aren't already experts. The question isn't "server side" or "client side", but do you come at it from an engineer's perspective, regardless of what side you're on?

As a library author, I find his remarks about them interesting but still naive. I know PPK doesn't like libraries, but they tend to be written first and foremost for the benefit of the people who wrote them: e.g., just the kinds of engineers he dismisses on both sides of the HTTP stack.

Frankly, good engineer's don't re-invent the wheel for kicks, and so a good engineer dropped from a server environment to a client-side environment will instinctively look for good tools. Implying that one has to suffer to get things done on the client is just plain wrong. Suffering doesn't make one a better client-side engineer. Engineering things does.