Seibel: 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.

Seibel: 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.

Seibel: 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.

Seibel: 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.

Seibel: So Google’s GWT compiles Java into JavaScript. And other folks have played around with compiling other languages to JavaScript. Is that a path forward?

Crockford: It’s sort of interesting to see JavaScript turning into the universal runtime. That’s not a role we ever expected for it.

Seibel: But, as you said, it’s everywhere; it is the universal runtime.

Crockford: Which I think puts even more pressure on getting JavaScript to go fast. Particularly as we’re now going into mobile. Moore’s law doesn’t apply to batteries. So how much time we’re wasting in interpreting stuff really matters there. The cycles count. So I think that’s going to put more pressure on improving the quality of the runtime.

As far as GWT goes, and other transforming things, I’m really pragmatic. This environment is so hard to work in—if you can find something that works, then great. I’m fearful of using it myself because I worry about the abstraction leakage. If there’s a problem in your Java code or in GWT or in what it produces on the other side, you may or may not have a place to stand to deal with that. Particularly if you took the approach that you can afford to be completely ignorant about JavaScript because the language is hidden from you. Then you’re going to be in a world of hurt if anything goes wrong. I hadn’t heard of that happening to anybody, so, so far they appear to be doing it right. But there is that risk.

Seibel: What would you like to see happen with JavaScript?

Crockford: I think the best way to make JavaScript better would be to make it smaller. If we could just get it down to what it does really well and remove the features that add little or no value, it’s actually a better language. And I think we can take that approach to HTML; I think we can take that approach to HTTP and to CSS. I think all of the standards that we’re working with, we need to figure out what do they do right and what is it missing and refocus them, rather than just piling new features on top.