I wanted to write up my notes on the jQuery UK Conference as I had an amazing time. Apologies to anybody who follows me on Twitter who didn’t want to know about the conference, you were probably spammed a bit. But shame on you for not wanting to know!! This isn’t a concise write-up of everything that happened, but is more what I took from the conference (what I learnt/found relevant to me .etc)

Yesterday I travelled to Oxford to attend the jQuery UK conference, which the team at White October carefully crafted together. The snow threatened to stop me, but thankfully calmed down by the morning. So a quick hop, skip and jump on to a train and coach; and I found myself in Oxford at the Saïd Business School.

After discovering I was pretty much the only person who hadn’t won a Blackberry Playbook, the White October team kicked off the conference by introducing themselves and their keynote speaker Ralph Whitbeck.

Ralph Whitbeck

After promising the UK edition of the jQuery conference would become a yearly experience, Ralph (aka @RedWolves) spoke about how jQuery’s popularity had increased and who the current team are before explaining what changes had happened to jQuery in the past year. He went through the changes in version 1.5; 1.6 and 1.7 - most of which sounded familiar, but some of which had passed me by.

When and Then

Version 1.5 introduced $.when and $.then which I haven’t really looked into before, but the basic syntax is:

$.when( deferreds ).then( successFunction, failFunction );

So, for example, if you loading a page or data through AJAX you could do:

$.when($.ajax('myUrl.json')).then(doSomething,handleError);

Relative CSS

In Version 1.6, I was unaware that it was now possible to use jQuery’s .css() function to change values relatively. For example:

$('#myElement').css('width','+=100px');

On and Off, and AMD

In Version 1.7, jQuery .on() and .off() was introduced, which I’ve written about before; and jQuery introduced AMD support which you can read more about on the amd-js api Github page.

Ralph also spoke about the internal workings of jQuery and how we could be more involved with. jQuery has a status updates page which is updated by each sub-team of jQuery every Friday and a jQuery meetings page where you can find out what meetings are forthcoming.

There was also talk of 1.8 and beyond. The main focus at the moment is to cut down the size of the library and clean up the codebase. jQuery 1.8′s focus is this, and is unlikely to contain any new APIs. It’s possible that jQuery may drop IE6/7 support in to a plugin in the future. At the moment, this is just being discussed and is not official - just an idea. As Christian Heilmann pointed out on Twitter, jQuery’s main purpose is to support cross-browser functionality and without IE6/7 it starts to reduce the need for using jQuery at all.

Going forwards, jQuery’s site is going to see an infrastructure overhaul and site refresh. There will be a new plugin site, this time with backups - and a new learn site, which sounds like something I’d like to get involved with.

Ralph’s slides are available online.

Todd Parker

Next up was Todd Parker (@toddmparker) to talk about jQuery Mobile. As someone who has spent the last 1 and a half months working with jQuery Mobile and PhoneGap trying to get an animation heavy Android application up and running; it was refreshing to hear that everything we had encountered was being spoken about. At the start of the presentation, Todd asked everyone what phone they used as their primary device. Over 60% of the room had Android devices; most others had iOS; with a few having BlackBerries, Windows Phones .etc. Interestingly, there only seemed to be 1 person using a Nokia, but I’m sure I saw at least 3 people from Nokia at the conference.

jQuery Mobile is awesome - a great tool for mobile development. When I first used jQuery Mobile I wasn’t sure. I was never a fan of jQuery UI - it always felt like too much bloat, unless you were using the majority of its features. jQuery Mobile felt the same the first time I used it. It changes your DOM - which really made me unhappy; but after playing around with it for a while you begin to understand why, and see how much help it is giving you by making things work on multiple devices; so then you start to play jQuery Mobile to its powers.

But for anyone considering building an Android application which uses the default browser (like PhoneGap is forced to do), the browser sucks. It doesn’t do what you need. It actually turned out we’d managed to force Android to do more effects than was claimed on the presentation (thanks to sheer determination to find a workable solution), but generally throughout the conference it was advised not to develop Android web apps to package natively.

The future of jQuery Mobile

Todd revealed some awesome changes coming to jQuery Mobile. Version 1.1, which is due at the end of February should feature a better loader; new transitions (and a default of fade for Android because it sucks at everything else); fixed toolbars; data-mini - which allows smaller buttons and text (which can be placed in headers for example); a fix to the iOS orientation bug where content is cut off when changing device orientation; and most importantly (for me), data-enhance=“false” which will tell jQuery mobile to stop screwing with your DOM for all child elements. They will be left alone. jQuery Mobile v1.1 is available online for testing already.

Version 1.2 also promises some interesting features such as Fetchlinks which allow you to specify a data-target for a link - and jQuery Mobile will load content in to this container.

Todd’s slides are available online.

Dion Almaer and Ben Galbraith

After a quick break, Dion Almaer (@dalmaer) and Ben Galbraith (@bgalbs) were up on stage and talking about Native vs Web applications. It’s clear from their presentation that Dion and Ben know each other well and work together just by how they could easily alternate speaking roles - I’ve done that before and it’s a tricky thing to get right, but they nailed it.

They had several learnings in this area, first talking about native vs web applications and their advantages and disadvantages and how the Android browser meant that it wasn’t really ready for animation rich web based applications yet - which is interesting as my recent work found that although it is an absolute pain in the ass, if you spend enough time tinkering it is possible to get something relatively nice animating on Android.

Dion and Ben have released a couple of tools to help with their development. Thorax is an opinionated application framework built upon Backbone.js; whilst Lumbar is a build tool that generates modular platform specific applications.

Jorn Zeafferer

You may not have heard of Jorn (@bassistance) before, but you have probably used his products - Jorn has created a bunch of jQuery plugins, including the awesome jQuery Validate plugin. Today Jorn spoke about the pitfalls and opportunities of single page web applications.

After going through some advantages and disadvantages, Jorn talked about the JavaScript History API, showing us the second biggest shocker of the day* - the History API browser support matrix, and more specifically how Android used to support it, but now doesn’t! (See [Can I Use?]() for more info).

Like all good web features, there are polyfills available - html5please.us is a great resource for finding out whether you should use what you want to use and whether you need to use any polyfills.

• The biggest shocker of the day was that around half the attendees hadn’t read JavaScript: The Good Parts. If you are one of those people who hasn’t, it’s really worth reading.

Lunch

Next up was lunch, and two lunch time talks. I missed Wes Nolte’s (@wesnolte) 10 jQuery tips talk as I was eating lunch (sorry Wes). The QUnit talk by Laurent Delcambre (@tquila_laurent) seemed like a good introduction to using QUnit. Laurent explained that using ‘same’ is preferable to using ‘equals’ for the same reason using === is preferable to using == (you are checking for same type as well as value so don’t get truthy/falsey results). Also, ‘same’ checks the contents of your object.

At this point I won a book on JavaScript, which at 1080 pages is going to take some time to read; but was awesome.

Christian Heilmann

To be honest, Christian Heilmann’s (@codepo8) talk was so captivating I didn’t write any notes. Chris is an excellent speaker, and his talk was perfectly pitched to the audience he was speaking to - some JavaScript developers, some people that use jQuery (yes, they are different). Interestingly for a jQuery Conference, Chris’ talk was about how we should stop relying so much on jQuery, especially on mobile devices.

On mobile phones, we do not need to worry about old versions of Internet Explorer; and including the jQuery library adds a chunk of extra downloading over 3G.

Chris spoke about two things that stuck firmly in my mind - one I was aware of, the other I was not.

Selecting elements with JavaScript (the simple way)

document.querySelector( selector ) allows us to grab the first element on the page that matches our CSS selector (read more on MDN).
Use document.querySelectorAll( selector ) to return all matching elements (read more on MDN).

This functionality is supported in all browsers except IE6 and IE7, so if you do not need to support these browsers (e.g. on mobile) you can use this functionality.

Using classList

element.classList was new to me. classList basically replaces the need for jQuery’s addClass, removeClass and hasClass by providing this functionality natively.

To add a class from an element you use:

element.classList.add("my-class");

To remove a class from an element you use:

element.classList.remove("my-class");

To check whether an element has a particular style you can use:

element.classList.contains("my-class");

There is also functionality to toggle a class, so you do not need to check whether it exists before adding or removing it (very handy):

element.classList.toggle("my-class");

classList has less browser support than querySelector but looks as though it could be incredibly handy in the future. (read more on MDN)

Chris’ big plea to his audience was to not just answer everything with “we’ll use jQuery” - which was very fitting for the audience (considering half of them hadn’t read The Good Parts). Keep animations in CSS where possible, keep logic in JavaScript - jQuery shouldn’t be the solution to everything. It’s very true, and a very big problem I find when interviewing developers.

Chris’ slides are available online. Chris also had the honour of being the first speaker to use a ‘to-do’ list example.

Haymo Meran

Talking after Chris was always going to be a challenge, and to be honest Haymo’s (@draftkraft) talk seemed more like a sales pitch than anything. I generally dislike WYSIWYG editors but the Aloha Editor looks very cool. It uses ‘contenteditable’ (which can be a absolute pain to work with thanks to different browser interpretations). The Aloha collaborative wiki seemed like a well thought out idea. Next time I’m looking for a WYSIWYG editor, I’ll definitely consider it.

Paul Irish

Paul Irish’s (@paul_irish) talk was also awesome, and I again took very few notes as I was busy being attentive; but Paul was explaining to the audience the web development stack and how it could help your development. Again, this was an excellent talk for the audience as half the audience didn’t seem to be aware of most of these front end tools.

There were too many tools for me to list here (and if you keep up with the web, you’ve probably heard of or used most of them) - but they are all listed on Paul’s slides. Paul’s slides were using CSS3 transitions and animations to create 3D carousels, it was all very impressive and a quick check of the code shows it was using Reveal.js. (thanks @Autarc)

One tool I wasn’t aware of was the HTML Email Boilerplate. I don’t have to build HTML emails anymore (thankfully), but it’s something I want to look in to as it could be useful at work.

Paul wrapped up his talk with some demonstrations of upcoming Chrome Developer Tools functionality. As he was running short on time, he went quite quickly and I got the feeling there were some participants that weren’t aware you could do most of the older functionality that he was whizzing through to get to the new stuff.

First up was the ability to search all JavaScript files to find a particular piece of code with the search returning a list of all the results. Next (using a webcam so we could see the phone), he showed how he was connecting to Chrome on his Android and selecting elements on the phone through the Chrome Developer tools. It was very impressive to show how it was working, and he finished it with a cheeky wink.

Paul’s slides are available online.

Addy Osmani

Addy’s (@addyosmani) talk was quite technical, probably a bit too technical for the some of the attendees who came from a design based background. But for the techies, it was very informative.

Addy spoke about how developers should break down large chunks of code in to smaller, reusable pieces. By separating units of code so that they do not relyvon one another (decoupling) you reduce the risk of parts of your code failingvand causing catastrophic errors.

Publish and Subscribe

By using publish and subscribe, you can allow modules of code to listen for events and react to them accordingly (known as “Event Driven”). In jQuery, this can already be done with .trigger() and .on().

To listen for a custom event, you would use:

$(element).on('customEvent', myFunction);

To trigger that custom event, you would use:

$(element).trigger('customEvent');

There are a few alternatives to using these jQuery methods which are detailed on his slides.

Patterns

Next, Addy spoke about two patterns - the Facade pattern, which hides complex functionality behind a simple API; and the Mediator pattern, which is like Air Traffic control where a module handles all the communication between other modules.

Modules

At the lowest level, a solution to modules could be Object Literals. At a higher level, modules could be created using the Module Pattern where privacy can be simulated (I’ve written about this before). At an even higher level, modules can be implemented with AMD - which is something I need to look in to in more detail (perhaps a future blog post?).

Addy had explained a lot of concepts, so it was time to merge them together. To build a large scale app, Addy was proposing that we separate our code into:

1. The Application Core - Using the Mediator pattern
2. The Sandbox - Using the Facade patten
3. Modules - Using one of the module solutions

At the end of his talk, Addy showed us an impressive demo (another to-do list) where he swapped jQuery for Dojo and his app just carried on working.

Addy’s slides are available online.

Doug Neiner

Doug (@dougneiner) is an excellent speaker and really got across his point clearly. Having just had a rather technical talk from Addy, Doug’s talk was more related to building better jQuery code and felt like it probably should have occurred earlier in the day as it gave some context to the content the other speakers spoke about.

Doug spoke about how you can improve your code by not initialising everything at the start of page load. Use Modernizr to check whether functionality is even supported (what’s the point of implementing something that isn’t even going to work?); and use tricks like measuring how far the user has scrolled before implementing functionality that is based far down the page (JIT initialisation).

Doug also spoke about making code less brittle by using jQuery functionality such as .prevAll() rather than .prev(); and .closest() instead of .parent(). Whilst these functions may be slightly less performant, in the majority of cases the performance hit is so minor and unimportant it doesn’t actually matter. If another developer changes your HTML, your application isn’t going to break.

His talk had a couple of excellent quotes:

Write code like you spend money!

Don’t invest everything in to your code at the start, get something up and running - and then invest in it later on if the code proves useful.

Write code like you buy a car!

While we’d all like a fast car, if we have a car that gets us from A to B that is normally sufficient. Faster cars whilst impressive aren’t worth the cost. So weigh the difference between quality and cost.

Doug’s slides are available online. Sadly, there was no to-do list.

In Summary

If today was an episode of Sesame Street, the two themes would be to-do lists and how much the Android default browser sucks. But jest aside, it was an awesome day (with an awesome after party) - and all the speakers, and the guys at White October should be very proud. If you want to read more, check out the slides (links throughout) or Jack Franklin’s notes.

Can’t wait for the next one!