Jeremy Keith Interview

In: Interviews

By Aaron Gustafson

Published on October /files/includes/10.css, 2005

This may just be the year of Jeremy Keith. Hot on the heels of his packed presentation at South by Southwest 2005 with fellow Brit-packer Andy Budd, Jeremy published his first book, DOM Scripting: Web Design with JavaScript and the Document Object Model, while working full-time as a freelance Web developer. As if that wasn’t enough, he also established the DOM Scripting Task Force at the Web Standards Project (WaSP), created domscripting.com and managed to make some great music to boot.

Jeremy, Andy and Richard Rutter recently joined forces to form the Web consultancy Clear:left. He took a few minutes (OK, nearly two hours) away from his busy schedule for a chat with us about DOM scripting—the book and the movement.

Digital Web Magazine: What got you interested in JavaScript?

Jeremy Keith: Originally, it was the desire to do cool stuff like make things whizz around the page or make one thing do something when you clicked on another thing. You can still see my first forays into whizz-bang-whoosh DHTML at http://adactio.com/version1/.

I didn’t really consider usability or accessibility issues. I just wanted my sites to be cool. Of course, that was a very ’90s idea of cool. Nowadays, usability and accessibility are, in and of themselves, cool. JavaScript, on the other hand, is not.

DW: Ha, true. Do you remember the first script you ever wrote?

JK: Honestly, no. But I imagine it was probably a rollover script. Either that or some piece of client-side form validation. For a long time, those were by far the most popular uses of JavaScript. I don’t think I’m alone in saying that it was rollovers or form validation that first introduced me to JavaScript. Even back then, I remember being confused by the plethora of scripts that all basically accomplished the same things but in completely different ways. The Perl maxim of “there’s more than one way to do it” definitely applies to JavaScript. The trick, then and now, is recognizing a good way of doing something.

DW: What would you say makes a really good script?

JK: For me, I think graceful degradation is the most important factor. What that boils down to is that a good script shouldn’t make any assumptions about its environment. Instead, it should investigate the terrain and carry out tasks only when the browser or document are capable of executing the instructions. The obvious example is object detection. Instead of assuming that the browser understands a method you’re going to use, like document.getElementById, you test for its existence before doing anything else in your script. The same approach applies to the document itself. Don’t assume that an element with a certain id exists—check for its existence before trying to manipulate it.

I think that’s the key to writing good, robust JavaScript. It’s the DOM-scripting equivalent to what Dan Cederholm would call “bulletproofing” in CSS.

DW: You were one of the first people to use the term “DOM scripting” for what has been traditionally known as DHTML. Why the shift in nomenclature?

JK: Mostly because of the baggage associated with the term DHTML. The term DHTML didn’t originate with developers—it was a marketing buzzword created by the browser vendors. I’m pretty sure that to most developers, the name sounded confusing—like another flavor of HTML… like, say, XHTML.

Also, the kind of scripts that date from the DHTML era (the late ’90s) are fundamentally different than the kind of scripts we would write today. Back then, competing browsers had different document object models. If you wanted to reference an element in Internet Explorer, you had to use document.all. In Netscape, it was document.layers. DHTML, by necessity, involved lots of code-forking to make anything work across browsers.

Nowadays, thanks to the standardized DOM, that kind of code forking is no longer necessary. You really can just write once and publish everywhere.

A lot of Web developers who tried DHTML years ago got burned, and they’re wary of getting burned again. Applying the term DOM scripting to the new, standards-based way of writing JavaScript helps to distance it from the stigma of old-school DHTML.

I still think DHTML is a useful term, but only in a historical sense. It’s a handy way to refer to the kind of scripts that were written during the browser wars.

DW: Is DOM Scripting limited to JavaScript?

JK: Well, the DOM itself isn’t limited to JavaScript. The DOM is completely language- and platform-agnostic. The knowledge you gain from using the DOM with JavaScript could turn out to be very, very handy if you ever need to parse an XML file using PHP, ASP or any number other of server-side languages.

The term DOM scripting, though, pretty much applies to the combination of the DOM and JavaScript, i.e. client-side DOM manipulation (in the browser) rather than server-side.

I suppose, technically, I shouldn’t even be saying JavaScript. I should refer to the language as ECMAScript. But at some stage, even my inner pedant just gives up.

DW: Yeah, ECMAScript is a bit of a mouthful.

JK: Well, remember, for a while there, there were other terms floating around too… LiveScript, JScript… JavaScript seems to have survived as the fittest.

DW: True. What do you see as the major stumbling blocks to broad adaptation of DOM scripting?

JK: I think that most of the problems are psychological rather than technical. On the one hand, that’s really good: there’s no need to lobby browser vendors or hardware manufacturers to add support for anything—it’s already there. On the other hand, the psychological barriers are very real and, in some cases, quite justified.

Let’s face it, no matter how you slice it, JavaScript is programming. And programming is scary if you’re not a programmer. Most Web designers simply don’t want to deal with code, and who can blame them?

But I’m hopeful that people can set aside their trepidation and approach DOM scripting as something that can be rewarding, even fun.

I think the greatest weapon we have when it comes to evangelizing DOM scripting is CSS. Designers have embraced CSS, but writing CSS isn’t like designing something in Photoshop—you really have to think about the structure of the document in order to style it. DOM scripting is just a variation on that—you think about the structure of the document when you want to add behavior.

It’s true that JavaScript has a steeper initial learning curve, but once that has been mastered, the rewards are exponential.

DW: How about major enticements to adopting it? Or, to put it another way, how do you win over the CSS set?

JK: The simplest and most effective way is to probably point at something that looks and behaves very cool and ask, “Hey, don’t you want to be able to make something like that?”

Maybe there should be a DOM scripting Zen Garden. In the meantime, pointing out nifty bits of well-written DOM scripting (and they’re popping up more and more frequently) should get the ball rolling.

The other big task is to remove the fear. That involves writing clear, jargon-less tutorials that explain just what DOM scripting is and what it can do.

DW: Good point. Are the CSS folks the primary audience for your book? DOM Scripting certainly doesn’t read like a normal scripting primer. Can you talk a little about the decisions you made to differentiate it from other tech books?

JK: Yes, the CSS folks are most definitely the audience I’m aiming for with the book. That’s the major distinguishing factor: it’s a book about a programming language but it isn’t aimed at programmers. I’ve had to walk a very thin line between keeping the explanations simple and being downright patronizing. I hope I didn’t step over that line too often.

The other thing that differentiates this book from other JavaScript books is that I hardly ever discuss specific browsers. There’s a bit at the start about the browser wars and a bit at the end about the current state of the Web, but the bulk of the book is about writing scripts that will work in any modern browser without any browser-sniffing and code-forking.

I hope that the book will appeal to the CSS-wielding designers who already know the benefits of using standards. I just hope that they don’t get put off by seeing lines of code when they’re leafing through the pages, deciding whether they want to buy it.

DW: How about the traditional DHTML wizards? How do you reach out to them? How do you help people break years of bad habits?

JK: In some ways, that might be a tougher nut to crack. The problem there is convincing people of the benefits of standards. It’s just like trying to explain why nested tables shouldn’t be used for layout: If someone has been using nested tables for years and doesn’t see any benefit to changing their methodology, there’s not much you can do. Likewise, if someone has built up an arsenal of techniques that, on the surface, appear to work (at least in some browsers), they won’t look kindly on the idea of starting afresh.

I think that the marketplace may end up being the deciding factor, as is now happening with CSS. If you make Web sites and you don’t use CSS, you’re a dinosaur and before too long, you’re not going to have much work coming in, but a CSS-savvy designer is going to be increasingly in demand. Eventually, that’s what’s going to happen with old-school DHTML versus the standards-based DOM scripting, although it may take longer.

DW: Agreed. Who do you consider innovators in the DOM scripting world? What/who inspires you?

JK: There are some great innovators out there, but the people who really amaze me are the ones who have been advocating a responsible, standards-based approach to JavaScript for years (long before the term “DOM scripting” emerged). Peter-Paul Koch has probably done more than anybody to lay the groundwork for the JavaScript revolution. He has invested an incredible amount of time and effort into quirksmode.org.

Steve Champeon has been talking about JavaScript, progressive enhancement and graceful degradation for years. It’s just a shame that it’s taken this long for the rest of us to start listening to him.

And of course there are my fellow countrymen and friends, Stuart Langridge and Simon Willison. They have both gone out of their way not just to write cool scripts, but to share some fantastic knowledge with the community at large.

Aaron Boodman, Scott Andrew, Cameron Adams… these guys have been experimenting and consistently coming up with some great results.

And you’re no slacker in the scripting department yourself, Mr. Gustafson.

DW: Aww, shucks. Now, the other JavaScript-related technology that has the industry abuzz right now is Ajax. How does Ajax factor into DOM scripting? What do you say to those purists/zealots who pooh-pooh it for not being a standard?

JK: You have to remember that Ajax != XMLHttpRequest. That’s part of it, but Ajax is first and foremost a methodology.

But as for the XMLHttpRequest object not being a standard, I can totally sympathize with the purists. I’m probably one of them. I hate the thought of using something that doesn’t appear in a specification from the W3C. And, sure enough, the first thing you have to do when you want use Ajax is fork your code: Internet Explorer does it one way, Mozilla another. But, on the whole, sheer pragmatism wins out and the benefits of using the non-standard object win out. I just hope it isn’t a slippery slope that would lead to developers returning to browser-specific code.

On the whole, I welcome our new Ajax overlords. The buzz being generated by Ajax applications like Flickr and Google Maps has done wonders for re-igniting interest in JavaScript. For the first time in quite a while, people really want to know how to write scripts. It’s critical that these people have resources they can turn to so that they can learn DOM scripting in a safe, responsible way. JavaScript is like any other powerful tool: In the wrong hands—and without the proper expertise—it could be used to do terrible damage.

But I tend to give people more credit than that. I think that most people want to build cool stuff and do the right thing.

DW: Let’s talk for a moment about your involvement with WaSP and the new DOM Scripting Task Force. WaSP did a lot to further the use of Web standards (especially CSS) by working with software developers to improve their products. Do you see the DSTF working with these vendors to improve the quality of the ready-made JavaScript libraries for their WYSIWYG editors?

JK: That’s not something we’ve discussed. There are a lot of things we could wind up doing in the future, but for the time being, it’s baby steps. Our first priority is in educating and helping developers. After that, we’ll probably take stock of the situation and see what needs to be done. For now though, we’ve got enough on our plate just dealing with the evangelization and documentation of DOM scripting.

DW: True. Do you think it is something you would be interested in pursuing? How about browser makers? Are you interested in working with them toward improving their products?

JK: Well, the situation now is a lot different than when the WaSP was first formed. In fact, one of the driving factors behind the formation of the WaSP was the lack of support for the standardized DOM. Compared to those dark days, the browser market of today is a DOM scripting paradise. Sure, there are things that could be improved in just about every browser’s support for certain DOM details, but the core functionality exists across the board. It’s a very different situation to the uneven CSS playing field.

That’s something that may come as a pleasant surprise to CSS developers who are making the move to DOM scripting. With CSS, you write your style sheet and then you spend ages trying to get it to work in all the different browsers and operating systems. With DOM scripting, the work all happens at the start. But once you’ve got a function that works in one browser, chances are it’s going to work in nearly all.

Again, that’s not to say that browsers couldn’t be improved in some aspects but, on the whole, cross-browser DOM support is far, far better than CSS support.

DW: What’s next for you? Another book, or are you thinking of taking a break from writing for a while?

JK: I’m definitely not going to be writing another book any time soon—that stuff is hard! But I will be doing lots of writing. I’ll be writing articles for the DOM Scripting Task Force and I also plan to start publishing some stuff on domscripting.com. Writing the book was just the beginning. The real work starts now.

DW: That sounds great. Domscripting.com could turn into a fantastic resource. Final question, and it’s on a bit of a tangent: If Salter Cane takes off and you’re busy touring the world, who would you hire to maintain your Web site?

JK: I’m too much of a control freak to let anyone else touch my site… heck, I don’t even have comments enabled. But if Salter Cane were doing well enough to be touring the road, I would stipulate in my rider that wi-fi must be available in every venue we play. That way, I could fulfill my dreams of rock stardom by night and continue to post irrelevant trivia on my site by day.

DW: Ha, that’s great. Thank you so much for your time.

JK: Thank you Aaron.

Related Topics: DOM, Scripting, XHTML, CSS