Speak JavaScript or die

2006-07-21 01:24:00

Another interesting couple of salvoes in the ongoing "is not, is too" argument of whether or not Real Web Developers have to know JavaScript, or if it's okay for them to rely on server-side 'helpers' and JS libraries.

Over at DOM Scripting, in a post that seems to be aimed primarily at guys on the design side of the continuum, Jeremy Keith encourages people to start picking up JavaScript because it's just plain necessary to their jobs these days -- "Learning JavaScript is something that you can postpone, but you really can't avoid," he says.

He also links to a nice rant by James Bennet about the state of Ajax support in the Django Web development framework. James's post seems more aimed at the server-side developer side of the equation, but he's also firmly in the 'learn JavaScript, dammit' camp, saying he doesn't think that Django needs server-side 'Ajax helpers' that generate JS.

He uses some even stronger rhetoric:

In 2006, if you call yourself a "web developer" you have absolutely no excuse for not knowing JavaScript. And if you don't know JavaScript, you have absolutely no right to call yourself a "web developer".

Pretty strong language (and pretty tailor-made for getting a nice, heated discussion going in your comments).

I'd firmly agree that as Ajax and client-side development become more important, you're putting yourself at a serious disadvantage if you don't develop a decent familiarity with JavaScript. To me it just seems like one the basic tools used to create a properly interactive Web application.

On the other hand, if your needs are really, really modest, you might be able to get by with relying solely on 'helpers' or copy-pasted code from the how-to for some JS toolkit. Say you're a sys-admin who just wants a bit of drag-and-drop fanciness in your Web console app (and you don't care if it's unusably slow or maybe unreliable in some browsers) -- you might get by fine with stuff from the Scriptaculous effects library, or using whatever RJS helpers Rails offers for that.

However people who refuse to take those training wheels off are limiting themselves to a pretty tiny swath of what client-side JS code can do. People who actually know JavaScript and code their own will be able to produce vastly more powerful interfaces for their apps.

And I will also (uncharitably) submit that if you want all the nice benefits that JavaScript-driven Ajax can provide you, but you somehow find JS so unbearably icky that you just can't bring yourself to touch it, you totally deserve what you get when something in all those layers abstracting away the JavaScript 'ickiness' breaks.

The toolkits actually written in JS are at least developed by JavaScript hackers who know what they're doing, so even though they may be leaky abstractions, you can count on them to get stuff mostly right. On the other hand, knowing what I know about JavaScript in general, and more specifically about the infinitude of opportunities for cross-browser weirdnesses in client-side code, I'm naturally a little suspicious of anything that purports to be able to transform a server-side language like Java or Ruby into perfectly working client-side JavaScript.

I'll also cop to the fact that some of this suspicion comes from being a second-language speaker of Japanese. I'll never be a native speaker of course, but I'm pretty comfortable that most of the time what I'm saying is grammatically and idiomatically correct. Speaking another language gives you a bit of insight into how hard it really is to translate one theoretically equivalent thing into another.

Whenever I think of GWT, I think of the gibberish BabelFish-translated e-mail messages in English I get occasionally from my mother-in-law in Japan. (I have no idea why she does this.) Because I can guess what the original Japanese probably was, I can actually follow these messages for the most part, but some parts literally make no sense whatsoever. So the idea of this flawless, magical conversion ("No more spending 90% of your time on browser incompatibilities! We solve that for you, like magic! No ugly JavaScript necessary!!!") -- still seems pretty much in the category of sci-fi conceits like the universal translator or translator microbes.

Actually I'm sure these "helpers" probably work really well within a fairly narrow band of functionality. Just like those computerized translation devices our soldiers are carrying around Baghdad are really good at spitting out preset phrases like "put your hands in the air" or "stop where you are." But if they wanted to expand that dialog into a discussion of Arabic history or art, they'd be SOL.

So if you have any intention of doing a seriously interactive Ajax-style browser-based app, you're going to have much greater power, and much larger range of possibilities open to you if you take the time to become fluent in the actual language of the browser. And despite what the inevitable pompous language bigots in #ruby-lang (for example) say, JavaScript is quite a nice language -- the syntax is not nearly as clean as say, Ruby or Python, but it's not at all icky and is actually pretty damned fun.


This is the blog for Matthew Eernisse. I currently work at Yammer as a developer, working mostly with JavaScript. All opinions expressed here are my own, not my employer's.


Previous posts

All previous posts ยป

This blog is a GeddyJS application.