After untangling some weirdness this afternoon, I feel like joining the masses storming the JavaScript Bastille.  But it’s too late for that with this “can’t live with it, can’t live without it” language.

A Big Baby

JavaScript is unmatched for its immaturity and ubiquity.  Both, of course, are intertwined.  With an installed base of a few billion JavaScript-enabled browsers out there, it’s virtually impossible to break compatibility and significantly fix this underdeveloped language.  The slow progress of the ECMAScript committee doesn’t help matters.  Hence so many “compile to JavaScript” tools and languages: GWT, CoffeeScript, Dart, etc.  But if going non-native were truly a good idea, we’d all be debugging bytecode.

As the size of our JavaScript code bases continues to explode (propagated by richer clients and SSJS), maybe we finally accept that the raw, unevolved language is here to stay and, since we can’t fix it, do a better job of propping it up.  Since many (perhaps most) JavaScript developers don’t naturally write clean code nor stick to The Good Parts on their own, we need code checkers.  Yes, I mean lint, but one that folks will actually use.

JSLint – A Good Start

If a proliferation of cross-compilers condemns a language, the proliferation of lint tools condemns its compilers, editors, and IDEs.  Lint tools typically fill the gap where a language lacks or the tools haven’t caught up or caught on.  Few people still use a separate C lint because most compilers and IDEs have integrated their most important checks.  And PMD became less important to me as I started tweaking Eclipse’s Java compiler warnings (although it still needs better file and package filtering).

There are a few JavaScript lint options; I prefer Douglas Crawford’s own JSLint and its recent JSHint fork.  It can be a bit pedantic, overemphasizing style.  Some of the trivial style checks can be disabled (for example, white: true and vars: true), while others can’t (“Mixed spaces and tabs”, really??).  But it’s helpful enough at catching things to be worth using in spite of its false alarms and awkwardness.

But what JSLint lacks most is integration: both with embedded source and standard tools.  That is, JavaScript source is often in server-side pages like JSPs, intermixed with form tags, embedded foreign language, and other noise that JSLint can’t handle.  The work-around is to let the server render it and then paste it into JSLint, but couldn’t someone integrate JSP parsing smarts with JavaScript validation?  And could we focus energies on making it an extension of Eclipse’s JavaScript validation: one that’s actually useful?

Perhaps smarter code analysis in this loose language is a hard nut to crack.

The Next Level

And that certainly makes sense: static analysis of JavaScript is hard because it isn’t just a dynamic language, it’s the wild west.  Is x a variable, function, property, or value?   Is it local, global, or forgotten?  Without true scoping, access control, and other aids, context is very hard to discern.  JSLint helps by not letting you get away with ambiguity, but arbitrary belts and suspenders aren’t the best solution.  Since we humans often have to let the JavaScript page render and step through it in Firebug to see what’s really going on, can we really expect a computer to figure it out from flat source code?

I think so.  With enough (warranted) attention, JavaScript validation will improve, and we’ll even see better code assist and refactoring tools.  It may take some new ways of looking at the problem, but fortunately, there’s some promising new research happening now.

Looks like we’re stuck with this JavaScript baby and all its dirty bathwater.  But here’s hoping future tooling makes cleaning it up a lot easier.