The JavaScript knowledge gap
JavaScript is a paradox of a language. It has nearly universal availability in its target market — client-side Web scripting — and is a major component of “Web 2.0”, but very few people actually write or even really know JavaScript. Many “modern” web-development frameworks remove the need for that by offering direct translation from some other language to JS, or by offering “helpers” which generate and include JavaScript automatically. And even among the few folks who don’t use those tools, most prefer to work entirely within the confines of a particular set of libraries.
So JavaScript is one of the world’s widest-deployed programming languages, and also one of the least-well-known, in the sense of the base of programmers who can competently work with it. That’s a problem.
How did we get here?
To a certain extent it’s always been this way. Even way back in the Second Age, JavaScript users fell into two camps: a small minority who were familiar enough with the language and with browser quirks to write effective code, and a vastly larger segment who simply downloaded ready-made scripts and dropped them into their sites. But the same was true of most web technologies back then; it was the age of the copy/paste learning experience.
With the coming of the Third Age and the rise of the web standards movement, it would have been logical for this to change; the rush was on to learn CSS and proper HTML, and you’d expect that the same would have been true of JavaScript: instead of downloading scripts or copy/pasting, people should have been going out and learning the right way to do things. But it didn’t happen that way: CSS got the lion’s share of attention, with HTML coming along for the ride, and JavaScript remained the red-headed stepchild.
I think some of this had to do with prioritization; the web standards movement pushed CSS and tables-for-tabular-data first, and that was absolutely necessary at the time. It wasn’t until things were really in full swing that there was even much focus on semantic HTML — at first, ditching table layout for CSS was the battle cry, and many sites went from a layout chock full of meaningless table elements to a layout chock full of equally meaningless div elements. The pushback against “div-itis” came eventually, but re-structuring with meaningful HTML was something that logically couldn’t happen until people had ditched their layout tables and come over to the CSS side of things.
Similarly, JavaScript didn’t get a lot of attention in the early days of the standards revolution, and with good reason: just as semantic HTML couldn’t really happen until CSS caught on, best-practice JavaScript needed some groundwork in the form of cleaner, more meaningful HTML and a solid understanding of how to separate the different concerns of the Web’s frontend. That groundwork has been laid, and within the past couple of years there’s been a surge in the use of JavaScript and in writing about JavaScript; you can now walk into a good bookstore and find multiple volumes on truly modern JS development using unobtrusive scripting and the DOM APIs. But it’s going to take a little while yet for all of that to catch on.
But that’s not the only thing keeping a solid knowledge of JavaScript out of the modern web developer’s toolbox.
The red herring of browser bugs
A lot of folks will profess that they don’t hate JavaScript in and of itself, but that they hate buggy browser implementations of JS and the DOM, and at first that certainly sounds believable; there are some pretty nasty compatibility issues across the various popular browsers. But the more I think about it, the more I think that can’t really be the reason; CSS was, and in part still is, notoriously “quirky” across browsers, and yet we soldiered through and learned it anyway, cataloguing the bugs and their workarounds as we went. So there’s got to be something more going on here.
Ultimately, I think a lot of the resistance to JavaScript comes down to unfamiliarity: JavaScript is different. If most of your experience is with HTML and CSS — a markup language and a style language, respectively — the prospect of tackling a programming language and, what’s more, doing actual programming (don’t listen to the nay-sayers: writing in JS is programming) is a pretty big leap. And if you’re a programmer with a server-side background, JavaScript is nearly as strange because it’s not like most other programming languages: if you’ve never done object-oriented programming you’ve got a significant conceptual hurdle to get over, and if you have done OO before you’ve almost certainly never done it the way JavaScript does (witness the variety of ways JS libraries have come up with to try to coerce it into behaving like a “traditional” class-based language).
So no matter where you come from, JavaScript is different. And “different” can also mean “difficult”, “scary” and a lot of other things. So people don’t really learn JavaScript unless they’re backed into a corner; until then they’ll rely on helpers or libraries to smooth it out and make it feel more familiar. At least, that’s how it seems to work.
Closing the gap
So we’re back to the paradox of JavaScript: it’s a ludicrously widely-deployed language, but very few people actually know it well enough to program competently in it on their own. If JavaScript is going to step up into its rightful place alongside HTML and CSS as a foundation of the Web’s client side, that’s got to change.
One thing which could help to bring about that change would be taking away the training wheels: no more cross-compilers, no more translators, no more “helpers”. So long as it’s possible to avoid actually learning JavaScript, I think most people will avoid it. But that’s not going to happen, so we’ve got to look elsewhere.
A more plausible approach would be to change the way JavaScript is learned. Personally, as a programmer, the biggest leap forward for me was finally sitting down and reading the rhino book. The unique thing about it is that it begins by treating JavaScript as a programming language, and postpones the DOM and other web-specific details until later. More than anything, I think this is the key to introducing a programmer to JavaScript — until you can think in JavaScript you can’t program effectively in JavaScript.
For people coming from non-programming backgrounds, I can think of a few options:
- Anyone who’s ever done serious work with Flash shouldn’t have too much trouble getting to the same level with JavaScript; the differences between ActionScript and JavaScript, to a non-programmer, are relatively superficial and don’t need to be explored in detail until you’ve got a good working familiarity with JS.
- Plenty of HTML/CSS folks are dabbling in a bit of programming these days; some hack a bit on Wordpress, others get really adventurous and try out Rails or Django. Having some experience with programming concepts, particularly from heavily object-oriented languages like Ruby and Python, can do a lot to reduce the unfamiliarity that plagues JavaScript.
- Finally, for those who’ve never touched a programming language of any sort, there are friendly, well-written books popping up with increasing regularity which provide gentle introductions to JavaScript and help to flatten the learning curve.
I’d like to have a better list here, but I don’t really have experience of making that jump; I already had a few programming languages and a fair amount of practical development experience under my belt when I got around to properly learning JavaScript, so I could be wildly off-target here. Perhaps one of the talented designers I know will pipe up and offer better insight :)
Wrap it all up in a nice package
JavaScript has had image problems for a long time, ever since the Elder Days when only the DHTML Wizards could wield it properly. In the last year or so the situation has started to improve, but any change in how people get exposed to JavaScript needs to be accompanied by a corresponding change in the general perception of JavaScript; it needs to be carefully marketed. The notion of JavaScript as a painful language to be avoided whenever possible needs to be thrown out, and replaced with the same sort of descriptions people have been giving to the new wave of server-side frameworks: once you know how it works, JavaScript is a rich, expressive language and opens up all sorts of possibilities you never could have imagined before.
And even though there’s been much consternation about JavaScript libraries, I think their use should be encouraged; just as CSS benefited from widespread knowledge of hacks which would iron out browser inconsistencies, I think JavaScript will gain a lot of good will from ever-wider use of libraries which smooth out the various implementation wrinkles. That means no more discussions about whether giving an inexperienced developer a library is like “putting guns in the hands of children” — that sort of elitism, whether intentional or not, can only hurt JavaScript adoption in the long run.
And I’m spent
JavaScript is a great language whose time, I hope, has finally come. But getting the majority of web developers and designers past their hangup over actually learning the language is absolutely crucial, and I think it’ll take a combination of all the things I’ve touched on here — better teaching approaches, better marketing and more encouragement of library use — to really close the JS knowledge gap and finally make JavaScript the first-class Web citizen it deserves to be.
There’s a whole lot more that could probably be said on the topic, but that’s where I’m going to leave off for now; I’ve spent most of the past two months doing nothing but writing JavaScript and writing about JavaScript, and it’s time to shift gears for a while and get back to writing Python and writing about Django :)