Meanwhile, as the JavaScript libraries continue to evolve and improve, the browser engines are also focusing on speed improvements. Dave Hyatt and the WebKit gang have announced a brand new JavaScript engine called SquirrelFish. This looks like being about 60% faster than the previous WebKit interpreter so you can expect quite a speed boost in the next version of Safari.

If you’re interested in what happens under the hood with Squirrel Engine, Dave shares some of the philosophical underpinnings:

SquirrelFish owes a lot of its design to some of the latest research in the field of efficient virtual machines, including research done by Professor M. Anton Ertl, et al, Professor David Gregg, et al, and the developers of the Lua programming language.

You can find plenty of gory details on the Surfin’ Safari blog.

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.

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.

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.

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 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.

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.

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?

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.

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.