Seibeclass="underline" 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.
Seibeclass="underline" 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.
Seibeclass="underline" 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.
Seibeclass="underline" Yet there’s often a tension between small, elegant jewels and sprawling, practical balls of mud. A small, perfect jewel is easy to understand and it doesn’t have warts but then you have to build more stuff on top of it to do anything. So everybody reimplements the same things over and over and that leads to a different kind of bloat and ugliness.
Crockford: But that’s not what’s happening. We have a number of Ajax library developers who are doing that and some of them are getting very sophisticated in their use of the language. And then the communities out there are building sloppy stuff on top of it and that’s working. So it’s not necessary for every application programmer to understand how to fully exploit lambda in order to take advantage of the lambda nature of the language. So we’re already doing that. We don’t need to abandon the language in order to fix that—that’s not where it’s broken.
Where we do have a problem there is that there are too many Ajax libraries. That was a consequence of the fact that JavaScript is so powerful and the need is so profound and that they’re easy to make. So for a while everybody was making them. I’ve been expecting that we’re going to have a shake-out but it hasn’t happened yet. So we still have a whole lot of libraries. So we have an alternative problem now—because there are so many libraries to choose from, developers don’t know which one to use. I think there will be a shake-out eventually.
One thing that we’re seeing now is that the Ajax libraries are converging. jQuery came up with a notation for using CSS selectors for getting a list of objects from the DOM and then providing methods for manipulating the objects en masse. And that turns out to be a really good idea and it’s something that JavaScript does very effectively. There’s an inefficiency there in that the interface to the DOM is horrible but they hide it all. They’ve really simplified the programming model—it’s brilliant.
So everybody’s doing that now—we’re seeing feature convergence. Which makes the problem even harder for the user community because it makes it harder to decide which library to use because they’re all becoming more similar. But eventually they’re going to coalesce down to a couple, maybe one. I had been predicting that one of the winners was going to be Microsoft with their Atlas framework, just because Microsoft is always one of the winners. But they don’t appear to be getting traction. The open frameworks seem to be doing much better. So I’m expecting one or two of the open frameworks will ultimately win.
Seibeclass="underline" These days you’re a JavaScript architect and evangelist here at Yahoo!, so part of your job, presumably, is to tell Yahoo! JavaScript programmers, “Here’s how you should do it.” Does your job also cover general good design practice and good coding practice?
Crockford: One of the things I’ve been pushing is code reading. I think that is the most useful thing that a community of programmers can do for each other—spend time on a regular basis reading each other’s code. There’s a tendency in project management just to let the programmers go off independently and then we have the big merge and if it builds then we ship it and we’re done and we forget about it.
One of the consequences of that is that if you have weak or confused programmers you’re not aware of their actual situation until much too late. And so the risks to the project, that you’re going to have to build with stuff that’s bad and the delays that that causes, that’s unacceptable. The other thing is that you may have brilliant programmers on the project who are not adequately mentoring the other people on the team. Code reading solves both of those problems.
Seibeclass="underline" Can you talk a bit about how you conduct a code reading?
Crockford: At each meeting, someone’s responsible for reading their code, and they’ll walk us through everything, and the rest of us will observe. It’s a really good chance for the rest of the team to understand how their stuff is going to have to fit with that stuff.
We get everybody around the table; everybody gets a stack of paper. We also blow it up on the screen. And we all read through it together. And we’re all commenting on the code as we go along. People say, “I don’t understand this comment,” or, “This comment doesn’t seem to describe the code.” That kind of stuff can be so valuable because as a programmer you stop reading your own comments and you’re not aware that you’re misdirecting the reader. Having the people you work with helping to keep your code clean is a huge service—you find defects that you never would’ve found on your own.
I think an hour of code reading is worth two weeks of QA. It’s just a really effective way of removing errors. If you have someone who is strong reading, then the novices around them are going to learn a lot that they wouldn’t be learning otherwise, and if you have a novice reading, he’s going to get a lot of really good advice.
And it shouldn’t be something that we save for the end. Back in the old days, we would schedule a code reading just as we were finishing a project and usually it would be canceled because we were late. I now believe that code reading should be happening all the time throughout the life of the project. That’s something that took me a while to figure out but there are so many benefits that come from that.
For one thing it makes it easier to track the project, because we can actually see what progress people are making. And we can see much sooner if they’re going off the rails or not.
I’ve managed projects where we’re up against a deadline and we had people saying, “Yeah, I’m almost done,” and then you get the code, and there’s nothing there, or it’s crap, or whatever, and they’re nowhere close to done. In management, those are the experiences you hate the most and I think code reading is the best way of not getting trapped like that.
Seibeclass="underline" So say we’re doing a code reading of some of my code. I bring printouts and we put it up on the screen. Then what? Do I literally read it out loud?