This year’s be-there-or-be-square JavaScript event is the newly-announced Full Frontal conference to be held at the fantastic Duke Of York’s Picturehouse in Brighton on November 20th:

full-fron•tal (JavaScript):

with nothing concealed or held back.

It’s being organised by Remy Sharp. Doesn’t this guy ever sleep? Not content with creating JS Bin and the JQuery API browser, and writing a book on jQuery for Designers, now he’s going to organise a conference too.

It looks like being an absolute bargain. A mere £100 will get you a ticket to a day of serious JavaScript talks from some of the smartest people in the business: Christian Heilmann, Peter-Paul Koch, Stuart Langridge, Simon Willison, and more.

Best of all, I don’t have to travel anywhere for this conference as it’s being held in my adopted hometown of Brighton. But if you do have to travel, I can think of now better place to travel to. Come along and I’ll make sure the geeks of Brighton welcome you.

Tickets are on sale now.

You can read all about how it was made or you can simply go and play around with it …go ahead; click on stuff.

Phil’s co-worker Paul Downey is responsible for such printed masterpieces as The Web Is Agreement and The URI Is The Thing. He has now created a printable version of Unobtrusify. Head on over to archive.org, download and print to your heart’s content.

Now I just need to find some sticky material so I can slap my copy up next to my desk.

This release features some significant changes and improvements. There’s all the usual speed improvements, of course, but what I like in particular is the way that jQuery is ditching browser sniffing in favour of feature detection. That’s the way to do it.

The way the community is developing is as interesting as the code. Sizzle, the CSS selector engine inside jQuery, has been spun off into its own standalone project so that it can be used by other libraries and frameworks. Meanwhile, the jQuery project itself is coming under the banner of the Software Freedom Conservancy to formalise its standing as free and open software.

Congratulations to John and the rest of the team. Congratulations also to fellow Brightonian Remy Sharp for putting together the very handy jQuery API browser. The boy done good.

At Clearleft, we often use pastebin.com though I’ve also used dpaste in the past. I like the way that pastebin allows you to create subdomains on the fly: just type in the URL to create it.

These services are great for collaborative debugging but they have one slight flaw when it comes to client-side work. JavaScript and CSS don’t exist in isolation; they are used to enhance an existing HTML document. So passing around a snippet of JavaScript or CSS might not be much good unless it is accompanied by the corresponding markup.

Enter JS Bin from Brighton’s own Remy Sharp, the man behind the superb microformats bookmarklet. This is a paste bin with a twist. As well as being able to share a snippet of JavaScript, you provide the markup that the JavaScript is acting on as well. If you’ve been sent a JS Bin URL, you can play around with the JavaScript and/or the markup, saving as you go.

There are some other nice touches too, like the ability to include a JavaScript library at the flick of a dropdown. For a proper explanation, be sure to watch the screencast that Remy has recorded.

Just for kicks, John has created a standalone selector engine called Sizzle. It’s not quite ready for prime time yet but it looks very promising. It uses the CSS syntax that has helped make jQuery such a popular library. Right now, the code is coming in at less than 4K!

I really, really like this modular approach to writing JavaScript. Instead of bloating a library with more features, the components of the library are instead being split into separate standalone pieces. I wonder if the same thing will happen with event handling and effects. Those three actions (selector, event, effect) probably make up 80% of jQuery use cases:

jQuery(selector).event(function() {
 effect();
});

For an event of a different kind, there’s a jQuery Camp scheduled for September 28th, the day before The Ajax Experience in Boston. The exact location has yet to be determined but given the number of jQuery fanboys out there, I’m guessing it won’t be ‘round at John’s house. There’s a nominal registration fee of $50 to cover lunch. If you use jQuery and you find yourself anywhere on the eastern seaboard of the United States at the end of September, you should probably register now.

In his spare time, John likes to relax by porting the Processing visualisation language to JavaScript. Freak.

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.