The Blog

I was in the illustrious surroundings of Rissington last week to deliver a DOM Scripting workshop. My good friend Ann was in attendance. During the latter part of the workshop — which was deliberately more loosely structured than the rest of the day — she pointed me to a really lovely bit of JavaScript form enhancement.

Take a look at the UK and Ireland TV and radio listings on Yahoo. See that search form in the upper right corner? It’s using the standard design pattern of allowing you to specify exactly where you’re searching. But unlike most implementations, this one is built on a rock-solid foundation of semantic markup.

Steve Marshall has the lowdown. Under the hood the form is using radio buttons for choosing where to search. Then, using a combination of JavaScript and CSS, this default representation is augmented to look and behave as desired. Switch off JavaScript and you can still use the search form perfectly well.

What impresses me about this isn’t so much the code (although I’m sure it’s top-notch), it’s the thinking behind the implementation: start with solid semantic markup with good ol’ fashioned form elements for interaction; then think about how it can be enhanced. Nice one, Steve.

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.