Douglas Crockford: JavaScript Doesn’t Suck

At the Web Directions South conference last week, SitePoint’s Kevin Yank had the opportunity to speak with Douglas Crockford, Yahoo architect and expert on all things JavaScript.

Douglas presented a talk entitled Web Forward! (formerly Ajax Security), in which he described the potential of – and problems with – JavaScript as a language, and how it would need to change for the Web to continue its evolution. He focused heavily on how the current process for developing web standards is failing us, and how the looming browser war could provide the solution.

Hi, this is Kevin Yank from sitepoint.com, and I’m here at Web Directions South, 2008 with Douglas Crockford from Yahoo. Hi Doug.

Hi.

So, I’ve heard you say several times just how much JavaScript sucks, and how many problems there are with it, and yet you seem to devote yourself to it with a lot of passion. Why is that?

I don’t think you’ve heard me say it sucks, because that’s not my position, except occasionally when I’m echoing the sentiment of the market.

Ah, that’s fair enough.

I am very clear about its shortcomings. But I believe that if you strip away its shortcomings, what you’re left with is actually an elegant, beautiful little language. And it’s not only a beautiful little language, but it’s also a powerful one, and one that is more widely deployed than any other language in the world.

Yeah. And it’s continually surprising to me just how capable a language it is, given where it came from. I mean, one day in the 1990s, Netscape said, “We need a little language to run in our browser.” And what we ended up with was very close to the JavaScript that we have today. How did Netscape end up with it as a language, answering that need at the time?

They were really lucky. Given the process that created the language, we should have gotten something much, much worse, because they didn’t do a careful design of requirements. They certainly didn’t give enough time for its design or its implementation. They took a prototype, which was intended just as a proof of concept, and that’s what they shipped. And it had all the problems that you would expect such an implementation to have. And it was partly on the basis of that implementation that the language got the terrible reputation that it had. And a lot of those defects are still in the language.

But beyond all of that, there were a couple of extremely clever ideas that were also in there, which have since been revealed, which give the language amazing, expressive power. But at the same time, it’s extremely accessible for beginners. And since, for most web developers, JavaScript is their first programming language, that’s an extremely valuable feature to have. A lot of JavaScript’s critics want to go back in the other direction, and make it more Java-like, but I think that would be a bad thing because it would alienate most web developers.

So, I’d rather go in the other direction and train our web developers how to be programmers, how to be computer scientists, because you can in this language. It’s possible to write good programs in this language, which is something we didn’t know before. And beyond that, I’m now insisting it’s necessary to write good programs, because if the programs are not good, they’re not going to scale, and they’re not going to be secure. The language is good enough to support that mission, so it works.

You recently wrote the book, JavaScript: The Good Parts, and I recently wrote a book about JavaScript myself. And what I found a lot of the time as I was writing it was, as you say, you have to try to train people what not to use in JavaScript.

For me, the strength of the Web is its accessibility, not just for people reading it, but for those publishing new content. I’m interested, as JavaScript moves forward and we try to correct these problems with it, whether we’ll be able to preserve that low barrier to entry that makes JavaScript something someone can pick up as their first language and feel confident with after a day or two?

I think so, and I think we need to. We would be making a tragic mistake if we didn’t retain the language’s simplicity. Most of the modifications I would like to make in the language would be to make it even simpler. There’s some cruft on it, and there are some attractive nuisances in it, which we don’t need but which people become dependent on. We’d be better off without that.

Unfortunately with the Web, once something bad gets in it, it takes years to get rid of it. Ajax didn’t happen until 2005, but all of the technology that we needed for Ajax was in place and in the field in 2000. Most of that five years was spent removing old browsers from the marketplace until there was enough of an audience on IE6, making Ajax a viable application platform.

I’ve admired Yahoo’s educational initiative – its pattern library and the Yahoo Developer Network. How did that come about? Has it been a success for Yahoo?

I think it has been a success. You know, there are some brilliant people at Yahoo. There always have been. For years we kept that fact a secret. We’re not doing that so much anymore. I’m really happy to see that we’re being more open now, and we’re sharing what we know with the rest of the community. It’s clearly been a good thing, and there’s been a lot of interest in what we’ve released.

No doubt the infamous line from your talk today will be that we need another browser war. What aspects of a browser war lead to progress and moving the Web forward? What do we want to see the browser vendors fighting over? Is it user market share, or is it developer mind share, or is it a bit of everything?

It’s going to be everything. There will probably be fronts on the war, and it may be that different things are hot at different times. But the problem that we have now is that we’re stuck. Our technology hasn’t evolved at all since the Ajax set got put in place in 1999, and the way we understand web applications today is radically different. So we’re now trying to go forward with the wrong technology, and it’s inadequate. We’ve tried to go forward using the standards process at W3C and ECMA; that process is not effective, so we need to find another way.

I’m not really proposing a browser war – it’s going to happen by itself. I wish I had the power to say, “This is what we must do.” The best I can do is recognize, “This is what’s going to happen, and we should figure out a way to take best advantage of it.”

Yahoo is a relatively recent addition to the ECMAScript standards body; you’ve spoken about how you’re hoping to lead a more conservative approach to that standardization, where the standards body follows behind the implementation, and documents what’s really good, what’s proven. With that happening, how is JavaScript going to get better? Where are those conversations on the leading edge going to happen?

They may still happen at ECMA. I’m starting a process at ECMA to look at creating a safe dialect of JavaScript, or a capability dialect of JavaScript. That’ll be happening at ECMA, involving ECMA members. I’m hoping I can open it up to some non-ECMA members as well. Our initial motivation will not be to write a standard, but to come up with a language that we can test. We’ll try to get the language tested, see if we can get it deployed, see if it actually does what it needs to, and then we’ll try to make a standard.

I think that’s the proper sequence for everything, but in the last few years web standards – at least for the last ten years – web standards have lost focus. They’ve been more about invention than about codification, and I think that is unhealthy. At best it’s been unproductive, and at worst we’ve seen bad standards come out of that.

For example, CSS2 was un-implementable, and eventually it had to be revised as CSS2.1 – an attempt to cut CSS2 down to what people were able to figure out how to implement. That sequence was totally backwards – or it started backwards, but eventually they got it right. Let’s look at what can actually work and make a standard out of that, and then let everybody catch up with each other. I think that’s a proper role for standards.

What I see happening now with HTML5 is appalling. There is some stuff there that I really like: I really like that they figured out what the rules of HTML parsing are. Brilliant. That’s long overdue. And you can look at any individual feature that they’re doing and say, “Yeah, that makes sense.” But there’s just too much, and there’s not a good set of trade-offs, there’s not a complexity budget. It’s not motivated by real need, but by what’s shiny in front of a committee.

So, I would like to find a way to inject more discipline into the process, and I think one way to do it is to change it to an evaluation and description process, where we’ll observe what’s going on out in the wild, and document the best of it. And that documentation process is really hard – it’s a lot of work. Taking something as complex as a computer system and describing it in a way which is generally useful is difficult. It’s good that we have these organizations to do that work, but that should be their focus.

One of the projects you mentioned in your talk was AdSafe, a method of injecting ads into pages in a safe way, so that the ads don’t have unfettered access to the rest of the site that’s hosting them. Speaking from the perspective of a site that runs ads and receives the most appalling code from our advertisers – which they expect us to inject into our site – how do we get the advertising industry to buy into that?

We’re going to have to do it all together. At Yahoo we’ve talked about going to the industry, and then we always back down because we don’t want to be perceived as difficult to work with – we’re already perceived as difficult to work with! So, we need to approach them all at once and say, “Look, we can’t accept these lousy ads anymore. We need to have at least this level of technical quality if you want to get on our sites.”

I think computer networks are the only place where there are no such quality standards. If you want to show an ad on a television network, it’s going to be exactly thirty seconds. You don’t get to go longer if you want – it’s not an option. It’s got to be encoded properly, it’s got to be on a standard tape format … all that stuff. (Otherwise) there’s no play. We don’t have those sorts of limits on computer-based advertising, and we need to. So, this is a remedial effort that we have to undergo.

So, consider it a slight spoiler for your book, but if you had fifteen minutes of attention from everyone who’s writing JavaScript in the world today, what one thing would you teach them to do better – or not do – with the language, to improve JavaScript on the Web?

The number one thing is, be aware that you can and must write good programs. One of the principal measures of the quality of a program is its legibility. We should be writing programs for other people to read. And I recommend code reading as a standard process of all development activities, so a team would do weekly code readings at the least, whether you take time out to read each other’s code … I think the benefits that come from that are tremendous.

Great. Thanks very much!

Thank you.

Image credit: Web Directions