Hi, this is Kevin Yank from sitepoint.com, and I’m here at Web Directions South, 2008 with Douglas Crockford from Yahoo. Hi Doug.
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.
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.
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.
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 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.”
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.
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!
Image credit: Web Directions
Jump Start Git, 2nd Edition
Visual Studio Code: End-to-End Editing and Debugging Tools for Web Developers
Form Design Patterns