Oh god, we really have to get out of JavaScript before things like this happen. I’m deeply concerned that JavaScript is actually getting a good reputation — this doesn’t bode well for actual programming languages.

1. Even if JavaScript was an excellent programming language, this still isn’t right. I should clarify what “this” is because JavaScript certainly doesn’t (har har): the fact that we have to use it for all client-side web programming. Couple that with the fact that web programming is being used for far more than just rinky-dink websites, and JavaScript is pretty much the only language you can use. You can use many other languages nowadays that compile into JavaScript (Python, Ruby, CoffeeScript, even C), but that is so wrong I just want to cut my fingers off. What we desperately need is not a “better language”. We need a bytecode or virtual machine in the browser that is relatively language-agnostic, so that I can send compiled binaries down the line (which I wrote in JavaScript, or Python, or anything else) and you can run them in your web browser.

2. As I said, JavaScript is getting a good reputation. I think that this is a slingshot effect from its very bad reputation in the past. Here’s the problem: JavaScript is a dreadful programming language (it has some good parts — not many). But JavaScript is also a horribly abused language: it has had lots of bad APIs and inconsistent implementations (which are not the fault of the language), as well as a lot of bad code due to the very low barrier to entry and the fact that every web coder has dabbled in it. The latter problems gave JavaScript, undeservedly, a bad name. But in recent times, I have seen — many many times — people say “oh, JavaScript is not so bad — it just has a bad reputation because it has had lots of bad APIs and inconsistent implementations (which are not the fault of the language), as well as a lot of bad code due to the very low barrier to entry and the fact that every web coder has dabbled in it. Really, JavaScript itself is a pretty good language.”

To me, this is like having a car that won’t start half the time and occasionally refuses to turn right that got hit by another car that ran a red light, and you saying “oh, the car isn’t so bad, it’s just the other guy’s fault for running a red light.” Yes, it is the other guy’s fault, but that doesn’t mean it’s a good car. If you ignore all the crappy JavaScript code that’s been written over the years, and you peel off the awful inconsistent APIs, the browser detection and messing about with the XMLHttpRequest and DOM, and just focus on the core language itself (ECMAScript), you do not find a nice language. You find a reasonably OK language with a lot of baggage and some shockingly poor design decisions. And no, I am not once going to mention “syntax” — I do not like JavaScript’s syntax, but I don’t want people to think I am merely disgruntled with curly braces because I am not — JavaScript’s problems run deeper than syntax.

I will give a couple of examples of JavaScript’s total failure as a language and reasons why I never wish to teach this language to undergraduates (and I specifically steered our third-year course away from JavaScript to Java + Google Web Toolkit because JavaScript is just that bad). First, you need “var” on every local variable. I don’t have a problem with being forced to explicitly declare all locals — that’s quite nice — but the penalty for not declaring a local isn’t an error message, it’s a global variable. So by default, JavaScript variables do not do what you think they do. Second, “this” is crazy: its scoping rules are not like other variables. I would imagine most JavaScript coders don’t know the subtleties here: if you store a method in a local variable and then call it (“b = foo.bar; b()”), the “this” is set to the caller’s “this”, whereas if you just call a method (“foo.bar()”), the “this” is the object (“foo”). A nested function’s “this” is set to the “this” of whichever function called it, not the enclosing function, so if you have a method that makes an Ajax request, and the response handler refers to “this”, it will not mean what you think it means. Third, it is dreadful for teaching object-oriented programming, requiring people to understand the difference between functions and classes (there isn’t one in JavaScript), understand the difference between storing methods in an object vs the object’s prototype (both work, but one is more efficient than the other, and they have subtly different semantics), understand the difference between an object’s prototype and the “prototype” attribute of an object (completely different and both very important), and understand the difference between calling a function with “new” and without (the result is totally different). Fourth, JavaScript has no module or namespace system, requiring that HTML be used in lieu of proper import statements, and with programmers having to either hope that names don’t collide, or store all of their code in giant objects. JavaScript has no integer type: all numbers use floating-point arithmetic. JavaScript arrays kind of let you iterate using the “for each” notation, except the order of iteration is not guaranteed, and if any library happens to have added methods to the Array class you will get wonderfully surprising results. There is no way to specify a minimum or maximum number of arguments to supply to a function: not enough and the remaining parameters are filled with “undefined”; too many and the excess arguments are simply forgotten.

There are some nice things about JavaScript (proper first-class functions and closures, Unicode strings, nice dictionary syntax which began JSON), but this is a really semantically ugly language that I wouldn’t want to use, let alone teach to undergraduates. Something like Python (e.g., Python) would be far more sane.

Note: People on Slashdot are saying that this isn’t the primary CS course at Stanford, despite what it sounds like.