Not too long ago I acquired a copy of “Learning jQuery 1.3“, a recently released ‘PACKT’ publication written by Karl Swedberg and Jonathan Chaffer. The only books I’ve previously owned relating to web development were not framework/library specific so reading this one was a totally new experience.
The book is mostly aimed at beginners but does cover some more advanced topics so may be of interest to the more savvy web designer or developer. Actually, anyone wanting a solid jQuery reference would benefit from this book!
I’d guess that one of the troubles with writing a book just about a specific topic is that you’re limited to its confines. This book does not start by discussing the DOM API or JavaScript itself, but instead it begins by first explaining the intent of jQuery and then by detailing the jQuery wrapper function and how you can utilise the power of CSS within this magical dollar symbol. jQuery is wonderful but, in my opinion, without a solid foundation in JavaScript you can never be as good as you could be.
The authors did a wonderful job and I don’t think anyone could ask for a better book about jQuery but I cannot help but raise the question of whether or not jQuery is the practical place to start.
I have this image in my head of some hotshot interface designer longing for some hotshot Ajax’y coolness to suit his ego; he wanders into Waterstones and picks up a copy of this jQuery book he’d heard of, he takes it home, and willingly begins on the long journey of learning “jQuery”. If the world were what I wanted, then this guy would soon realise the error of his ways and how he should have learnt JavaScript before venturing into it’s squeeky clean abstractions; but, unfortunately, the world is not like that; the reality is more upsetting – not only will this designer never realise the error of his ways but he’ll live on, writing jQuery everyday, creating bouncy effects and “jQueryfied” web interfaces. Why is that a problem? – Because he will never be able to program in JavaScript he’ll lack the fundamental knowledge that would otherwise ensure him complete cross-browser and timeless sanity!
Did you see that!? While discussing the necessity of learning JavaScript before jQuery, I went off at a tangent; Something book authors are not afforded the luxury of doing… But that isn’t to say it was a worthless moment! That’s why books bug me a little, it’s all about size, specification and compensation! It’s never really about the information. 1
Back to the book…
The book goes into considerable depth and manages to cover most, if not all, aspects of jQuery. In addition to feature descriptions and examples, Karl and Jonathan discuss best practices and continually advise the reader on the best course of action in various situations. jQuery’s UI framework and other various plugins are also discussed near the end.
I only have a couple of concerns about the book and its content. I don’t feel that the surrounding technologies are given enough time in the book. A preliminary chapter on the basics of JavaScript (and the DOM) would’ve certainly benefited beginners. While the average reader might not see the relevance of such a chapter, they’ll probably have a better understanding of the syntactic discrepancies of jQuery because of it. Even though having knowledge of JavaScript is a noted prerequisite, I doubt many readers of the book would accept this necessity. Beginners are vulnerable to the classic mistake of learning a framework before learning the language on which it’s based.
The only issue with offering such a chapter would be that half the readers would probably find it either useless or not worth reading… yet another reason why books bug me, you’ve got to cater to such a large audience with such varying motives that you’re bound to disappoint at least a few of them!
I only have one other tiny problem with the book, and this is very specific issue and probably a little over-zealous of me to even mention it: In the first chapter the authors state that without jQuery’s bespoke ready event you’d have to rely on the onload event to run code when the DOM is loaded. Then they continue by saying how you’d have to bind a named function to the event by obtrusively placing it in the HTML (<body onload="...">). These assumptions highlight a notable problem with jQuery and its “marketing” techniques: The conception that unobtrusive JavaScript is only possible with jQuery is far too widespread, even the assumption that jQuery makes unobtrusive coding easy is, in my view, rubbish. There are far more respectable ways to market a product (i.e. jQuery) than slamming the competition (i.e. JavaScript without jQuery). 2
Conclusions
The content of the book, as it is, is definitely up to scratch. The only issues I have are more theoretical and are largely unrelated to this particular publication.
If you are considering buying a book of this type or are possibly on the edge of a decision then I absolutely suggest this one! Everything you’d want to know about the jQuery library is neatly squeezed inside the covers of “Learning jQuery 1.3“. Don’t be put off by my negativity; like I said, those are just a couple of my opinions concerning the general approach of books like these, not the content of this particular one.
Even if you’re not considering buying any book at all, I would definitely consider looking at this one. Although, if you’re a total beginner I might suggest a more gentle and progressive introduction to the world of JavaScript, possibly “JavaScript: The Definitive Guide“. If you can’t be bothered with “regular JS” and just want to get at the cool stuff then I urge you to reconsider your stance. JavaScript isn’t as bad as people make it out to be, and it’s only getting more popular; learn JavaScript, then learn jQuery (or a library/framework of your choice).
1 – By this, I mean “information” is rarely the prime concern when publishing a book. While creating an informative book may be the sole objective of the author it’s not going to be the publisher’s primary concern!
2 – Library’less JavaScript is not in competition with any particular library but the marketing techniques of these libraries has created this dillusion; that JavaScript is not good enough, and that somehow it’s all too hard…
Thanks for reading! Please share your thoughts with me on Twitter. Have a great day!
agreed
i have come across UI designers such as this. this is not a javascript only issue, but flash as well. we do heavy as3/4 data interpolation nonsense, but are put on the same level as animators.
that being said
there is and should be merit for the UI designers getting their hands dirty for such things as rapid prototyping… …but they will soon return to the javascript devs when the heavy lifting is needing to be done.
Hi James,
Thanks a lot for the review!
I definitely understand and appreciate your concern about learning a library/framework exclusively rather than combining it with solid fundamental JavaScript concepts. I wouldn’t suggest that someone buy our book in order to avoid learning JavaScript. In addition to the book you mention above, the following books, depending on the person’s background and experience, are also good options: Peter-Paul Koch’s PPK on JavaScript, Douglas Crockford’s JavaScript: The Good Parts, Jeremy Keith’s DOM Scripting, and Stoyan Stefanov’s Object Oriented JavaScript.
While I’m sure I’m in the minority here, I don’t think it’s necessary to learn plain JavaScript before learning jQuery. There’s nothing wrong with learning the two at the same time. Each can enhance understanding of the other. That said, I agree that it would have been nice to have included some preliminary discussion on JavaScript and DOM basics.
I’d like to clarify something that you mention in your post: “Then they continue by saying how you’d have to bind a named function to the event by obtrusively placing it in the HTML.” We don’t actually say that. Instead, we go on to discuss window.onload. We also note:
Thanks again for the review. I’m glad you like the book, despite your misgivings.
@eugene, I totally agree. It’s fine for prototyping but when a real working product is required then people that know the technologies inside and out should be the ones to create it.
@karl, thanks for your comment. I am sorry about my misguided accusation about the ‘onload’/’ready’ stuff.
I don’t quite understand your stance on the issue of which technology to learn first. I don’t think it’s okay to start with jQuery because you’ll make tonnes of mistakes that wouldn’t have been made if you knew a little bit about JavaScript. For example, a post at Nettuts was posted today demonstrating how to create a tooltip plugin; I don’t like to point fingers but the author obviously did not start by learning JavaScript. Look at the plugin’s code and you’ll see what I mean. Now, if that author had learnt JavaScript first and knew about the syntax and best practices then he/she would’ve been better prepared when starting to learn jQuery.
How many people that use jQuery everyday know that when they do
$(...)they’re actually calling a function that returns a custom jQuery object? How many of them know about scope, closures, lambda, logic operators, the concept of truthy/falsy??I still see many jQuery’fied designers doing
if(myVariable == true) {...}…I’m just saying that learning JavaScript before jQuery is better than the other way around. And no offense to jQuery itself, but it’s not the best platform on which to learn JavaScript – this is inherent of most libraries – they abstract away so much that the user will rarely be exposed to real JavaScript.
James, please note that I never recommended learning jQuery before JavaScript. I simply suggested that learning them at the same time is perfectly reasonable. And I don’t buy the argument that jQuery or any other JS library will cause you to make more mistakes than pure JavaScript will. Yes, that Nettuts article was unfortunate. But I think the problem lay in the author’s inexperience in general. Lack of plain JavaScript experience was clearly not his only problem. However, whether Nettuts should try to pass off an article by a novice as some sort of authoritative guide is a separate matter.
Sure, “if that author had learnt JavaScript first and knew about the syntax and best practices,” he would have done a better job. He also would have done a better job if he had first learned jQuery and its syntax and best practices before posting the “tutorial.” It isn’t fair to compare someone who is just beginning to learn jQuery with someone who has already learned JavaScript, its syntax, and its best practices. Compare people of equal ability and experience, who are at the same level in their professional development, and let’s see how much better the one is who learns JavaScript first rather than JavaScript and jQuery hand in hand. My hunch is that the difference won’t be as great as you claim.
Before the rise of JS libraries, thousands of web hacks were cranking out the most ridiculously crappy JavaScript you could ever imagine. Some were doing it with DreamWeaver and its MM_swapImage garbage, some were doing it with the help of “DHTML” code snippet sites, and some were doing it all by themselves. But they were all learning JavaScript the old-fashioned way. Even now, lots of people who have never used jQuery are doing
if(myVariable == true) {...}. But, hey, beginners make mistakes — lots of them. And that’s okay. As long as they learn from them, and don’t pose as experts.Thanks for the reply Karl.
I guess I agree with you on most of your points. What I meant to put across in my last comment was my belief that learning “pure” JavaScript before its abstractions is a better approach because when a problem occurs you can attribute it to the language itself instead of rummaging down to the lowest level in order to find the cause. I would extend this argument and say that, in an ideal world, JavaScript should be learnt BEFORE the DOM API. While learning two things at once (JS + DOM or JS + jQuery) is a sound method, it might not be ideal.
My argument is purely theoretical, it’s not realistic to expect people to follow this approach where you must start at the lowest level possible and work your way up through the abstractions – plus my argument is flawed, massively, in that it does not allow progress – if everyone constantly programmed in Assembly then we would be living in a different world – it’s because of various programming languages that software engineers can create programs at such speed! It’s because of jQuery and other JS libraries that web designers/developers can create rich and interactive web experiences at such speed…
I’ve gone a bit off track here. I didn’t mean to make a spectacle of that Nettuts tutorial either; it just looked like the perfect way to illustrate a point I wanted to make – being a beginner is fine, but only when you know you’re a beginner! That author was paid money to educate people…
I’ve made this mistake a tonne of times. I look back at articles/tutorials written by me in the past and I cringe at my ignorance, plus I feel a bit guilty for misguiding readers. (heck, I’ll probably look back on this comment right here in a similar manner)
The question of which to learn first, JavaScript or jQuery, is not about necessity, but, I think, it’s about which route will lead to a better understanding of both technologies. Of course “learning them at the same time is perfectly reasonable” but is it the right route to take? If you held all the cards, what decision would you make?
I can’t really argue a strong point here because I’ve only ever been on one side of the river. I picked up JavaScript before I even realized that libraries and frameworks existed so I have quite a limited perspective.
Maybe learning both at the same time would yield impressive results… I don’t know.