Posted
by
samzenpuson Wednesday April 28, 2010 @01:50PM
from the read-all-about-it dept.

Michael J. Ross writes "Like all major programming languages, JavaScript can be extended in functionality through the use of libraries, such as jQuery, which is currently seeing tremendous popularity and enhancement in the Web development community. Designers and developers who want to learn how to use jQuery for creating rich user interfaces through client-side JavaScript are advised to begin their journey to jQuery proficiency by reading one of the many books dedicated to this powerful JavaScript resource — such as jQuery Cookbook: Solutions & Examples for jQuery Developers." Read below for the rest of Michael's review.

jQuery Cookbook

author

Various authors

pages

480 pages

publisher

O'Reilly Media

rating

9/10

reviewer

Michael J. Ross

ISBN

978-0596159771

summary

An extensive collection of solutions to jQuery problems.

This book was published by O'Reilly Media on 19 November 2009, under the ISBN 978-0596159771, and is authored by no fewer than 19 contributors — all quite knowledgeable of JavaScript and jQuery — and edited by one of those contributors, Cody Lindley. On the publisher's page for the book, visitors can read the book's description, table of contents, and errata, of which there are 22 as of this writing, although none have been confirmed by the authors or publisher. Visitors can also download all of the sample code used in the book, in addition to the eight code demos for Chapter 13. Lastly, prospective buyers can purchase the print version of the book, the electronic one (in PDF, ePub, and Mobi format), or the two combined at a considerable discount — or read the book as part of Safari Books Online.

jQuery Cookbook's 480 pages are organized into 18 chapters, covering a wide range of topics: the basics, element selection, utilities, dimensions, effects, events, forms, plug-ins, user interfaces, theming, Ajax, data formats, and testing. Lindley starts off the first chapter, titled "jQuery Basics," by presenting the advantages, philosophy, and organization of jQuery. Readers will likely chuckle at his suggestion that they memorize the jQuery API outline, which comprises two pages. The many code snippets are quite helpful, but they are needlessly long, partly because most of them contain far more HTML elements than are needed to illustrate the point, and also because each snippet contains the DOCTYPE and head tags, among others — often taking up more lines on the page than does the code pertinent to the topic at hand. This pointless and space-wasting redundancy is seen also in a few of the chapters that follow. As well, some of the passages in the first chapter's narrative are oddly phrased, frequently requiring a rereading of the material, while others could be made more concise. Additionally, some of the sample code contains bugs, which fortunately are detailed on the errata page mentioned earlier. The second chapter, "Selecting Elements with jQuery," presents numerous techniques for specifying elements within the DOM. The only obvious blemish in the material is in section 2.4, where the author refers to animated elements, but with absolutely no explanation as to what that means; countless new readers may assume he is referring to animated GIFs. Nonetheless, these two chapters form a helpful foundation for the rest of the manuscript.

The third chapter, "Beyond the Basics," gets off to a questionable start with the assertion that "jQuery can [] extend jQuery to infinite possibilities," which sounds like a line wisely rejected for the movie Toy Story. Yet the discussion continues on a solid footing, as it covers more advanced techniques for working with selected elements. Some of the discussion overlaps material presented in the previous two chapters, but it is always worthwhile to hear critical concepts explained from a different perspective. However, section 3.8, which briefly introduces jQuery plug-ins, is out of place; that material should be folded into Chapter 12, which focuses on that topic. The fourth chapter may be brief, but it explains several jQuery utility methods. Most of the code snippets use a format of "(function($) (jQuery);" — whose usage and advantages are not explained in this chapter, nor any earlier ones. This points up one of the key downsides of having almost every chapter of a programming book written by separate authors: readers can be confused or misled by disparities in coding practices, especially when the reasoning behind them is not given. The title of the fifth chapter, "Faster, Simpler, More Fun," is a bit misleading, because the authors don't explain how to make one's jQuery programming simpler or more fun, but they do provide a great deal of information on troubleshooting, performance optimization, and jQuery coding practices, including those pertaining to progressive enhancement, accessibility, and unobtrusiveness. Section 5.19 lacks a figure showing the menu being discussed, but that's the only obvious flaw.

The remaining chapters are dedicated to more specific aspects of jQuery programming, including the important topics of page layout as well as element positioning and sizing, discussed in Chapter 6. The subsequent chapter delves into effects, which is one of the more exciting topics in the jQuery realm. Even though a portion of the readers may be put off by the trickiness of the code, the material does demonstrate some of the powerful capabilities of jQuery effects — which in conjunction with HTML5 may easily encroach on areas of client-side programming formerly dominated by Adobe Flash. Throughout Chapter 7, most if not all places where the author refers to the "mouse," he apparently means the "mouse pointer." Events play a critical role in JavaScript software, and even more so for code that is mostly jQuery — thus the value of chapters 8 and 9, which examine basic and advanced event handling. The next pair of chapters discuss a variety of techniques for enhancing HTML forms, from scratch and through the use of jQuery plug-ins. The sample source code is better commented than what is seen elsewhere in the book, and the explanations are quite good. The subsequent chapter focuses on jQuery plug-ins, beyond their usage within HTML forms, and briefly explains how to create your own plug-ins and how to perform unit testing on them.

Because JavaScript is primarily a client-side technology, it should come as no surprise that jQuery can prove an outstanding tool in crafting user interfaces for Web sites and Web-based applications. Chapters 13 through 15 explore such topics as drop-down menus, sliding panels, rotating images, modal windows, tooltips, the jQuery UI, and how to style jQuery UI widgets, a.k.a., theming. No Web interface is an island, and over the years there have emerged a number of data formats and protocols for utilizing those formats for transmitting information between browsers and servers — such as Ajax, XML, JSON, and JSONP — covered in Chapter 16. Finally, the last two chapters of the book are geared more to testing and deployment, and less so to interface design and development. The topics covered include techniques for persisting data in the browser, managing large amounts of code and data for major software projects, automating the unit testing of jQuery code, testing callbacks and user actions, grouping and selecting tests, and more.

Overall, jQuery Cookbook starts off with some basics, and only then moves on to higher-level concepts and related use cases. However, the book is ostensibly aimed at beginners and intermediate JavaScript programmers, but the former group may find the ideas difficult to grasp fully, despite the introductory chapters — because some of the techniques are fairly advanced, they involve terminology unfamiliar to anyone new to jQuery, and some of that terminology is not explained. On the other hand, the recipes are generally well written and clear, supplemented with properly tested and working code. Consequently, anyone who takes the time to work through the examples patiently, should be well rewarded.

Because of its coverage of a wide range of topics, jQuery Cookbook can be used not only as a learning aid, but in some respects also as a reference — and in this regard the book's index will be quite useful. In light of the considerable length of the manuscript, reading it from stem to stern would involve an investment of time — especially if one were to work through all of the examples and try them out in one's own development environment — quite easily, in fact, since all of it can be downloaded from the publisher's site. Most of it, however, is organized as plain text files, and not HTML files; and no reason is provided for this annoying choice.

In terms of the layout and appearance of the text and figures, one flaw is that in countless lines throughout the book, the words are jammed together, making it difficult to read the text rapidly. In fact, some of these lines almost look like single words. This is also seen in the subheads, an excellent example of which can be found on page 149: "Solution2:ChangingthehrefAttributeoftheStylesheetThat'sResponsible." Unfortunately, the same is true for much of the source code, but in a different sense: Operators and variables are jammed together, clearly illustrating the need for whitespace in making code more readable. Some of the code is excessively long (noted earlier), and the authors are inconsistent as to whether their JavaScript is placed at the end of the body element or in the header element. Nonetheless, the sample code is generally of good quality.

There is another aspect related to not only this book but all other computer programming books for which individual chapters are written by different authors: jQuery Cookbook does not seem to be a single book, but instead a collection of books that were bundled together because of a common thread, namely, jQuery. This leads to some of the problems mentioned earlier, such as discrepancies in coding techniques and formatting — from which the beginning reader is supposedly learning best practices. On the other hand, the multi-author approach makes it possible for each major subject area to be handled by one or more writers who are expert in that particular area — which in turn results in a better product overall, even if one or two of the chapters are noticeably weaker than the others.

The book contains a number of copyediting flaws not listed on the aforementioned errata page: "elevated" should instead read "alleviated" (page 12); "or [its] alias" (13); "could change" should read "could be changed" (26); "jQuery('a')removeAttr('title')" is missing a "." (30); "'blue')" is missing a terminating ";" (50); "season in" should read "season" (56); "was contained" should read "is contained" (144); "position: absolute" in the narrative should not be broken between two lines (156); "great[er] than" (157); "equal[-]sized panels" (160); "only running" should read "only runs" (165); "still support[s]" (168), "#source5txt" should read "#source4txt" (217); and at this point I stopped recording errata. Also, in countless places in most of the chapters, semicolons are used where dashes are called for, and vice versa. O'Reilly's copyeditors should have detected and fixed those errors prior to publication.

Yet most of these blemishes are of little significance. What really counts is the overall value provided to the reader: Usable for both learning and reference, jQuery Cookbook delivers a tasty buffet of programming essentials, best practices, illustrative examples, optimization tips, and other information of value to JavaScript developers who wish to spice up their Web creations with jQuery.

The biggest problem is the entire dom aspect, of doing things, the dom needs subtree isolation,there have been various approaches like xul which tackled that problem, but not a single one became standard.Add to that that the dom is used nowadays as UI definitionc construct and your are in a hell of a mess.

That is right. The two major problems with javascript is the dom specification, inconsistent implementation, and it is a prototype based language... The THREE major problems with javascript is the dom specification, inconsistent implementation, it is a prototype based language and a total lack of good development tools...

Amongst the major problems with javascript are the dom specification, inconsistant implementation, it is a prototype based language, a total lack of good development tools, semi-colon insertion,... etc.

Proper JS support has been the feature which all mainstream IDEs have been chasing recently, competing on achievements. It's not just Java IDEs, either - VS has just added a bunch of goodies [asp.net], too.

I can think of three off the top of my head that I know work fine, and I'm pretty sure I could add Eclipse and Anjuta to the list.

Incosistent implementation is an issue, but jQuery fixes a lot of that. I only had to add two or three functions to my 'compatibility.js' file I use with everything to get IE in line (the rest of the stuff is things I think JS is missing in the default).

Granted, I'd still rather be programming in Python, C or even Java with a good UI library, but

Another problem is download size, at least for those few of us still on occasional dialup or slow 3G. The minified version of JQuery is 72K. Still that's better than the NYT home page, which makes 30 requests for JS files, though only 60K total.

I agree, although one thing that annoys me slightly is the lack of "spell checking" tools for JavaScript (and other ECMA-262 variations). In other words, dynamically typed objects make you occasionally spell property names wrong, and the runtime will not complain until you run the program, where a property are taken as simply some other one. Stuff like that.

JavaScript Lint implementations help a lot, but they specifically state so and do no checking of such object properties. Which is understandable for a d

The biggest problem with writing a pure-JavaScript spellchecking tool would be providing the dictionary for it to work with, and pulling in that dictionary would add significantly to the page load time.

Of course, there are uses of JavaScript that don't require the code and data to be pulled from a network connection--in those cases, it should fairly easy to hack together one of your own by implementing a phonetic algorithm [wikipedia.org] and/or using an edit distance calculation [wikipedia.org] to identify plausible alternatives.

No offense, but it insults me somewhat that you are offering me use javascript lint, after I have written about using it a post ago. Of course, one cannot expect Slashdot readers to read the entire conversation, I guess:-)

Sorry for the offense. I already mentioned that I misinterpreted your original comment. What I probably didn't mention was that the original post was in the middle of a 14-hour work day, and the one you just replied to came after six hours of sleep.

mikerz did not say it sucked, in fact did not comment on the language at all. You could have said the same thing for C around 1997 - cross-compilation on gcc and msc was difficult because of compatibility issues. The quality of the language didn't matter, the quality of the implementations did.

Technically, mikerz was off-topic, but it's hard to praise the language when you can't write much useful in it without a compatibility library like jQuery or your own homebrew hacks. Writing a valid C program you c

You could have said the same thing for C around 1997 - cross-compilation on gcc and msc was difficult because of compatibility issues.

No, actually you couldn't.

What you describe is a differing implementation of the language itself. ie, a C program that would compile on gcc would not compile on msc because of issues with the way the compiler compiled the language.

But no such incompatibilities exist with javascript. Take a valid javascript program that corresponds to the latest ECMA standard and throw it at

Actually, if you wanted to carry on the analogy, it would be "cBrowser" for the office suite, and "cWriter" for the web browser (because you are browsing documents, and the web browser has optimized form handling)

I've heard the same group that developed JQuery is working on a database querying framework called JDisplay.

Always thought it was a weird name, but having used it, it's clear the name jQuery refers to the power that comes from being able to "query" the DOM with CSS3 Selectors (originally Resig wanted to name it JSelect [stackoverflow.com])

Play with it for a while... going back to getElementById() and getElementByName seem archaic (Sizzle js does exist now, and jQuery 3+ uses that).

On the publisher's page for the book, visitors can read the book's description, table of contents, and errata, of which there are 22 as of this writing, although none have been confirmed by the authors or publisher

So there are 22 what? Chapters? Chapters and errata? Description, chapters and errata?

And why exactly can't the authors or publisher confirm anything? You'd figure that at least one of the 19 contributors could confirm at least their own contributions:)

I'm with you on that one, but the publisher's website has 22 errata that the publisher has not confirmed. That's the sort of thing you should catch yourself before an editor sees it. If you don't have an editor, you need to try harder. Or we're not the intended audience, could be that.

If you're fairly comfortable in JavaScript you should be able to look at the online documentation at jQuery and figure it out in a day or two. The framework is very simple to understand and it'll save you the $20+ dollars you'll spend on the book.

I must say....I got really excited. I hoped that someone had finally coded a GOOD cookbook/recipe/mealplanner application, and that it was SO GOOD slashdot picked it up. Open source, minimal bull to get it running, and can export to any format.

This is only the second time I've seen a review of an O'Reilly book exceed the length of the book under review
(The first was the review of false in a Nutshell).
Actually, I just wanted to post "TL;DR" but didn't want to hassle with the lameness filter...

Now, granted there's people out there who think nothing of having 1MB web pages and it's not really a problem for people with high-speed connections, however some people have limited monthly bandwidth, others are still on dial-up, more and more are using wireless networks with their cellphones and those networks aren't as fast as a cable modem, not to mention the limited bandwidth per tower.

Some JavaScript libraries are "recompiled" to make them smaller by reducing variable names to a, a1, fz etc. and stripping out all non-executable elements such as comments and white-space. The result, if you lose the original, makes early BASIC look readable in comparison.

56kbps = 56000 bits per second = 7000 bytes per second. You're adding 10 seconds to the download time of people on 56kbps modems.

Actually, jQuery is about 24k after it's been minified and gzipped (and any modern browser will gzip text over the wire), so that's slightly over 3 seconds for a 56k modem, and that's only once for your entire site. That's practically nothing if your site is more than one or two static pages, especially if you have anything crazy like JPG images in your page.

Really? You're questioning some Kb used on a very useful library that is a basic cross-browser requirement for good scripting. In this day and age where broadband is available to anyone...

I'm currently developing a webapp which is quite heavy in scripting, css and images (for the user interface). To get to the login page you need to download more than 500Kb, which might be a lot for any random static page but not for a large complex webapp. It is worth adding the proper caching headers so all subsequent p

You mean that you it's a problem to 72k to a page to write javascript code that will turn your static web page into a dynamic one, making your site much more usable ? How big is an image already ?

Don't forget as well that by placing this piece of code outside the page, it be be cached for a long time, not to be re-downloaded for a while. It's more or less a one time cost if your browser and web application are properly configured.

(or course you can develop in JS without jquery, but it takes more time, more

72k I don't have to download because I have NoScript, and your site better degrade gracefully or I usually find an alternative. If your site does not have minimum functionality without scripting, I don't consider it functional at all.

So, ah, welcome to the modern world of browser caches. It's absolutely worth 70k, *once*, because you shouldn't need to load it more times than that. It gives you easy cross-browser compatibility and a huge amount of features. Amazon manages to use it, as does Twitter, Dell, Best Buy, ESPN, and a few others. If those companies are okay with the one-time-lag, I can suspect it's okay for the vast majority of users you're going to hit.

I didn't know what to make of this book review. The book review points out a lot of ways in which this book is a mess (poorly copy-edited, unclear motion from one author to another, terminology used without definition, etc.). Then at the end, it says:

Usable for both learning and reference, jQuery Cookbook delivers a tasty buffet of programming essentials, best practices, illustrative examples, optimization tips, and other information of value to JavaScript developers who wish to spice up their Web creatio