How to Ruin/Fix JavaScript?

by | October 22nd, 2007

With the rise of Ajax lots of people are becoming quite excited about the JavaScript programming language. As skillful programmers who are new to JavaScript move beyond cutting-and-pasting snippets of code and actually begin learning something about the language, there are some common reactions that tend to emerge. We see these consistently in interactions with students and readers alike:

  • “Wow! I didn’t know JavaScript is (or could do) X.” This is the general refrain from folks who assumed that JavaScript was somehow a toy language to the point of being literally impossible to use for, say, writing a Quicksort algorithm. While we are not sure how exactly such an incomplete programming language could ever be thought to exist, since you only need a few constructs to represent ANY algorithm, there is an implicit compliment and discovery of value here by the newcomer that should be acknowledged.
  • “Well JavaScript is interesting, but I really wish it was like language Y.”  So now that a newcomer has determined JavaScript can really be used to program, the new coder may moan that it isn’t like Java, C, Ruby, Python, LISP, or whatever language they seem to think is a true, good, or at least familiar to them.
  • “Look this is a better way to write JavaScript!”  The new JavaScripter, having just discovered the real dynamic power of JavaScript, immediately races to “fix it,” either manually or by employing one of the numerous libraries out there that claim to do that for them. You see, JavaScript people clearly don’t have their heads screwed on right, for a variety of reasons:
    • The language doesn’t use class-based OOP style coding, and often simply isn’t elegant enough to use, so let’s use it’s dynamic and OOP prototyping nature to patch it up.
    • It doesn’t have object X or construct Y that we have in Ruby/Python/PHP/etc., so it blows, and we need to make it “suck less.”
    • It is discovered underneath to be a functional language like LISP,ML,Scheme, etc., but it lacks the sweet terse elegance that real functional programmers crave. No worries, we’ll figure out how to reveal this awesomeness to the world and chain functions to infinity and beyond!

Now of course we poke fun at those who in Crockford’s opinion go against the grain of the language. However, it does give us the opportunity to show that the key to the “fixes” is exactly what makes JavaScript interesting, it’s dynamic – you can override things.

As an example of JavaScript’s dynamic nature you might notice if you write/read JavaScript that document.write() is seen but document.writeln() is rarely seen. The reason is pretty clear, they appear to do the same thing.  And given that you are writing to an (X)HTML document, typically the whitespace introduced by the writeln() method just doesn’t have an effect, so why bother with it? Of course, if you wanted to fix this, you could make the method insert a <br> tag for you. Given JavaScript is dynamic we can easily do that like so:

document.writeln = function (s) {document.writeln(s + "<br />");};

Fixed! Of course you take this idea to the n-th degree, like some libraries see out there, and it turns JavaScript into something that, well, doesn’t look like JavaScript. It seems to look more like Ruby, Python, Java, or whatever language it is that the converted JavaScript programmers came from, and are in effect trying to recreate.

This power JavaScript affords is dangerous.  It is very much like using C’s preprocessor to make it look like some other language — and it raises the same sort of issue. Clearly “patching” JavaScript to make it act like a language that you are more familiar with, or like some meta-language you always wanted to work with in the browser, is appealing.  But the “dialecting” you do when adopting this approach keeps others from participating in your coding — unless they happen to speak, or are willing to learn, your dialect.

Linguistically speaking, the power of languages increases dramatically with speakers/practitioners.  The network effect is vast. For this very reason, the distinctive-dialect approach is dangerous for the popularity and longevity of the language in its core form. Consider that the TIMTOWTDI (“there’s more than one way to do it”) ethos kept Perl from achieving its fullest potential and led to things like Python and even Ruby. On the other hand Perl certainly lives on, and JavaScript is picking up converts fast for many reasons.

Will its dynamic nature and its myriad of uses fix or ruin JavaScript?  Who knows?  But in either case nobody can argue that the language is not important anymore.


Thomas Powell is a long-time web industry veteran, as well as the founder and CEO of PINT.