Seibel: So that’s the current situation. Yet you want the Web to be abetter platform for developing applications. If we can’t fix the problems wehave unless all the browsers fix it and even that doesn’t help, we’re juststuck. What’s the way forward?

Crockford: That’s the thing I struggle with. I can see the ideal. I knowwhat it needs to be. And I know where we are and I can see all the obstructionsin the way. And so I’m trying to figure out how do we take this forward. We’rein a trap, in a sense, in that we have developed these huge systems—I’m moreconcerned with the economic systems and the social systems, but also thetechnological systems—that are dependent on this system which was not thoughtthrough very well.

The worst feature of JavaScript, without question, is its dependence on aglobal object. It doesn’t have linkers, it doesn’t have any kind of informationhiding between compilation units. It all gets dumped together into acommon global object. So all the components see everything else; all thecomponents have equal access to the DOM; they all have equal access tothe network. If any script gets onto your page it can go to the server andrepresent itself as your script and there’s absolutely no way the server cantell the difference.

It has access to the screen; it can go to the user and represent itself as yourscript and the user can’t tell the difference. All of the new antiphishingthings that they’re putting in the chrome don’t work if the page came fromyour server and all scripts come with the same authority no matter wherethey came from.

But it’s even worse than that because there are other ways that script canget onto your page. The architecture of the Web has several languages init—there’s HTTP, there’s HTML, URLs are a language, there’s CSS, andthere’s the scripting language. They’re all in there and they can all beembedded in each other and they all have different quoting and escaping andcommenting conventions. And they are not consistently implemented in allof the browsers. Some of them are not specified anywhere. So it’s reallyeasy for an evildoer to take some script and put it in a URL, put it in a pieceof style and put that in some HTML and put that in another script, and soon.

Seibel: Those are the classic cross-site scripting attacks, taking advantage ofbugs in the browser.

Crockford: Right. That’s horrible; we have to fix that—it’s intolerable thatwe keep going this way.

On top of that we’ve discovered mash-ups. And mash-ups realize somethingthat we’ve been trying to do in software for 20 years: to have interestingreusable components that we can snap together like LEGO and make newapplications out of, instantly. And we’re doing that stuff in mash-ups and it’sbrilliant, where you can take something from Yahoo! and something fromGoogle and something of yours and something of someone else’s and putthem all together and make an application, and it’s great. And it all happenson the browser, right in front of your eyes. Except that each of thosecomponents has access to the same stuff. So now we are intentionallycreating XSS exploits. And the browser’s security model did not anticipateany of this goodness and does not provide any way of allowing forcooperation with mutual suspicion. The whole Web is built on one mistakeafter another. We have this big pile of accidents.

Seibel: So given all that, is the cost of the ES4 effort just the opportunitycost, that everyone is going to spend time thinking about that instead ofsome way to fix these problems?

Crockford: Right. It’s solving the wrong problem. It’s solving the problemthat people hate JavaScript. And I can appreciate Brendan Eich’s positionthere because he did some brilliant work but he rushed it and he wasmismanaged and so bad stuff got out. And he’s been cursed and vilified forthe last dozen years about how stupid he is and how stupid the language isand none of that’s true. There’s actually brilliance there and he’s a brilliantguy. So he’s now trying to vindicate himself and prove, I’m really a smart guyand I’m going to show it off with this language that has every good featureI’ve ever seen and we’re going to put them all together and it’s going towork.

I don’t think that’s the problem we need to be solving right now. I think theproblem 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 objectionwith 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 achoice of programming language, we’ve gone way forward. We’re still notdone yet, but we’re in much better shape than we are now. Then there arethings like Caja and ADsafe which are trying to do that using today’stechnology. We can’t wait.

What ADsafe does is it creates a safe subset of JavaScript. So it disallowsaccess to anything that’s global and anything that’s dangerous. And it turnsout there’s still a useful language in that subset. Because all the lambdapower is there. And lambdas can do a lot. So it’s an unconventional languagebecause 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 thereany 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 shouldhave. But there’s too much stuff in the language that hasn’t been tried. Andour experience with ES3 is that once an error gets into the spec, it’simpossible to take it out. And we have no experience with this language. Noone has ever written a big application with it.

It will be standardized and deployed before we know that it works. So Ithink we’re doing this way too fast. I’d be much more comfortable if we hadmultiple reference implementations and people doing useful applicationswith it and then go, OK, the language seems to work; now let’s standardizeit, 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 folkshave played around with compiling other languages to JavaScript. Is that apath forward?

Crockford: It’s sort of interesting to see JavaScript turning into theuniversal 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 togo fast. Particularly as we’re now going into mobile. Moore’s law doesn’tapply to batteries. So how much time we’re wasting in interpreting stuffreally matters there. The cycles count. So I think that’s going to put morepressure 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 thatworks, then great. I’m fearful of using it myself because I worry about theabstraction leakage. If there’s a problem in your Java code or in GWT or inwhat it produces on the other side, you may or may not have a place tostand to deal with that. Particularly if you took the approach that you canafford to be completely ignorant about JavaScript because the language ishidden from you. Then you’re going to be in a world of hurt if anything goeswrong. I hadn’t heard of that happening to anybody, so, so far they appear tobe 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 tomake it smaller. If we could just get it down to what it does really well andremove the features that add little or no value, it’s actually a betterlanguage. And I think we can take that approach to HTML; I think we cantake that approach to HTTP and to CSS. I think all of the standards thatwe’re working with, we need to figure out what do they do right and whatis it missing and refocus them, rather than just piling new features on top.