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?
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: In terms of the support?
Dave: Yes, because what they see is not CSS, it’s not CSS that’s going on is it?
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.
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.
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?
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.
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.
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?
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.
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.