The Blog

Don’t tell Paul but I sometimes listen to the Boagworld podcast. I’m sharing this dark secret with you because recently the podcast featured a good interview with Christian Heilmann.

Christian talks about best and worst practices in writing JavaScript today. It’s well worth a listen.

But when the subject turns to Object Oriented Programming, Christian makes a pointed reference:

And there’s not much magic to it. I mean I get annoyed when I see JavaScript guys going on stage and saying like: Well guys, this is a function and when it’s an object it’s a method and why should I know this? Well you should know this because you need to communicate with other developers as well sooner or later.

Um… that would be me. In my books, presentations and workshops I’ve often explained methods and properties as being like functions and variables, just within the scope of an object (hence the dot syntax). But I never, ever said And why should I know this?

What I was trying to do was explain objects using reference points that I think most people will understand. I know that for me personally I had a lightbulb moment when I grokked methods and properties as being like functions and variables. The whole point of explaining this terminology is precisely so that people can communicate with other developers. As Christian says:

And these people speak that lingo and rather than you having to explain yourself for 15 minutes you could communicate in 3 minutes.

Exactly! That’s why I think it’s important that I take the time to at least explain the terminology of objects (i.e. methods and properties) even if I don’t delve into the technical details. My aim, like Christian, is to encourage better understanding and communication.

Evidently Christian takes issue with my teaching techniques. That’s fine. But I wish he wouldn’t put words in my mouth by claiming that I’m telling people that they shouldn’t have to learn the terminology around JavaScript objects.

Then again… maybe his comment wasn’t aimed at me at all and there is some other conference speaker out there who is going around telling people that they don’t have to know what the words “method” and “property” mean. If that’s true, then I agree with Christian. Such exhortations are not useful. But in lieu of any source for Christian’s imaginings of what he thinks he heard, I’ll take the egotistical paranoid route and assume he’s talking about me.

Anyway, I guess I’ll have to make sure from now on that I’m clearer about what I’m saying. More importantly, I’ll have to make sure that I’m clear on what I’m not saying.

In Chapter 8 of the DOM Scripting book I’ve got a little script that looks through the contents of an HTML document, finds any instances of the abbr element and then constructs a definition list with the information contained within them. Then there’s a section in the chapter called A browser bomb in which I explain how the script needs to be forked because Internet Explorer refuses to recognise the abbr element—part of a longstanding spat with Netscape. This means not only that you can’t do any scripting on abbreviations, you can’t style them either.

But now it turns out that Internet Explorer has an interesting quirk. If you write:

document.createElement("abbr");

…suddenly the browser recognises the element and you are free to script and style abbreviations (you don’t even need to append that newly-created element to the document). This applies to any elements that IE doesn’t recognise, which could be very hand in migrating to HTML5.

It doesn’t qualify as an error so I’m not going to add it to the errata but I sure wish I had known about this when I was writing the book.

My first public appearance in 2008 is coming up in two weeks. I’ll be spending a day delivering a Bulletproof Ajax workshop. In case you couldn’t tell from the title, it’s based on the book of the same name (wot I wrote). The workshop will be held in the cosy and comfy environs of the Clearleft office building in the heart of Brighton.

This is an entry-level introduction to the hows and whys of implementing Ajax. I’ve given this workshop before and it’s always gone smoothly though I think I might update some of the material; maybe ditch some of the introductory DOM Scripting stuff and spend more time on implementation and design challenges. I’d love to do more hands-on stuff and get people writing stuff but I find this a real challenge when it comes to code (it’s a lot easier with something simple like microformats). I’d be interested in hearing any ideas for making this workshop more interactive.

If you can convince your boss to part with the asking price of £395 per person, maybe I’ll see you on January 25th and we can climb that Ajax learning curve together.

The second day of @media Ajax certainly kicked things up a notch. While day one covered a lot of the day-to-day questions of JavaScript that I could relate to, day two was a trip to the future.

The tone was set in an opening keynote by Brendan Eich, the creator of JavaScript, giving us the lowdown on JavaScript 2. I last saw Brendan speak at XTech 2006 in Amsterdam. Back then he was telling us what was coming; here he was showing us what’s arrived. I understood about 50% of what he showed us, which I thought reflected well on Brendan’s explanatory prowess.

John Resig, creator of jQuery, gave a rundown of his library, focusing on prototyping. By taking questions throughout—and responding to all of them thoroughly—it was clear that he wasn’t giving a canned demo; he could have happily talked for an hour about any aspect of coding with jQuery. A lot of people in the room were already using jQuery and, by the time John finished, I suspect a lot more are going to investigate it. I picked up some nifty tips and tricks for myself.

Dan took to the stage and invited us on a mind-bending journey into the depths of metaprogramming. I always knew that JavaScript was a very flexible and adaptable language but Dan really showed just how malleable it could be. But, as Dan pointed out, the best way to really get your head around this stuff is to code it for yourself.

Alex Russell of Dojo fame was up next but instead of just diving into his library, he painted a much broader picture. From my own conversations with Alex, I had a feeling that he would be a great speaker and he was. He began by applying Maslow’s hierarchy of needs to applications and took us forward in time to a Web of the future that’s being hacked together today. I didn’t agree with everything he had to say but boy, did I ever enjoy listening to him say it!

Then it was the turn of Douglas Crockford who had earlier been compared to both Yoda and Gandalf by Brendan. Douglas covered some of the same territory as Dan, demonstrating the flexibility of JavaScript as well as showing its weaknesses. He also expressed his concerns about the direction that JavaScript 2 is headed.

All of that set the scene nicely for a lively closing panel.

As always, I really enjoyed moderating but I definitely felt a bit of my depth. The panel consisted of:

• Brendan Eich,
• Douglas Crockford,
• Alex Russell and
• Stuart Langridge.

They were a little reticent at first but once the subject matter got on to the burning issues like security, the conversation took off. Highlights included Alex bitchslapping Yahoo for not being truly open source with YUI and Douglas declaring that CSS is inherently shit.

All in all, I think it was a good way to wrap up a really good conference. I was very impressed with the level of presentations and the audience interaction. The two-day schedule was clearly very well thought-out. Perhaps the Ajaxians should have been on day two and John could have been on day one but that’s a minor quibble. Overall, @media Ajax was pretty darn great.

Day one of @media Ajax has just wrapped up in a very wet and rainy London.

The show opened with a State of Ajax address by the guys from Ajaxian in which they gave their perspective on where Ajax and the Web is headed. I have to say, their perspective seemed somewhat alien to my experience of Ajax in the here and now, but I think they’re talking about fundamentally different use cases—situations where the browser eclipses even the operating system and JavaScript drives everything from the interface to the core processes. Hey, you can even use JavaScript to create CSS layouts! Yes, they really said that and no, I don’t know what they’re smoking but I want some.

I think their otherworldy perspective makes sense if you’re, say, Google and you’re trying to figure out how you can hack around that awkward beast that is the Web (by doing everything in Java, apparently) but I couldn’t help but feel that in their enthusiasm to port the desktop to the Web, the Ajaxians are missing the core attributes that make the Web so appealing—things like hypertext and markup, to which technologies like JavaScript and Ajax should be subservient.

In complete contrast, Mike followed with the story of how, instead of trying to make everything work in a single technology he already knew, he explored a whole range of technologies and methodologies opened up by Ajax. In effect, Ajax drove him to become something of a renaissance man.

Derek then proceeded to give a storming presentation on JavaScript and accessibility, wonderfully illustrated by some snapshots of real-world instances of bad design that he has come across just in the few days he’s been in the country (which reminded me that most of the examples of bad design in Donald A. Norman’s The Design of Everyday Things were gathered from the time he spent in the UK).

Stuart followed with a presentation about breaking the web. His tongue was firmly in cheek… and possibly also in horses, judging by his continuous reference to horse pornography. It was a good lighthearted way to make some serious points.

I found Christian’s presentation to be a great breath of fresh air. He opened by declaring, It doesn’t matter what JavaScript library you use, or whether you use a library at all, or what coding style you use, as long as your team all agree on it. He went in to a lot more detail on how to manage code and the developers working on that code but he had me at “It doesn’t matter.”

PPK wrapped the day up with a case study that compared data formats (XML, JSON, HTML, etc.). It was also an illuminating study of the Plantagenet and Tudor royal houses—it turns out he’s something of genealogy geek.

Overall, a great day of talks, in my opinion. It’ll be interesting to see how tomorrow goes. While the first day is pitched at covering the building blocks, day two is going to cover the bigger picture. In preparation for the closing panel, I’ve been trying to gauge the backgrounds of most of the audience members; are they front-end developers, server-side developers, designers, what?

I’ve had some great pub conversations with the conference attendees. In the course of these chats, some people mentioned to me that they thought the first day was covering stuff they already knew and they said they were looking forward to the meaty stuff in day two. Personally, I’ll consider myself lucky if I can even follow all the high-level programming stuff that’s bound to come up in the talks on Dojo and JavaScript 2.

@media Ajax is about to kick off in London. I’ll be there but I won’t be giving a presentation—I’ll leave that to the experts. Instead, I’ll be moderating the closing panel. The line-up hasn’t been set yet but seeing as all the speakers are world-class, it’s bound to be a great constellation.

I’ll be spending my time at the conference (and its attendant social events) quizzing the attendees on what they interested in finding out. If you’re going to be there, say hi and let me know what you’d like me to talk about on the panel. Even if you’re not going to be there, I still want to know what you think I should be asking the finest JavaScript minds on the planet.

So tell me… what’s on your mind?

About a year ago, I wrote about my disappointment with Spry. Spry is yet another JavaScript library, this time from Adobe. My beef was with the way that Spry required proprietary markup and then claimed to be using Hijax. Roger Johansson also called them on it.

It looks like Adobe were listening. In fact, I know they were listening because not long after Roger and I published our rants, Scott Fegette recorded an interview with me that was split in two; one for public consumption and the other for developers at Adobe.

Version 1.6 of Spry looks a big improvement on what’s come before. Roger is pleasantly surprised and so am I. I’m glad to see that Adobe do listen to what we have to say but more importantly, I’m glad that they are providing solid documentation that stresses the importance of standards:

• Spry and Web Standards
• Progressive Enhancement with Spry
• Separating Behavior from Structure - Unobtrusive Spry
• Validating Spry

Documentation like this, which shows how to use code responsibly, is vital to any library. After all, it doesn’t matter how powerful or fast your code is if people then use it to break the Web.

Anyway, I just wanted to acknowledge the changes that Kin Blas and his team are making. I was quite vocal in pointing the problems with Spry; it’s only fair that I’m equally vocal in pointing out the improvements.

This somehow slipped under my radar when it was released in July: Unobtrusive JavaScript is part of O’Reilly’s Short Cut series. It’s written by Jesse Skinner and tech edited by Christian Heilmann. It’s PDF only so if you want a dead-tree version, you’ll have to print it out yourself.

I haven’t read it but judging from the description, it sounds like good Hijax-like advice:

This short cut will focus on the practical benefits of using Ajax and JavaScript unobtrusively and show you that unobtrusive web development and progressive enhancement benefit both web developers and users of the Web. You’ll get to see many simple examples of building web interfaces that are unobtrusive. You’ll quickly see that it is actually very easy to make web applications that everyone can use.

The PDF book grew out of a presentation from The Ajax Experience in 2006 which is well worth checking out.

Simon Willison—soon to be a fellow Brighton resident—has posted a lengthy overview of the jQuery library aimed specifically at JavaScript coders (as opposed to designers). Simon wasn’t initially all that impressed by jQuery:

When jQuery came out back in January 2006, my first impression was that it was a cute hack… I wrote jQuery off as a passing fad.

Like Simon, I’ve been very wary of jQuery and just about every other JavaScript library out there. But I’ve started kicking its tyres on a recent project I’ve been working on. For the most part, I’m fairly impressed. The selectors—based on CSS selectors—really do make life easier. I like the simple philosophy of jQuery:

Find stuff and do stuff to it.

This combination of selectors and events covers an awful lot of typical JavaScript development. That said, I have found some issues when I’ve delved into the effects: sliding, fading and all that stuff. The problems generally aren’t actually JavaScript problems: because the effects work on altering CSS properties, it can be hard to predict how the effects will interact existing style declarations.

Mostly I’ve found that jQuery is neither inherently good or inherently bad: it’s neutral. I suspect that’s true of most JavaScript libraries. It’s still up to the developer to use best practices and make things unobtrusive.

No library is a magic bullet and no library can compensate for a lack of basic JavaScript knowledge but the “play nice” philosophy of jQuery means that, if it’s handled correctly, it can make life easier for the developer without making life harder for the end user.

When I wrote DOM Scripting I had a very specific audience in mind. I aimed the book squarely at web designers who were well-versed in the benefits of web standards such as CSS and semantic markup, but who were quite wary of JavaScript. JavaScript was not just a programming language (which is scary enough in itself) but it was a programming language with a bad reputation.

There weren’t any other books on the market like that. There were plenty of reference books and plenty of cookbooks but the reference books tended to be stodgy affairs best suited to programmers and the cookbooks often threw best practices to the wind with the philosophy that the end justified the means.

I think I was very lucky with the timing of DOM Scripting. It had the bookshelves right around the time that many web designers realised that there was a hole in their skillset that needed to be filled. The book struck a chord with people, it sold well and, more importantly, it helped the rehabilitation of JavaScript in developers’ collective consciousness.

Frankly, I never really wanted to write a book. But I wanted that book to get written and, because nobody else was doing it, I did it myself. On the whole, I’m pretty happy with how it turned out.

Since then, there’s been a whole slew of really good JavaScript books published. Most of these books delve much deeper than DOM Scripting which remains very much a beginner’s book. In fact, DOM Scripting has remained pretty much the only book pitched at that level for that audience. Until now…

Cameron Adams and Kevin Yank have written a book called Simply JavaScript. As Cameron makes clear, this book is aimed squarely at the same audience that I was targeting:

This book – Simply JavaScript – is all about progression: taking a topic which can get pretty darn complex and breaking it down into nice, simple baby steps.

This kind of approach sets up Simply JavaScript in competition with one of the most well-written tech books available – Jeremy Keith’s DOM Scripting.

Looking through the table of contents, it’s clear that Simply JavaScript is much more up-to-date than my book (which is almost two years old now). It covers the JavaScript libraries which have become so ingrained in modern development workflows. It even has instructions on Ajax.

Its progression, however, is quite similar to the way I set up my book: begin with the fundamentals of the language, move on the Document Object Model and then delve into some practical examples, all the while emphasising best practices.

And that’s the key to why a book like this deserves to be successful: it sets out to balance the practical considerations of scripting for various browsers with the importance of separating behaviour, presentation and structure. That’s a tricky balancing act but if anyone can pull it off, these guys can.

I had the pleasure of seeing Cam and Kevin present together at Web Directions South last year. Their excellent presentation on APIs was only slightly marred by the inclusion of a picture of my head clearly Photoshopped onto the body of a male stripper. How childish! And all because I happened to use a picture of topless cameron diaz in my presentation.

Despite my call for a truce, it appears that this war of attrition has crossed over into the printed page. Reading through the sample chapters from Simply JavaScript, I noticed that I am listed in one example table with the hobbies “Cooking, bouzouki and male stripping.” Lies! I hardly ever cook.

While I plot my revenge, I will lull my adversary into a false sense of security by recommending that everyone check out his new book:

• read all about it,
• peruse the table of contents and
• download the free sample.