The SitePoint Podcast: jQuery: Novice to Ninja

The SitePoint Podcast

Kevin Yank is joined by Opera Software’s Bruce Lawson, SitePoint author Ian Lloyd, and Kyle Weems, creator of the CSSquirrel web comic, to discuss the latest uproar from within the W3C HTML5 Working Group. Related posts: 1. SitePoint Podcast #33: Team Opera at WDS09 Kevin does the rounds at

Running time
0h35m
File size
33.00MB

Download Original File | View original post

Episode synopsis

Episode 50 of The SitePoint Podcast is now available! This week, Kevin Yank (@sentience) is joined by Earle Castledine (@mrspeaker) and Craig Sharkie (@twalve), co-authors of SitePoint’s new book, jQuery: Novice to Ninja.

Listen in your Browser

Play this episode directly in your browser! Just click the orange “play” button below:

A complete transcript of the interviews is provided below.

Download this Episode

You can also download this episode as a standalone MP3 file. Here’s the link:

Subscribe to the Podcast

The SitePoint Podcast is on iTunes! Add the SitePoint Podcast to your iTunes player. Or, if you don’t use iTunes, you can subscribe to the feed directly.

Interview Transcript

Kevin: February 26th, 2010. SitePoint co-authors Earle Castledine and Craig Sharkie drop by to discuss the jQuery JavaScript library. I’m Kevin Yank and this is the SitePoint Podcast #50: jQuery: Novice to Ninja.

Today’s show is all about JavaScript. So whether you’re a JavaScript expert or you have always wanted to add JavaScript to your toolkit, today’s show is for you. We’ve got the two co-authors of SitePoint’s latest book, jQuery: Novice to Ninja, together to talk with us. We’ve got Earl Castledine who is known in web circles as Mr. Speaker. You can find him on Twitter @mrspeaker.

Earl is well known for his experiments bending web technologies into new shapes. His latest experiment, TurnTubeList, lets you take two playlists of YouTube videos and mix them back and forth like on a DJ turntable and the user interface is all done with JavaScript controlling the two Flash movies from YouTube, and it’s really impressive stuff. Check it out at TurnTubeList.com.

Craig Sharkie is known on Twitter as @twalve and Craig has been working for big names like AOL, Microsoft, Yahoo!, Ziff-Davis, and now he calls Atlassian home. He has been touring and speaking about JavaScript for years. He likes to stay he spoke about the “good parts” of JavaScript before Douglas Crockford did.

Guys, welcome!

Both: Hey Kevin!

Kevin: This is a rare pleasure that I get to speak with two SitePoint authors in my time zone.

Earle: It’s a good time zone to be in I think.

Kevin: Craig and Earle are both Australian. They’re both in Sydney at the moment. I’m in here in Melbourne, but wow, it doesn’t feel very far away compared to… Usually we get authors from America and Europe and all over the place, but it’s great to be able to showcase some Australian talent with this book.

So this book, jQuery: Novice to Ninja, is it fair to say it’s a beginner’s guide to jQuery?

Earle: I guess the title is a bit of a hint. Yes, it is beginner book, but it ramps up towards the end. So toward the end, everyone can have something to learn about jQuery.

Kevin: For those who don’t know in our audience, can someone describe what jQuery is?

Earle: Those who don’t know what jQuery is?

Kevin: (laugh) Exactly.

Earle: To the back of the class for you guys! jQuery is—well it’s the brainchild of John Resig. It’s a JavaScript library to help manipulate the DOM, basically. That’s jQuery’s chief feature, is being able to move stuff on a page. It’s features are – can select things on the page, like getting paragraphs and move them or flash them, or do anything that you can imagine to them and it has also got a neat Ajax helper library too. So there are sort of two parts to it, DOM manipulation and a cool Ajax library. Would you say that’s fair, Craig?

Craig: Yeah, definitely fair. It’s a really easy way for non-classic developers to get access to some of the features that would normally take a lot more effort than you can get by just picking up our book and starting from scratch.

Kevin: What do you mean by non-classic developers?

Craig: The language uses syntax which is very familiar to the design community through CSS. So you don’t have to worry about understanding a lot of the under-the-hood features of JavaScript before you can actually start using jQuery. So you will end up loving JavaScript and will want to get to know it a lot better, but you can get a lot of features happening really quickly just by simply plugging jQuery into your webpages and moving on from there.

Kevin: So jQuery adds this layer on top of the JavaScript language. It’s a layer that will be very familiar to people who come from a background of CSS?

Earle: That’s right. The way that you select things on the page is basically CSS selectors, so if you know how to style something then you know how to select it and then if you know, on the end, you put .hide, then—wooh!—it hides, and then put .fade—wooh!—it fades. So getting stuff working quickly, it’s really fun. It just makes it really fun to play with the page.

Kevin: All right. That’s really where jQuery got its name. It was about getting a set of elements, a set of parts of the page based on a CSS query, right? But it’s really grown up from there. I mean, what are some of the parts of jQuery today that people don’t really know about?

Earle: I think the custom event handling stuff is really powerful and a lot of people don’t end up going down that road where you can start setting up your own events to trigger, so you’re only writing code once and triggering them for multiple parts on the page. This does get quite, I guess, complex, compared to the stuff that you learn at the start, which is just making something zoom up and down. You can start building some sort of really industrial strength applications with the advanced features without dropping into JavaScript as much as you much as you’d need to. You’d need to write a heck of a lot of JavaScript to do the same thing.

Craig: Also something you can do is you can extend the selector engine as well, so that— People who are familiar with CSS would be familiar with :hover or :last-child or :first-child, but with jQuery you can actually develop your own series of custom filters so the syntax to getting access to an element on the page in any sort of statement you want is really straightforward. That’s another feature of the language is that if you can think of an action, the first point of reference in the API is likely going to be that action. So if you want to hide something as Earle said, it’s not toHide or hideElement or some long syntax; it’s simply the word hide. So you find a selector, you add a single action to it, and you get a great response.

Earle: I think the custom selector thing that Craig was talking about is really cool because, I think it was from the book that you made, is it below-the-fold selector?

Craig: Mm-hmm.

Earle: He’s made his own selector so instead of saying selecting .classname or h1, it was :belowthefold, I think it was. It would narrow it down to anything that was below the page fold. It was just a way that you could start selecting things like that wasn’t a part of the core jQuery selector engine.

Kevin: Wow, that’s really cool.

Earle: Yeah, I liked that.

Kevin: Is it fair to say that once you start using jQuery, your JavaScript code ends up looking really different than from the code you would have written before?

Earle: No… Hopefully, it looks better.

Kevin: (laugh) Better is different.

Earle: You can’t separate the fact that if you got serious into writing jQuery and then in the end you want to learn how to write JavaScript properly. You can still write terrible JavaScript using jQuery.

There aren’t a lot of people writing terrible JavaScript because you can write such beautiful JavaScript. The only thing is that you stop reinventing the wheel to do things like being able to select elements cross-browser nicely. You let someone else worry about those kind of cross-browser issues, which is good.

Craig: And we were really keen to make sure that while the book focuses on jQuery that all the examples use best practice where possible, so that if you follow our examples by the time you finish the book, you should come out of it as a much better JavaScript programmer than you went in, even a better programmer than you intended to become.

Kevin: Yeah, that’s something we try to do with all SitePoint books, so good work guys, good work.

Both: (laugh)

Kevin: Obviously jQuery is not the only JavaScript library out there.

Earle: No, I think it is. (laughing)

Kevin: (laughing) “I think you’ll find it is!”

Craig: There’s one or two out there as well, yeah.

Kevin: For you guys, it’s the only choice, though?

Earle: Now it is. I play with any new thing that ever comes out, ever, and try to use it in a production environment if I can get it past my bosses, but now I’ve got to the point where—okay, this is arguable—but jQuery has sort of won the library battle and that’s not 100% true because there’s other libraries concentrate on different… They’re starting to develop their own niches. In terms of speed, jQuery is not the fastest library out there.

Craig: It’s the second fastest and that’s arguable.

Earle: Yeah.

Craig: What will generally happen— I think one reason why jQuery is really valuable to us as developers is that there’s a massive community. So it’s not just the strength of the language itself, there’s also the strength of the community behind the language. For example, I met up with John Resig in WebStock last week in Wellington and we were talking about the fact that a competitor library will come out with a claim and John will go and check out to make sure the claim is correct or incorrect, and if he finds out that someone is actually able to make a claim that their library does X better than jQuery, then he’ll change the way jQuery works to match or better that competitor library.

Kevin: There are a lot of gray areas on this stuff though. When you talk about performance, I mean do you judge the performance by how fast it is on the fastest browser or how fast it is on the slowest browser?

Earle: They usually have a big matrix setup to show you how it runs over every browser. The performance issue is— Okay, for me, it’s become less and less. I haven’t had— Even when you’re making crazy ridiculous widgets, where things start bogging down, it’s only when you’re doing something really quite crazy that you care anymore when you start talking about milliseconds for 15,000 operations, it’s like, well, great, the other one’s 5 milliseconds faster, but the end user’s not going to notice it, in a lot of cases. It depends, of course what you’re doing.

But also other libraries concentrate more on classical object-oriented classes and making these kind of frameworks where you can extend classes in a classical sense, object-oriented programming, which jQuery steers away from. If that’s what you’re looking for in a library, then perhaps you should check out the other libraries.

Kevin: I want to talk about jQuery from two different perspectives. The first is for someone who doesn’t know JavaScript at all. I mean, we mentioned earlier that jQuery provides a welcoming set of features for people who know CSS and can smooth out some of the difficulty and the strangeness of JavaScript when you first encounter the language. Would you actually recommend someone who doesn’t know JavaScript learning it with jQuery and then exploring the language from there?

Earle: Sure.

Craig: Definitely, definitely.

It’s one of those things that is so easy to use and it’s so easy to use the library well, that you can’t help but try and push yourself and your access to JavaScript. Before you know it, you will be doing fantastic manipulations of the DOM it will be without any classical training.

Earle: And it’s basically, again, it smoothes over the stuff that’s really—can I say, crap? I’m going to say crap—about JavaScript in the browser. If first thing that someone coming from no experience in JavaScript that has to do is write a nice cross browser getElementByClassName, we’ve already lost them—they’re gone. They don’t want to do that. They just want to be able to get elements by class name and then figure out what they want to do with it, and when you want to do something that’s not in jQuery, that’s when you go “Well, how should I do this?” And usually that answer is JavaScript. So you can even sort of blurs the line between when you start actually getting into the JavaScript, if that makes sense?

Kevin: Yeah. And the other perspective is because everyone out there who is an experienced JavaScript developer goes through this period where they built up their own libraries, their own code base that they know and they trust, and they understand how every line of it works and they know if something doesn’t work they’re going to be able to fix it because they built the thing in the first place. Obviously, the two of you have each gone through your own, um, journey and it ended with “I’m going to throw away my own getElementByClassName, I’m going to throw away my own events compatibility layer and I’m going to trust that jQuery has the best implementation.” How did you get there?

Earle: Mine was called E-jax, for Earl’s Ajax Library. Yeah, that didn’t last very long. It lasts up to the point where you use it in a project that you realize you’ve made errors in it and then you should go back and fix it in every project you’ve used it in, and then you don’t, and then you go “Someone else should be taking care of these fundamentals, not me.”

Craig: That’s the thing in jQuery it provides us with a really strong set of fundamentals, but it’s got a fantastic plug-in function as well so that if you can’t find it in the core language—which is quite likely, because it’s nice and clean and fast—you can build it in the plug-in and then you quickly find that all you’ve done is transferred your old library into the new syntax of jQuery. So you’re still out there, you’re still able to make some crazy functions and you can rely on yourself and distribute to the community, but it’s using a foundation that you know that if you walk away from a job, the next jQuery developer coming in behind you can read your code straight away and that means that you can expand the team quickly, you can move around quickly, you can move one job to the next and know that you’ll be able to have a really slow barrier of entry because it’s based on something we all know and love.

Kevin: What is jQuery like to debug? If it does something you don’t expect it to do and you have to drill into that black box and see what’s going on, what’s that like?

Earle: You mean if there’s a bug in the source code of jQuery?

Kevin: Whether it’s a bug or just something you didn’t understand.

Earle: Generally you never have to actually get to the jQuery library to look at it unless you’ve done something pretty crazy. Usually the debugging follows how you’d normally debug. You break into functions or alert if you have to and you figure out what’s going on. You generally know you’ve done something stupid if the error’s occurring in the code that’s inside the jQuery Library. Not something to stupid, but you go “Oh, hang on, I passed in something that’s not expected.” Usually it’s quite a high level thing. But getting into the code – if you seriously mean getting into the jQuery code, it’s very beautiful JavaScript code.

Craig: Yeah.

Earle: If you want to have a look. I mean I love going through the source code of that. That’s why I’ll always keep it the non-minified version until it goes to production for QA.

Kevin: So you get the feeling that for something to be this efficient and this fast that they had to do some things in some really non-obvious ways and if you dig in to that code, you’re going to get lost really quickly because rather than doing things the way that makes beautiful code, they’re doing things the way that makes fast code. Is that true at all?

Craig: There’s a lot of beauty in the speed of the code as well. So if anything, by looking at the source code itself, you’ll quickly become a better programmer in the way you lay out your non-jQuery JavaScript.

Earle: It’s not … there’s no weird tricks in there. There’s tricks, but they haven’t gone … it’s not all obfuscated and weird. It’s very readable.

Craig: Yeah, and often the tricks are things that you might not necessarily do the first time you’re writing JavaScript there so you might target a browser and you’ll get a great response. But they’ve made their code flexible to accommodate the cross-browser issues so that if you start looking at their code you start learning at first practice how to do better code.

Earle: But you usually don’t have to get into it.

Craig: Very, very rarely.

Kevin: All right.

Earle: You can figure out in your own code what’s going on.

Craig: And often you’ll— If you spend any time in the IRC channel, you’ll start seeing that there’s a lot of people out there who are quick to help. If you find something which comes up as a bug, that you think is a bug, then ask the community and the community will often provide with a quick answer.

Kevin: So let’s talk about the community. JQuery, the first name that comes to mind when you hear jQuery is, as you said, John Resig, the creator of the library. How big a part of the community is John? Is he still the sole man responsible for jQuery, or has it become a community effort?

Earle: The ‘soul man’…

Craig: (laughing)

Kevin: (laughing)

Craig: It’s definitely a community effort but it’s good to know that there’s someone with a hand on the tiller still. So there’s a growing team of developers out there who are committing constantly to the source code, but there is one person who knows what’s going on who loves it so dearly that he’s happy to put his name to it.

Earle: It’s pretty crazy. So many times on the dev lists I’ve submitted something and then 10 minutes later there’s a reply from John Resig, and you go “Are you awake all the time?”

Kevin: You guys got to meet John Resig recently at WebStock in New Zealand, right?

Craig: Yeah.

Earle: I met him over in Sydney. We had a jQuery meet-up and he came along to that. It was really good.

Kevin: So did the subject come up that you guys are just about to publish a “jQuery Ninja” book and he has a “JavaScript Ninja” book coming up, were there any hard feelings there?

Earle: I skirted around that issue, yeah.

Craig: I am worried about that issue, yeah.

Kevin: What’s he like?

Earle: Really nice, nice guy.

Craig: Yeah, very unassuming. He’s like his library. He just knows what he’s doing. One of the things I thought was quite strange that he was saying that he barely really codes anymore, he doesn’t build product sites with his library. He spends his time building his library.

Kevin: Mmm. So that’s where I guess the community becomes really important.

Earle: Definitely. It’s not just John anymore. There’s a whole bunch of the core guys in the jQuery team now. So I think that it is probably getting out, getting away from just John. In fact, didn’t he just recently have to make it into the foundation?

Craig: The foundation, yeah.

Earle: So if John gets hit by a bus then jQuery keeps going; which is kind of important.

Kevin: Craig, in your bio on the book you talk about how back in the 90s you used to talk about the “good parts” of JavaScript versus the not-so-good parts, and that’s something Douglas Crockford from Yahoo! has made a career around now.

Craig: Yes.

Kevin: How important is that distinction these days once you use something like jQuery? I suppose it leads you towards parts of JavaScript to use them more and to ignore parts. Does jQuery provide a guiding force towards those good parts of JavaScript or is it still a minefield out there?

Craig: JavaScript itself is still a minefield and it will continue to be so, unfortunately. There needs to be— Because of the way that JavaScript is so ubiquitous with the way the Web is being built, there needs to be maintained a strong sense of backwards compatibility. So a lot of the code that we’re seeing growth in the ECMAScript, it’s not in changes to the way code used to work but it’s in building additional features for us to use.

Earle: So all the bad stuff’s still there.

Craig: That’s it, yeah.

Earle: You can still make atrocious JavaScript with or without jQuery.

Kevin: But hopefully you’ll reach for a jQuery feature before you’ll reach for a JavaScript feature.

Craig: Yes.

Earle: And you’ll also find that especially when you start using plug-ins that you start looking at the code of plug-ins and if they’re good plug-ins you start seeing good code as well. I’ve found lots of little tips like that where I went “Oh, that’s nice, a nice little way to do it” from a good plug-in.

Kevin: So it goes without saying that the core code of jQuery is all good. Are there good parts and bad parts of jQuery is what I’m wondering? Are there plug-ins to be avoided?

Earle: Plug-ins to be avoided? Oh there’s some terrible plug-ins.

Craig: If you see a plug-in that’s advertised on jQuery’s site, then you can trust it.

Kevin: Really?

Earle: But still research.

Craig: Exactly. You still have to research the plug-in. You still have to make sure that it suits your purpose. It’s like you’re allowing another developer to put his code in your website. So you’ve got to do it with a sense of not trepidation but you’ve got to be really aware of what’s going on.

Kevin: Yeah, it’s like giving someone the keys to your car. You need to make sure you know who they are and that they’re going to bring it back.

Both: Exactly.

Kevin: Speaking of jQuery plug-ins, do you guys have some favorites, some ones that aren’t so well-known that you’d like to talk about?

Craig: I’ve got a fantastic one that I built for Twitter.

Kevin: Well, okay, it’s your own plug-in so that’s kind of cheating but go on, tell us about your plug-in.

Craig: It looks exactly like a standard action from jQuery. You simply find a selector, tell it to be a Twitter and it fills up that selector with tweets. So it’ll take a username and will go to the stream and access the Twitter stream and just fill up the page. It uses the features of jQuery so that you get animation and it’s the seamless Ajax tie-ins so that you can sit there all day and watching the stream pass you by.

Kevin: That’s really cool. You talked about generic JavaScript libraries versus specific JavaScript libraries and I think jQuery started quite specific. It solved one real problem when it initially began but it has grown to very much be a generic library, but people are building specific libraries as jQuery plug-ins now.

Earle: Like what?

Kevin: Well, like Craig’s Twitter plug-in. That’s something that previously you would have downloaded a JavaScript file with no dependencies and it would have had its own event handling code in it and its own DOM manipulation code in it and nowadays people are building on top of the jQuery foundations.

Craig: Yeah, we do it here at Atlassian. We’ve got a library called AUI, which is the Atlassian User Interface and it’s exactly that, it’s as a base we’ve got jQuery but on the top we’ve got specific functions which suit our products.

Kevin: So is there still a space— If you guys have the choice between a jQuery plug-in and a raw JavaScript library, are you likely to look at the JavaScript library these days if they do the same thing?

Earle: Do you know, I still— Usually if I’m just coding, I’ve got a little idea, I’ll often just code it up just straight in JavaScript while I’m just prototyping it and getting it up, but I find that starting with j— I mean you get so used to the convenience of it that you do plug it in there, but that’s not to say you’re always going to want to do that. If you’re looking to keep the smallest code base possible, keep things running, like you said before, it is a layer. You’re putting a layer on top of what you’re doing. If you don’t want that layer, then sure, there’s nothing wrong with writing your own still, but don’t tell your boss because they’ll know it takes longer.

Craig: The other thing that if you do end up ducking back in every now and again to the JavaScript like Earl and I both do, is you start to get a sense of the fact that if you’re writing a selector in JavaScript as opposed to in jQuery it takes a long time to write, and that gives you a sense of understanding that what jQuery is about to do might start to be slow and it sort of gives you an alarm bell that when you’re making this like you should really look at the way you’re constructing it so you get the optimal performance out of it.

Kevin: So it’s not magic. If it would be a slow thing for you to implement, chances are it’s a slow thing for jQuery to do.

Earle: Yeah, nothing’s magic.

Craig: But it’s becoming slightly more magical all the time.

Kevin: Yeah, I’m sure there are some good ideas in jQuery that you wouldn’t necessarily think of and therefore you get the advantage of those optimizations but that’s a good cautious place to start with. Maybe jQuery isn’t magic.

Craig: Well, if you pretty much— Maybe you can start off thinking that it’s magic but if you’re a real nerd then you’d never ever trust magic. So you’re walking a fine line doing it.

Kevin: So what’s going on with jQuery at the moment? I know 1.4 is sort of just out as we record this.

Craig: Yeah, 1.4 actually has came out. It came out Thursday night or Friday night last week.

Kevin: Yeah. So … what’s exciting and new in 1.4 and what’s coming in jQuery that you guys are looking forward to?

Earle: I want to see what they’re doing with the mobile stuff. I think they’re talking about getting a specific jQuery mobile build and targeting sort of mobile platforms. I think it seems it’s got a master plan there. I’m keen to see what that master plan is. It’s an interesting space. It’s a space that I’m a fan of at the moment so that’s what I’m excited about, what’s coming up.

Kevin: Craig?

Craig: Coming up, like Earl was talking about, but one of the things that I find interesting in the mobile space is that they’re not talking about cutting browsers out of jQuery. They’ve got jQuery to a point now where they know that an optimization that I need to do for IE7 will still be of benefit to a compliant browser. So they’re not looking to move away from any different platform or browser, they’re looking at making the entire library itself better at each step, and because they’re, in 1.4, they really strengthened the live action so where before you would do a click, now you’re doing a live click and it means that you’re delegating, which increases the speed of the browser’s response. Based on the strength of that, they’ve actually introduced a new action called ‘delegate itself’ and delegate allows you to do the same functions as live but to do it in only a section of the page so it cuts down the DOM that you’re looking through, and you’re getting fantastic response from the browser on all the different platforms.

Kevin: Now you lost me there. I don’t know what these live actions are. Do you think you could take it a step back and describe that in more detail?

Craig: Yeah, actions are simply the things that we’re doing with jQuery so…

Kevin: Yeah, so like ‘hide’ before.

Craig: Exactly, like hide. Or like click or mouseover or mouseenter, but due to some browser variations, we never used to have that full access to all the different functions that you would normally expect. So you couldn’t do mouseenter through a live action.

Earle: Wait, were you asking what live was?

Kevin: Yeah!

Earle: Oh yeah, that was just… okay, so imagine if you wanted to make every paragraph on your page, um, alert an annoying popup when you clicked on it, and you’re like $('p').click and alert("Hey, how are going?"). It’s like that?

Kevin: Yeah.

Earle: That would be great, every paragraph on your page would – you’d click on it, it would pop up and pop up, “Hey, hey! That’s great.”

Craig: The problem comes in when if you added a paragraph to your page after the function’s been run initially…

Kevin: Right.

Craig: …your paragraph doesn’t know about the function that the other paragraphs are all using. With live, the live action works off the document itself and so any paragraph, in that case, any paragraph which is added to the document, it will then get the power of the methods of the other paragraphs are using.

Kevin: So live events provide a continual, a convenience where new event handlers are continually applied automatically to elements that are added to the document on the fly. So what’s new in 1.4?

Earle: That was there before. They really fixed it up for 1.4.

Craig: They made it faster and they’ve opened it up to more events.

Kevin: Yeah, okay. That’s cool.

Earle: A lot of people, that was their favorite part of 1.4, I think. Like, “Thanks! You’ve finally made the live work perfect.”

Craig: You can still write a click as an action but you have to be certain that the selector that you’re using will be available when the function is called and that it won’t change afterwards.

Kevin: Yeah.

Craig: Now, they’ve tweaked live to an extent that you don’t have to worry about it anymore, so you can get to a point now where the click as a native action by itself almost can be deprecated because you can just use live.

Kevin: So at this point, is jQuery so good that there’s nothing annoying about it?

Craig: No!

Earle: No…! Otherwise they would stop developing it.

Kevin: (laughing) So what annoys you about jQuery?

Earle: Well, to me—we’ve gone back to your thing—I like things being not abstracted away; I like to see where things are. So the convenience for me is also annoying that I’m giving up some of my control to it. But the convenience is well worth it.

Kevin: And I think that stops a lot of developers from adopting something like jQuery.

Craig: Yep. Definitely.

Earle: But until you use it, I think once you’ve used it for a while, you go, “Why did I waste so much time in the past writing this stuff over and over? I should have just used jQuery.” I think, okay, even if you’re not using jQuery, you need to be using a Library these days. Otherwise, you’re wasting time.

Kevin: Craig, what annoys you about jQuery?

Craig: One of my major bugbears at the minute isn’t so much of a problem with the Library itself but the fact that we still have to worry about downloading it. I’d love to see us come to a point where you can tell a browser that you want to add a library to it. So, rather than having to go to a CDN (a content distribution network) to get wider access to the files, the files themselves are available inherently in the browser. So I know when I jump on the train that the library that I was using when I was home on my network is still going to be available to me without having to go in and tweak the code around.

Kevin: Yeah, that’s exciting. Like, there are content delivery networks out there. It would be rare for you to download jQuery and make it a part of your project. Usually these days, you just reference it on the official server but that really makes it difficult to develop when you’re offline.

Craig: Yeah.

Kevin: Hmm, that is annoying. I do want jQuery in my browser.

Craig: (laughing)

Kevin: So this book is 400 pages long.

Craig: Yeah!

Kevin: And having written a book that size myself, I know what an achievement that is. Congratulations, guys.

Craig: Thank you.

Earle: Thank you very much.

Kevin: What are some of the things buried in these 400 pages that you guys are most proud of? I thought the below-the-fold plug-in was really impressive.

Craig: Thank you.

Kevin: Is there anything else like that we should be on the lookout for?

Craig: One of the things I also got proud of was when John Resig did his WebStock speech, the presentation of it, he was talking about some of the faces of jQuery which have less documentation than others, and I was very pleased to see a lot of the things that Earle and I have made an example of actually was present in John’s speech. So things like the end action, which you’ll come to know and love when you start to use it, it’s poorly documented but it’s in the book and we love it.

Earle: Yeah. I like the last part of the book where we really get into sort of the Ninja-ey stuff and I’m really hoping that there’s people pick it up who’ve never touched jQuery and end up making it to the last chapter and covering it all. That’s what— I think the way we structured the book, I really like. I’d love it if at the end, we’d converted a few non-JavaScripters into loving JavaScript. That’s what I’d like.

Craig: There’d been some guys at work here and they’ve said “Now I’m really looking for a book that lets them start from the beginning.” And I said, “Well, you’ve got it.” And they said, “Well yeah, but I don’t really know how to use the selectors that well.” And I said, “Well, the book does it.” So I think it’s really good that the book is able to get to an audience that has previously been a bit locked out from access to that level of development.

Kevin: At the front of this book, you guys went a little romantic with your dedications. This isn’t usually something that I pull out, because dedications can be quite personal. But they’re rarely this personal. Earle, your dedication reads, “For Amelia, I wanted to have a picture here of me holding a boom box above my head but they wouldn’t let me. Will you marry me? Earle.” And I know the day that that got submitted at SitePoint, everyone was talking about it and we thought, “Man, that is quite a lead time for a proposal.” And we felt really bad we couldn’t get the book out in print by Valentine’s Day for you, Earle. But how did it go?

Earle: Well, I’m now engaged so that was a—

Craig: Woo!

Kevin: Congratulations. Round of applause for Earle. (clapping)

Earle: Yeah, like you said, there was quite a lead time and so you know, I was really just concentrated on holding the relationship together so that…

Craig: (laughing)

Kevin: Yeah, we thought, “Oh man, that would be a tough last-minute change to have to make.”

Earle: Oh, I’m in the good books now, that’s for sure.

Kevin: Yeah. So tell us the story, what happened?

Earle: I’ll probably get in trouble for telling this story, but Amelia, who is my fiancée…

Kevin: Yes.

Earle: Well because I had no idea when this book was going to land at my hands, I’ve been applying the agile development process here, you know, I already had a few backup plans ready but in the end, it was at a park where she’d been nagging me, “I want to see the book, I want to see the book.” And I’d been putting it off, finally let her do it, and she picked up the book, looked at cover, looked at the back cover and then—I’m thinking, “true lady form”—straight to the dedication! So I didn’t have to— There was no prompting or anything. And I’ve never seen a face change from like a little smile to a confused shock more quickly. Then it was a couple of “really” questions, “Really? Really?” And then it was all happy. She was all smiles.

Kevin: Ah, that’s great.

Earle: I had a ring ready to go and everything. That’s some planning right there.

Kevin: Well, when it’s in print, you know it must be so. Congratulations, you guys. We’re already planning how we’re going to adjust it for the second print run.

Earle: Waeeey? That sounds…

Kevin: You have to put like, “She said yes!” Or something likes that.

Earle: Well that’s what she said to me. She said, “Actually, I won’t give you an answer. I’ll let you know in the dedication of my first book.”

Kevin: (laughing) Youch! Well it’s been great talking to you guys and I look forward to digging in. I’ve read the first couple of chapters but yeah, I am deeply engrossed in this book so looking forward to getting through the rest of it and yeah, I’m happy to hear that it’s not just a clever title. It actually does get to some advanced places at the end. That’s quite an achievement.

Earle: Well, I’d like to hear what you have to say about it when you get to the end.

Kevin: All right. Well thanks for joining me guys.

Earle: Thank you.

Craig: Our pleasure.

Kevin: And look forward to the second edition.

Both: (laughing)

Kevin: Bye-bye.

Both: Thanks Kevin.

Kevin: And thanks for listening to the SitePoint Podcast. If you have any thoughts or questions about today’s interview, please do get in touch.

You can find SitePoint on Twitter @sitepointdotcom, and you can find me on Twitter @sentience.

Visit sitepoint.com/podcast to leave a comment on this show and to subscribe to get every show automatically. We’ll be back next week with another news and commentary show with our usual panel of experts.

This episode of the SitePoint Podcast was produced by Karn Broad and I’m Kevin Yank. Bye for now!

You can find SitePoint on Twitter @sitepointdotcom.

Have any thoughts about this interview? Please visit us at sitepoint.com/podcast to leave a comment on this show and to subscribe to receive every show automatically. Email [email protected] if you have any questions for us; we’d love to read them out on the show and give you our advice.

This episode of the SitePoint Podcast was produced by Karn Broad. Thank you for listening and have a happy, healthy, and successful 2010.

Theme music by Mike Mella.

Thanks for listening! Feel free to let us know how we’re doing, or to continue the discussion, using the comments field below.

Related posts:

  1. SitePoint Podcast #33: Team Opera at WDS09 Kevin does the rounds at Web Directions South 2009, asking...
  2. SitePoint Podcast #15: This Way Up In this episode of the SitePoint Podcast: Google’s new image-based...

You might also like...

Comments

Contribute

Why not write for us? Or you could submit an event or a user group in your area. Alternatively just tell us what you think!

Our tools

We've got automatic conversion tools to convert C# to VB.NET, VB.NET to C#. Also you can compress javascript and compress css and generate sql connection strings.

“An idiot with a computer is a faster, better idiot” - Rich Julius