Dave: Okay, with me here is Remy Sharp who is a jQuery expert. OS, Remy, you work for yourself – what sort of stuff do you do?

Remy: I work on a mix of things, I work on some client projects – if a client comes to me with an interesting idea, I’ll work for them for their project. I tend to work as a consultant, a hired hand to their project rather than delivering the whole project to a client – my client will have their own client, so they work through me.

Dave: Okay right, so you’re there to provide input and to keep things going, keep the skill level quite up, and to keep…

Remy: Yeah, I’m basically… I tend to try and be a hired expert in kind of front end but I do everything anyway so I get to cherry pick the work and I get my fingers stuck in all kinds of pies.

Dave: Cool. And how long have you been involved with jQuery for?

Remy: Since June 2006 when I posted pretty much my first article on the web and it was a JavaScript tutorial and I realised there was Prototype and script.aculo.us for effects and I discovered jQuery and, because I’m a bit of a lazy developer I prefer to kind of spend my time doing stuff rather than doing the donkey work. jQuery allowed me to skip all the difficult stuff and when I finished the article, I took that and just converted it to jQuery and it was 20 lines down to 2, and that was my first article.

Dave: That’s really cool because one of the things I like about jQuery is the fact that it allows us to do all the same things but doesn’t tell you how to do THE CODING WRONG OR RIGHT but just gives you the tools to not have to worry too much about the cross-browser stuff. What is that you think makes jQuery so popular, because as you can see from the graph I showed you earlier – 35% share across the JavaScript CATEGORIES.

Remy: Yeah, for me the reason it’s successful is the community behind it. I mean, it came at the right time and the CSS Expressions inside of jQuery make it very accessible. But it’s the community, the help, create all the documentation, create blogs and talk about it and actually implement it. The Evangelist team, they weren’t made to be evangelists – they’ve taken people who were blogging about it, and being passionate about teaching other people how quickly they can get up to speed with JavaScript using jQuery, upspeeding in creating effects and AJAX and so on, using jQuery. They then have been pulled in to be evangelists. But I’m absolutely convinced it’s all down to the community that have helped build us up and also about the IRC channel, it’s really heavily subscribed, something like 300, 400 people on there everyday, and there’s newbies and intermediates and advanced people going on there, asking questions. And there’s guys and girls wanting to answer questions just for the challenge of being able to solve these things. I think it’s a friendly community as well – I’ve been on some IRC channels where if the question is too easy for them, they’ll tell you to bugger off. They’re just rude to you and I don’t get that in the jQuery community at all, I haven’t seen that very much.

Dave: I guess it’s partly due to JQuery being a product people tend to get excited about. People tend to naturally think ‘this is incredible’ and they want to share it with friends and when they get someone who doesn’t know about it, I guess they want to, rather than push them away, encourage them and bring them along and teach them everything they know. That’s going to help a lot.

Remy: The other thing for me is the CSS Expressions, the actual CSS part of it. I run jQuery for designers because I think that web designers like the front end people who just know CSS and know how to cut a mock into HTML but haven’t really touched JavaScript, they can take a CSS Expression and go ‘oh yeah, I understand if I can style it using this CSS, I can do something like add a class or add a click event using that CSS as well’. And people instantly get that. Once they understand they can use CSS to get into that particular area of the DOM and just manipulate it a little bit, they get it. I think the kind of ‘click’, the eureka moment is really, really early on with JQuery. JavaScript takes a little bit longer to understand how to navigate down to that specific point and some of the other libraries, they do more things… like Prototype is very good for extending the JavaScript language whereas jQuery is very much find something and do something to it.

Dave: Find something and do something to it is like a mantra people hold on to – I guess it’s quite a powerful way to think about it because it just makes sense to people. I think one of the areas I’ve noticed particularly with designers is they see the CSS Selectors and think it’s brilliant but WITH SUPPORT you’ve got to get across that message that it’s not a CSS engine you’re thinking about, it’s the JavaScript engine. How’s that work? What’s going on there?

Remy: In terms of the support?

Dave: Yes, because what they see is not CSS, it’s not CSS that’s going on is it?

Remy: No, underneath jQuery is an engine called Sizzle which is by John Resig and it’s completely stand alone piece of software that can be ported to any library if you want to, or write your own. What that’s doing is deconstructing that CSS selector and finding the right DOM nodes but is also detecting native functionality inside the browser. Safari 4 for instance has Query Selector and Query Selector All which are methods on the DOM that you can pass the CSS selector in and the browser will natively go and grab that content and give it back to you. So, inside of Sizzle, it detects that functionality and doesn’t bother with all the code that does all the searching inside of Sizzle. It just says ‘I will defer to the native functionality’. With IE 6, it’ll say ‘right, there’s no Sizzle here, I’m going to deconstruct this CSS selector and search through the DOM nodes and try and do it in the most optimised way’. I know there have been lots of speed tests as each library releases each selector engine they all go through this Slick Speed thing. Sizzle is currently running the lead with that and it’s the latest, one of the last releases of selector engines. One my pet things is to try and think about how you’re writing a CSS selector, it should be treated like CSS but CSS is native to the browser so in IE6 if you do .header it’s quick because it’s native but in IE6 and JavaScript selectors it means ‘search every single DOM node for this class’. It’s looking at every DOM node – if your DOMs very big, like 2000 elements, you can narrow that down by just doing div.header. So, it’s still down to the browsers a

nd browser support but Sizzle will even the playing field and you won’t have to worry about the support but the browser is going to be faster, depending on how new it is.

Dave: So there’s two real benefits here. First, you don’t have to worry about ??? anything in the jQuery documentation, any kind of selector that you can imagine will happen across all browsers but it will be faster in a faster browser. So there’s a two-fold benefit there, you don’t have to worry about older browsers like IE6 but you can get all the performance benefits of say IE8.

Remy: Yeah, I mean for a small application or a even a medium size application you’re not going to notice the difference of speed of selection in IE6 compared to Safari. It’s unlikely you’re going to be able to spot that. If you’ve got a client web site or a portfolio website, you’re not going to see that difference, but if you’re working on a very complicated website that has a huge amount of JavaScript behind the scenes, you’re trying to save milliseconds all the time. You think about optimising, just as you would cache variables, you’d optimise all the code as well as your CSS selectors but from a developer’s point of view working on an average range of portfolio work, project work, the selectors are going to be quick and they won’t need to worry about that kind of performance difference. But jQuery, yeah like I said, completely evens out the playing field for that kind of thing.

Dave: Cool. So, one of the things that we tend to find is that you get a project and you use one tiny bit of jQuery, so you’re writing a nice hacky bit of jQuery that does a nice sort of thing – something slides up and down. Then over the course of six months suddenly you get a huge amount of things sliding down, across and up and all over the place, and you go back to it and you think ‘if only I’d thought about organising all this stuff earlier…’. What kind of tips can you give for making sure you write code, because obviously jQuery is quite concise but you can easily end up with a mess. Are they any ways you can help overcome this?

Remy: Yeah, I mean, it comes down to planning, for one, but some of things I would do is… Paul Irish blogged about a pretty straightforward technique – what you do is look for an ID on the Body element and use that as your READY function. You have one start up file and it’s an object that has the ID of the Body as its key and it has a function associated with that. So if you’re on the landing page, the home page, it’ll run a certain kind of start up block of code and if you’re on maybe the search page it’ll only execute a different set of code on start up.

Dave: Oh, so you get a different set of jQuery functions happening depending on what page you’re on and what stuff needs to happen. That’s quite clever.

Remy: And I would take all my plugins and separate them out into separate files where I know they’re going to be reused either across the web site or other projects. But personally, I would also, for production, release that all into one file so it would be unified anyway, but during development, certainly plugins would be separated in separate files or maybe one file that would contain my plugins. I would have boot up code, start up code, in one separate file with the key value pair for a kind of ‘home page runs this code, search page runs this code, article page runs this code…’ and so on. And one of the other things I’ve had people ask me about is having a lot of markup inside of your jQuery which is something… the chap I was speaking to was saying, we’re trying to separate content from code and I see this process happening where they know they want to dynamically create something on the page where it slides out and something happens. So it’s like shifting markup into JavaScript. I mean, you can immediately see the problems with that because your markup changes five years down the line or even six months down the line and you’ve forgotten about this piece of JavaScript that contains markup. You can use templating systems to get around that kind of thing. You can inject it using AJAX hits or you can have it embedded on the web page already and reveal it as you’re going along. But you need to think about how it’s tucked away. Those are the kinds of things I try and use when I’m building a project.

Dave: Well that sounds like pretty good advice. On the subject of plug-ins. I mean, the idea of creating a plug-in probably seems daunting if someone has come from a design background and they’re you’re just getting their hands dirty with jQuery and they’re quite comfortable with taking and finding something and doing something with it if you know your selectors and you know a few of your actions. At what point should you start thinking ‘this could be a plug-in, I should be doing something that’s reusable’? How would you make that decision?

Remy: The most obvious one for me is if you’re working on two different websites where you’re copying and pasting the code. That’s the first point at which you should say this should be a plug-in here. But typically you’re working within one project and you’re finding you’re re-using a bit of code all the time. My rule of thumb is if my code that’s a candidate for a plug-in, if it doesn’t need to know exactly how it’s marked up and exactly how the action should happen and how it should be styled, then that would be a plug-in. For instance, if I have a link that always reveals a particular type of content, like a Terms and Conditions link would maybe make the content slide down and I have another link somewhere else and it’s making some other content show – having a reveal link is a fairly common pattern for instance. So I would have a plug-in called ‘Reveal’ which would say ‘look at the link I’ve just clicked on, take the hash off the URL, go find that hash in the document somewhere and animate it into the page using the passed in effect’. So I could now do ‘search through all the anchors with the class Reveal on it and here’s… so I do .reveal open brackets slide down. Or maybe I could have that as part of a class or a metadata on the actual link itself so it could read that piece of metadata out in my plug-in to reveal this ID on the page somewhere. So it’s really, it’s when you start repeating code, that’s the rule of thumb. If you repeat code a lot it’s probably going to be a good plug-in. If you’ve got a friend who you think would use it, that’s a plug-in as well. Developers should probably talk to each other more than they do already (laugh from Dave), and that will give you an idea of these kinds of things.

Dave: Yeah, definitely we do see certain common functions that you do tend to re-use quite a lot. I guess, as you briefly mentioned there, it comes to a point when you want to make a nice re-usable function. How do you translate it into something very specific that can be re-used, what’s the secret there?

Remy: It’s looking, it’s trying to be able to foresee not all of the possible uses for this piece of code, but the common uses for this code. I’ve been in enough projects where you’re told to make something so generic and so flexible that it en

ds up being so generic a piece of software that nobody knows how to use it anymore because they don’t know what all the arguments are. But, when I’m looking at a piece of code and thinking this looks like a good candidate for a plug-in I try and think about how else it will be used, like for instance, when I’m sliding down like in that previous example, what if slide down isn’t the only animation effect I want. What if I want to be able to pass in the duration of the effect, maybe an ease in as well? So, if I think about those kinds of aspects of the design of my little piece of code, that’ll help me actually write the piece of code, because I strip out the things that are specific to this particular effect or this particular interaction. I’ll strip those away and also I’ll try and think about, if I have specific selectors inside my function that are targeting specific areas in the DOM, how do I make that more generic? Can I have some passed in or should I be creating those DOM nodes on the fly? That kind of thing. You have to make a judgement as to how far you’re going to re-use it basically and I’d strongly recommend don’t try to make a plug-in that can be re-used for everything because (laugh from Dave) it’ll end up in the bin.

Dave: Alright, cool. So what’s the future for jQuery? It seems to be growing massively. I mean, a couple of years ago no one would have heard it and now you can’t move without seeing the guides and the tutorials on the internet, and every one seems to be talking about it. Where’s it going, what’s the next stage?

Remy: Well, the next stage are … the mobile version of jQuery which I assume is going to be released around the same time as 1.4. I don’t really know, I mean it’s ending up on a lot of websites, I mean the EDM that Google offer – I’m not sure if everyone knows about that, I met someone today who didn’t know about it – Google have a CDN for all the large JavaScript libraries so it means that, for instance, Stack overflow has the Google-hosted version of jQuery and it means that if you had it on your website and you use the same link, it’ll already be hot cached inside of the browser so it will load faster. So I was being asked whether or not browsers should be preloading jQuery into the browser – you can just kind of enable it and start using it. At the moment we have Google CDN which is kind of close to actually having that. In terms of the far future, I think the adoption is going to carry on, they’re going to keep growing the community. There’s four conferences for jQuery next year, one in London, Boston and San Francisco and then an online conference where people can actually do live Q&A. Just keep telling people about it (laugh from Dave) and sharing how easy it is. I mean there’s always beginners to every single industry so if we show them what the options are…

Dave: I was having a look into the jQTouch plug-in for jQuery which seems to be heavily optimised for iPhone or mobile Safari browsers. What’s all that about, what’s going on there?

Remy: As in the optimisation?

Dave: As far as I can tell, it’s doing more than just animating. It seems to be using this built-in to…

Remy: Yeah, so what jQTouch is doing is – because Safari 4 and particularly the iPhone WebKit have native animations built in, they have CSS animations basically. So what jQTouch is doing is converting your request for animation, in fact it’s not… I wrote that (laugh from Dave)… I’m working on a project that is using jQTouch and I’ve been hacking the bits of it to do what I wanted to do so there’s a bit of crossover there… It’s translating, basically saying ‘we want to animate left to right’ so it’s writing in the CSS expressions, giving the DOM node the CSS properties to actually trigger the animation to go.

Dave: Right.

Remy: So, it’ll prep it with ‘WebKit transition should be this’, it needs to translate to nought pixels to 320 or whatever it is and then it will actually apply it. WebKit actually also has a WebKit transition end that you can bind on to say the transition is now finished, trigger this call back and maybe you can do your piece of AJAX or whatever you do. But it’s using native CSS animations and applying them bit by bit against the DOM nodes.

Dave: So you get to use all the built in animations to make it really smooth and cool and you’re still using jQuery.

Remy: Yep. Yeah. What I’ve been doing on recent projects that I hope to kind of open source as well is create a plug-in that sits in between the two, that says ‘is there native WebKit animations and if there is take whatever animation data you gave me, if you want me to animate left or the opacity, use the native ones, if it’s not then use jQuery’s built-in animation functions’. So it can be smoother and faster and easier on a browser if it’s native than if it were actually run through JavaScript. That’s what I really want to see, I’d like to see jQTouch move in that direction and create a library that isn’t specifically for iPhones but a library for any kind of mobile device and you can still use it and it’s not dependant on WebKit transitions and I suspect it will end up going that way, the same as HTML 5. I’m kind of digressing a little bit but the Web forms 2.0, all the kind of built-in validation into the forms and the input types – I’d like to see a jQuery library, in fact the jQuery Validation library, detect that functionality and if it’s there let it just happen and if it’s not, plug it. So we can start making use of native functionality inside browsers when it’s available.

Dave: …it’ll just then happen…

Remy: Yeah, I mean, there’s’ still discussion as to whether or not the way the validation is happening inside the browser is absolutely correct and whether it should be mirrored or not but that’s what I ‘m kind of excited to see. Plugging native functionality if it’s not there and using native functionality if it is there and just making it easier for the user to get there.

Dave: It sounds really exciting. And I gather you’ve got a conference coming up next month?

Remy: Yes, I’m running a conference for JavaScript developers, not focussed on libraries such as jQuery and so on but getting underneath the skin of JavaScript and how it all works. Conference called ‘Full Frontal’. It’s in Brighton on 20th November and it’s being held in the world’s first or UK’s first purpose-built cinema, its a hundred years old this year. We have speakers from Yahoo!, well not specifically from Yahoo But I cherry picked all the speakers before I even announced the conference, Christian Heilmann, Simon Willison, PPK (Peter-Paul Koch). Talks on accessible JavaScript, JavaScript in mobile devices, in HTML 5, mashups … the dictionary definition of Full Frontal is ‘nothing held back or concealed’ so the idea is really getting

to the guts of JavaScript. After @media AJAX finished last year I really wanted to see a JavaScript conference in the UK.

Dave: I guess for people who want to do more than just use the tools but really understand what’s going on, how they can make full use of it and get deeper into it.

Remy: Yep, I mean I see the JavaScript community as two sets of people. People who use CSS and understand that, and don’t particularly want to understand JavaScript and what’s happening inside of jQuery and the other group of people who know JavaScript well and are using jQuery to just kind of skip the donkey work. My conference is for beginners, intermediates – advanced people are going to know this stuff as well they’re going to get to learn a few edge technologies but Full Frontal is aimed at people who want to understand JavaScript and see what we can do with it. It’s a great language, it’s in every single browser, across the world all over the place so I think it’s worth looking at basically.

Dave: Cool. Very exciting. Right, well thanks very much, it’s been a pleasure.

Remy: You’re welcome. Cheers.

Thanks goes to Wendy Phillips for transcribing this interview.

If you recognise that the mobile web is important and you need help deciding on a strategy, then book a mobile consultancy clinic.

Book a consultancy clinic or contact Rob about a more in-depth review.