JavaScript, purely by accident, has become the most popular programming language in the world. There are more JavaScript processors in the world than any other language by far. And for all of its problems with its security model, JavaScript is the only language where you can write code and run it on any machine.
And if that weren’t enough, it’s now being embedded in a lot of applications. Most of the Adobe applications have JavaScript in them so you can script them locally. And other applications as well. So it’s become hugely popular.
The problem with the language is that it was rushed to market way too fast and standardized way too fast. So most of its defects are not in the current implementations—they are in the specification. The standard says do this incorrectly. Which is appalling. But that’s the state of it. It got frozen in 1999 and then should have gone into neglect and died. But instead, by accident, Ajax happened and suddenly it’s the world’s most important programming language.
So now we’re thinking that we need to fix it. But the time to have fixed it should have been in 2000. But it didn’t get fixed then, back when everyone was paying no attention to it. Now it’s huge.
There’s another thing that’s odd about JavaScript in the web context: If you’re doing a server application or a desktop application or an embedded application, you get to choose not only the language but which specific compiler you’re going to use, which specific runtime you’re going to use. You don’t get that choice in JavaScript. You have to run on everything that’s out there.
Because we have to run on everything, bugs don’t get fixed. If a browser maker ships a bug and goes, “Oops, we screwed up,” and the next month they ship another one, we cannot depend on all of their users doing the upgrade. The mainstream, once they get IE installed on their machine, that’s it; they don’t upgrade. Those bugs stay there for years.
Seibeclass="underline" So that’s the current situation. Yet you want the Web to be a better platform for developing applications. If we can’t fix the problems we have unless all the browsers fix it and even that doesn’t help, we’re just stuck. What’s the way forward?
Crockford: That’s the thing I struggle with. I can see the ideal. I know what it needs to be. And I know where we are and I can see all the obstructions in the way. And so I’m trying to figure out how do we take this forward. We’re in a trap, in a sense, in that we have developed these huge systems—I’m more concerned with the economic systems and the social systems, but also the technological systems—that are dependent on this system which was not thought through very well.
The worst feature of JavaScript, without question, is its dependence on a global object. It doesn’t have linkers, it doesn’t have any kind of information hiding between compilation units. It all gets dumped together into a common global object. So all the components see everything else; all the components have equal access to the DOM; they all have equal access to the network. If any script gets onto your page it can go to the server and represent itself as your script and there’s absolutely no way the server can tell the difference.
It has access to the screen; it can go to the user and represent itself as your script and the user can’t tell the difference. All of the new antiphishing things that they’re putting in the chrome don’t work if the page came from your server and all scripts come with the same authority no matter where they came from.
But it’s even worse than that because there are other ways that script can get onto your page. The architecture of the Web has several languages in it—there’s HTTP, there’s HTML, URLs are a language, there’s CSS, and there’s the scripting language. They’re all in there and they can all be embedded in each other and they all have different quoting and escaping and commenting conventions. And they are not consistently implemented in all of the browsers. Some of them are not specified anywhere. So it’s really easy for an evildoer to take some script and put it in a URL, put it in a piece of style and put that in some HTML and put that in another script, and so on.
Seibeclass="underline" Those are the classic cross-site scripting attacks, taking advantage of bugs in the browser.
Crockford: Right. That’s horrible; we have to fix that—it’s intolerable that we keep going this way.
On top of that we’ve discovered mash-ups. And mash-ups realize something that we’ve been trying to do in software for 20 years: to have interesting reusable components that we can snap together like LEGO and make new applications out of, instantly. And we’re doing that stuff in mash-ups and it’s brilliant, where you can take something from Yahoo! and something from Google and something of yours and something of someone else’s and put them all together and make an application, and it’s great. And it all happens on the browser, right in front of your eyes. Except that each of those components has access to the same stuff. So now we are intentionally creating XSS exploits. And the browser’s security model did not anticipate any of this goodness and does not provide any way of allowing for cooperation with mutual suspicion. The whole Web is built on one mistake after another. We have this big pile of accidents.
Seibeclass="underline" So given all that, is the cost of the ES4 effort just the opportunity cost, that everyone is going to spend time thinking about that instead of some way to fix these problems?
Crockford: Right. It’s solving the wrong problem. It’s solving the problem that people hate JavaScript. And I can appreciate Brendan Eich’s position there because he did some brilliant work but he rushed it and he was mismanaged and so bad stuff got out. And he’s been cursed and vilified for the last dozen years about how stupid he is and how stupid the language is and none of that’s true. There’s actually brilliance there and he’s a brilliant guy. So he’s now trying to vindicate himself and prove, I’m really a smart guy and I’m going to show it off with this language that has every good feature I’ve ever seen and we’re going to put them all together and it’s going to work.
I don’t think that’s the problem we need to be solving right now. I think the problem we need to be solving is: The Web is broken and we need to fix it. So we need to figure out a way to go forward. And my biggest objection with what Brendan is trying to do is it’s a distraction.
I’m looking at this stuff incrementally. If we can get a module; if we can get a choice of programming language, we’ve gone way forward. We’re still not done yet, but we’re in much better shape than we are now. Then there are things like Caja and ADsafe which are trying to do that using today’s technology. We can’t wait.
What ADsafe does is it creates a safe subset of JavaScript. So it disallows access to anything that’s global and anything that’s dangerous. And it turns out there’s still a useful language in that subset. Because all the lambda power is there. And lambdas can do a lot. So it’s an unconventional language because it doesn’t let you use prototypes in the way we have up until now. But it’s a full lambda language, so hugely powerful.
Seibeclass="underline" Leaving aside that it may be solving the wrong problem, are there any bits of ES4 that you like, just from a language point of view?
Crockford: There are some bug fixes that are good that I think we should have. But there’s too much stuff in the language that hasn’t been tried. And our experience with ES3 is that once an error gets into the spec, it’s impossible to take it out. And we have no experience with this language. No one has ever written a big application with it.
It will be standardized and deployed before we know that it works. So I think we’re doing this way too fast. I’d be much more comfortable if we had multiple reference implementations and people doing useful applications with it and then go, OK, the language seems to work; now let’s standardize it, now let’s deploy it worldwide. I think we’re doing it all backwards.