I became a bit of a JavaScript fanboy while writing Simply JavaScript last year, so it was especially thrilling to get to sit down with Douglas Crockford—possibly the world’s biggest JavaScript fanboy—and geek out on our mutual love of JavaScript at Web Directions South 2008 a couple of weeks ago.
One of the most amazing things about JavaScript is that such an elegant, subtly powerful, and forward-looking language could have been born of the fiercely competitive innovation of the so-called “browser wars” of the mid-nineties. Really, all Netscape needed to get ahead was a simple scripting language to run in its browser, but somehow what it ended up building was this amazingly capable little programming language. I asked Douglas Crockford how this happened:
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. That’s what we had. 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.
In his talk at the conference, Crockford had outlined a number of fundamental security problems that he would like to see fixed as JavaScript moves forward. Problems aside, perhaps JavaScript’s greatest strength as a language is how accessible it is to beginners.
As JavaScript moves forward, I wondered, would we be able to preserve that low barrier to entry that makes JavaScript something you can pick up as your first language and feel confident after just a day or two?
I think so, and I think we need to. I think 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, there are some attractive nuisances in it, which we don’t need, which people become dependant on. We’d be better off without that.
Unfortunately, the thing about the Web is, once something bad gets in it, it takes years to get it out. Ajax didn’t happen until 2005, but all of the technology that we needed to do 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 that Ajax became a viable application platform.
The main set piece of Crockford’s talk was the story of how he became convinced that a second “browser war”—as scary a prospect as that might be—was exactly what would be needed to kick the evolution of JavaScript and the Web back on track.
Fundamentally, Crockford believes, web standards have failed in their attempt to lead innovation on the Web:
For example, CSS2 was un-implementable, and eventually it had to be revised as CSS2.1, which was an attempt to cut CSS2 down to what people were actually 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 stuff, and there’s not a good set of tradeoffs, there’s not a complexity budget. It’s not motivated by real need, it’s more motivated 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.
Read my full interview with Douglas Crockford at sitepoint.com.
Image credit: Web Directions
Kevin YankKevin Yank is an accomplished web developer, speaker, trainer and author of Build Your Own Database Driven Website Using PHP & MySQL and Co-Author of Simply JavaScript and Everything You Know About CSS is Wrong! Kevin loves to share his wealth of knowledge and it didn't stop at books, he's also the course instructor to 3 online courses in web development. Currently Kevin is the Director of Front End Engineering at Culture Amp.
