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.
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.
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.
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:
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 :)
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.
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 :)
Comments for this entry are closed. If you'd like to share your thoughts on this entry with me, please contact me directly.
Nice article. I definitely think you’re right about JavaScript — it is a great language, the groundwork has been laid for it to finally be used in the right ways, and there are very few people who really, truly know JavaScript itself really, really well.
I personally consider myself a designer and not a programmer. And since I always considered JavaScript programming (like you said, it is, but for some reason some people don’t see it that way), I never really dove too deep into it. Just as I did with PHP back in the day, I would simply dabble as far as I needed to — which usually meant tweaking a few lines of someone else’s code here and there, never really fully understanding what I was doing. In my mind, I was a designer and JavaScript really wasn’t my job.
Now, a year and a half later, I probably can’t call myself a non-programmer anymore. I’ve learned Python (to some degree, anyway — I’m certainly still not at expert!) and actually really enjoyed programming for the first time in my life (and trust me, I’ve tried before). And yet, I still don’t really want to learn JavaScript. Here are my reasons why (con’t):
(con’t)
None of this is to take away from your article, of course. I agree with basically everything you said and I definitely think we need more great JavaScript programmers in the world. I just think there are a lot of practical reasons why learning JS inside and out doesn’t seem like the most efficient use of my time — and I suspect it’s the same for other people, as well.
So, I say to JavaScript: what argument do you have that I need to learn you? Why should I invest my time in you, instead of (for example) Python or ActionScript? Are you really worth my time when I can use all of you I really need by learning a framework like YUI?
I think, first off, Javascript has always been kind of squeezed in the middle “too hard” for designers, and not worthy of “real” programmers.
And browser implementations HAVE been buggy, and continue to be (I’m looking at you, Safari, the current thorn in my side).
Frankly, I don’t think most code out there isn’t good enough to really leverage modern DOM-based scripting. Many people have made the leap to clean, meaningful code, but many more haven’t, or are muddling their way through some in-between phase.
Then there’s the mantra of graceful degradation. Figuring out how you’re going to make your JS degrade well requires forethought and problem-solving skills many people just aren’t willing to give it. If it works without JS, then why bother with JS, right?
But since learning JS (and I’m still learning), I’ve cooked up a few things that I just couldn’t have dreamed of otherwise, and that’s a great feeling of empowerment.
And sometimes the client side is just the right place to do something, rather than at the server.
I agree with your fundamental thesis that Javascript ought to get more respect, but think that your “red herring” section is itself a red herring. Of course Javascript is different — all programming languages are different. The differences between Javascript and any other Algol-based procedural language (i.e., most languages) are trivial. Languages like Forth and Lisp are truly different from most procedural languages.
I don’t have any insightful suggestions as to why Javascript expertise isn’t more widespread or more valued, but there’s nothing whatsoever about the language itself that deserves to be called “difficult”, “scary”, or even “different”.
JavaScript received a bad rap in the 90s for reasons everyone’s familiar with. Now that it’s coming around again as a real benefit to web applications, we owe it to ourselves as professionals to learn it. I don’t tolerate myself writing poor HTML or CSS, why should my JavaScript be any different? Rails and Django will implement it for me, but I don’t like the code soup it (Rails) spits out. I love speed, but clean, semantic code is important too.
Ultimately the user is served a better experience, usability doesn’t go to the wind and designers and developers can get along better. That’s my argument for well and truly learning JavaScript.
Jeff Croft, there’s a bit of a chicken and egg problem there.
You can do truly useful things with Javascript, but until you learn Javascript as more than “a thing I can copy/paste from a website somewhere”, you can’t know what they are. So you never even see them, therefore you have no interest in learning Javascript.
It’s especially funny that you talk about the frameworks that do all this stuff with Javascript. Clearly, Javascript has the power to make those frameworks; they simply harness up a fraction of the power, they do not give you all of it.
If a framework does what you want, great. But if you want to do something different, you’ll need to know Javascript.
Javascript is a full, real programming language, and thanks to XMLHttpRequest it can now do useful input and output. It’s not Javascript’s fault if you can’t figure out anything you want to do with a fully general language.
Just to be clear, Django won’t implement it for you. Django doesn’t have JavaScript helpers like Rails does (and I’m glad it doesn’t!).
Yep. You’re right. But I have to wonder if I haven’t found myself needing it by now, then it is truly an essential feature?
As I said, I know you can do cool and useful stuff with JavaScript. I’ve done some of it myself and James does a lot of it for us here at work. But, as Baxter said above: if I have to make my site work without JavaScript first anyway (so as to gracefully degrade), then are the JavaScript features really essential? Obviously not, since my site works without them.
You can do great stuff with JavaScript — most of it just isn’t essential, that’s all. That doesn’t mean it’s worthless. Some of it is great. It’s just not essential or mission-critical, most of the time.
You lost me. What’s funny about that?
And that’s my point, exactly. Thanks for agreeing with me. If a framework does everything I want, then I don’t need to learn javaScript. Glad we’re on the same page.
Again, I’m glad we agree, since that’s pretty much exactly what I said.
Your comment was interesting, Jeremy. The tone was as though you were flaming me and trying to argue with me — and yet we agree on almost everything. So what gives?
I do have to say, Jeremy’s right when he says (as with any language) the more you learn JS, the more you see you can do with it.
I recently had to deal with a page that had a ginormous table on it that showed matches on the x-y axes. It was far too large for the mandated 780px width, and frankly too large to effectively scan even if the width HAD been available. Using JS I could dismantle the table, build the x axis items as an unordered list, and when the user clicked an item it showed the matches from the y axis. I ended up with something that was way more usable, had way more “wow”, and still degraded gracefully.
That’s the kind of thing I love JS for, and it’s the sort of thing that makes JS worth learning.
JavaScript certainly is an interesting language. When I first got into the web, I was terrified of the language. I was not a programmer at all, and the code examples of the late 90s were a mess. I was copying and pasting the code right through college, even though I took a DHTML class.
Even after I learned PHP, I was still scared of JavaScript. But my jobs required it as a solution for features every now and then, so I had to take my best crack at modifying someone else’s slideshow script and the like. Then I discovered the Unobtrusive JavaScript site, and then Ajax hit. I bought the book Ajax in Action and started playing around with the Prototype library. I practically took the Prototype library apart and learned the ins and outs of the language and now no longer need to use that library.
Just over a year later, I consider JavaScript my favorite personal language because of its many powerful features like first class functions, prototypal inheritance, and classless, mutable objects. It is hard to justify the necessity of learning the language due to the many libraries, frameworks, and shear lack of necessity of the language for many web sites.
My hope is that more programmers learn the power and flexibility of JavaScript and can find more applications of the language across the board, from web sites to web applications to traditional software like Fireworks. This will only come when more people learn the language and play with its features. It’s very much the chicken and egg problem, but I see more and more good info on JavaScript by people that really know the language and its abilities, so it’s a start.
I feel very much the same. Thanks for putting it into words.
To be clear, I totally think JavaScript is worth learning. It’s just that I personally only have so much time on my hands and — again, for me personally — other languages seem to have more benefit. The same might not be true for you, of course.
I’d love to know javaScript inside and out. I just haven’t really been convinced that I need to know JavaScript like I need to know HTML, CSS, and a server-side scripting language, especially considering I can do just about anything I need to with a JS framework — and when I can’t, I’ve got James sitting three desks down to do it for me. :)
This article is all about why so few people have learned JavaScript. I was just trying to contribute my personal reasons that I haven’t learned it, even though I think it’s a very good language.
Hrm, I’m not sure if that’s the full extent of things. CSS has a lot of benefits that JavaScript doesn’t just because CSS is CSS and JavaScript is JavaScript. People that were coding tables by hand, people that could differentiate between there arse and a hole in the ground, were able to see the benefits of CSS. People who were using Dreamweaver and the like could tolerate the maintenance and the amount of code that had to be written because a majority of it was done for them.
You don’t think that JavaScript is similar to event driven GUI programming?
Good read. :)
Jeff, I hope I didn’t sound like I was calling you out. Not my intention.
By pretty much any standard, I’m a middleweight at javascript at best, and I know it.
So, I’m dealing with the question too, why haven’t I REALLY learned it… and my answer is similar to yours — there’s only so much time to learn everything, and javascript is easy to push down the list.
I’m pleased with what I have learned, and excited that I see possibilities and solutions I didn’t see before, but can’t really translate that into a pressing need to learn more of it.
Anyways, I know that you know enough JS to get things done, I know you’re happy to use whatever tool is going to be most effective at getting the job done, I know you’ll happily learn more javascript if and when the need arises.
Just pointing out, since the conversation thus far seemed pretty one sided, one real world problem I don’t know if I could have solved without knowing some javascript.
I’ve been using JS for a long long time, I first picked it up when the rhino book was in it’s first edition, I was so pleased to learn about JS as a language rather than just as snippets of this and that to toss in here and there. I still recommend that book to new developers, now in it’s 5th edition I’m even considering buying it again just to loan out to people. I’ve also heard the Ajax in Action and DOM Scripting books are good as well.
Thanks for putting JS on the soap box for a while, it needs love too.
Cory basically summed up my feelings on the matter in one sentence. It took me over 10,000 characters and I still don’t think I said it think clearly. :)
This page doesn’t even have “html”, “head” or “body” tags … perhaps you should call this article “The HTML knowledge gap” :)
Psst.
Just a little hint: before you go make yourself look like an idiot again, you might want to learn a bit more about HTML; this page is valid HTML 4.01 Strict.
I think the biggest disconnect on JavaScript right now is between people who work on content-publishing sites and people who are developing web-based applications. If you’re developing a content-publishing site — whether it’s a blog, or a store, or a news outlet, or even Wikipedia — then there’s really only so much you’re ever going to need out of JavaScript. Furthermore, unless you desire to be a real innovator, you really can find everything you need out there in a library somewhere. Heck, if you use Rails, half of it is already built into your server-side framework. And as long as that’s what you want to do — and I’m not trying to say there’s anything whatsoever wrong with doing content sites — learning JavaScript isn’t likely to be at the top of your priority list.
Web applications are a whole different ball of wax. If you’re building email apps or map applications or drag and drop calendars or web-based corporate information systems, you are being professionally negligent if you aren’t hard at work in mastering JavaScript. These things beg for really world-class JavaScript developers.
For stuff like this, libraries like Prototype are a great starting point that give you a baseline that works everywhere. But then you start building out your own transport layer for managing client-server communications, and maybe you need rock-solid rich-data dialogs and a really tight client-side grid control. A consistent library for client-side error reporting and exception management. All sorts of stuff that client-server developers have been using for years on desktop platforms is now just coming into its own on the web.
Even a couple of years ago, virtually all of this stuff was getting built purely server-side in Java and ASP.Net, with postbacks between pages. But with consistent cross-browser Ajax behavior, there’s no reason not to treat the browser as the client side of a real client-server architecture. So that’s what you’re starting to see, and that’s why JavaScript is perhaps the most important programming language on the planet right now — it’s the assembly language of the internet.
My post was mostly in response to your question, Jeff: “So, I say to JavaScript: what argument do you have that I need to learn you?” I don’t see a reason to change my original answer: It’s a chicken and egg problem and you can’t see the answer until you already know Javascript.
There’s all kinds of “essential” stuff you can do with Javascript, but until you break out of the paradigm of thinking about things solely in terms HTML and pure server-side code, you’ll not be able to see them.
I’ll put thing concretely: If you can go to Google Maps, and say “The Javascript on this page is not essential to the user experience”, then I can tell you you’re not going to agree with what I’m saying, ever. (And vice versa.) But if you do agree it’s essential, where, there you go.
(But I remember MapQuest, before they copied Google’s map dragging. Scrolling anywhere was a pain in the butt. I consider not giving the users a pain in the butt an “essential feature”, but if you don’t (and I want to make it clear I’m not trying to accuse of this, I mean this as a true if), then Javascript isn’t going to appeal to you. There’s very little Javascript can do that can’t be done theoretically with a server roundtrip, if you’re willing to cause the user arbitrary levels of pain.)
Jeff, you’ve repeated this sentiment several times in the comments. I don’t think it’s accurate.
The scope of a browser-based JavaScript framework is not as encompassing as the scope of Django or Rails. Much of what Prototype does, for instance, is to provide wrapper methods that abstract away the implementation differences between browsers.
Some frameworks, like jQuery, use a different programming paradigm to lessen the learning But in general I guarantee you won’t get very far with any framework without learning a bit of JavaScript. Frameworks aren’t a veneer over JavaScript; they’re a caulk to fill in the cracks.
Frankly, I think only i can decide whether the phrase “I can do just about anything I need to with a JS framework,” since only I know what I need to do.
Well, I do know a bit of JavaScript. A decent bit, in fact. As James points out in his article, a lot of us know a bit of JavaScript.
I have no doubt that you’re right about JavaScript frameworks not being be-all, end-all solutions for everyone. They are, however, sufficient for my personal needs.
And that’s all I was saying.
Of course JavaScript is essential to Google Maps. I would never argue that point. But I am not creating Google Maps — they’ve done it for me, and even provided me a framework with which I can use it.
My point wasn’t that JavaScript is useless — my point was that I personally don’t have a strong need to learn it. James’ article is about the reasons why there aren’t a lot of people that have taken the time to learn JS inside and out. All I was doing is stating my personal reasons.
One of the key reasons is the proliferation of JavaScript frameworks and APIs that make it easy for me to do the things I need to do without learning JavaScript inside and out. Your example, Google Maps, is a perfect case in point. Because they’ve offered me a nice API to use, I’ve only ever needed to learn it — I haven’t needed to learn JavaScript at a very deep level in order to use maps in my projects.
Sorry, Jeff — I didn’t phrase that properly. I’m saying that there isn’t a qualitative difference between using a JavaScript framework and using JavaScript. Even if you weren’t using a framework, you’d still be hooking functions onto events and reading from DOM properties.
I suppose this is just confusion about what “learn” means — you talk about “learning” JavaScript, but if you know enough to accomplish the things you want to do, then I think you’re fine, whether you use a framework or not.
Then we agree. :)
I think some people (James?) are calling for more people to really learn JavaScript deeply, understanding the ins and outs of the language without using a framework to do a lot of the work for them.
Yeah, I’m not worried about it; it’ll come with time. Prototype was my gateway to JavaScript and Rails was my gateway to Ruby, just as you talk about Django being your gateway to Python. There’s already far more JavaScript expertise in the world than there was even a year ago.
Another great article on JavaScript’s current state and relation to the developers who should know it.