jQuery in Action 154
Michael J. Ross writes "As perhaps the only substantial computer language embedded inside of the major Web browsers, JavaScript has brought an unprecedented level of power to client-side programming for the Internet. Yet as a result of cross-browser incompatibilities and other problems, it has probably also resulted in an unprecedented number of headaches for Web developers. JavaScript libraries attempt to mitigate much of these difficulties. One of the most popular such libraries, jQuery, is explored in a book by Bear Bibeault and Yehuda Katz, titled jQuery in Action." Keep reading for the rest of Michael's review.
Released by Manning Publications on 7 February 2008, under the ISBNs 1933988355 and 978-1933988351, jQuery in Action attempts to cover a large amount of information within its 376 pages. The material is grouped into nine chapters: an introduction to jQuery; wrapped element sets; modifying element properties, attributes, styling, and content; browser event models, including jQuery's; animations and effects; jQuery utility functions; plug-ins; AJAX; and four powerful plug-ins. The book concludes with an appendix, which may be the best place to start reading in the book, because it reviews many of the key aspects of JavaScript upon which more advanced jQuery heavily relies. The authors assume that the reader has a solid understanding of JavaScript, and is familiar with the basics of AJAX
| jQuery in Action | |
| author | Bear Bibeault and Yehuda Katz |
| pages | 376 |
| publisher | Manning Publications |
| rating | 9/10 |
| reviewer | Michael J. Ross |
| ISBN | 978-1933988351 |
| summary | A well-crafted guide to jQuery. |
As an introduction to jQuery, the first chapter briefly presents the rationale behind jQuery and its contribution to "Unobtrusive JavaScript," which is essentially the long overdue separation of JavaScript and CSS code from HTML markup — that is to say, separating behavior from structure in Web pages. With this new approach to JavaScript, the resultant code may in some cases be a bit longer, but it is far more readable, maintainable, and robust. Anyone who has tried to decipher cryptic JavaScript interwoven with HTML, will appreciate this leap forward. However, after these first two sections, prior to starting with the details of jQuery and its syntax, the authors should have explained to the reader where to find jQuery and how to reference it within a page. This critical information is provided only in the chapter summary, almost as an afterthought. A reader skipping the chapter summary could easily miss it.
The second and third chapters lay the groundwork for what will follow. The former chapter explains how to specify and manipulate sets of elements on the Web page, known as "wrapped element sets." This is done using all of the selection methods supported by CSS 3, as well as some additional selection capabilities built into jQuery. The latter chapter explains how to manage the properties and attributes of page elements, and how to get and set attribute values and other attribute manipulation techniques. The authors show how jQuery gives programmers tremendous control over the HTML and CSS of their Web pages, which can be changed by creating and modifying elements, and wrapping them in new elements, as well as adding and removing class names within the HTML, thereby using the existing CSS code. On the other side of the same coin, styling can also be updated by getting and setting the styles themselves, thereby using the existing HTML code. The last section of the third chapter focuses on form elements, which have special properties within both HTML and jQuery.
Event handling is a key aspect of any GUI, and is the subject of Chapter 4, in which the authors describe the DOM event models — focusing on Levels 0 and 2 — and how the jQuery event model helps to neutralize the problems introduced by Internet Explorer (naturally) failing to follow industry standards in its implementation of the DOM Level 2 Event Model. The chapter concludes with an extended examination of some sample code — in this case an order page from the online menu of an imaginary Asian fusion restaurant.
The book shifts gears in its fifth chapter, which explains how to use animation and other effects to jazz up the Web page — such as fading images in and out, as well as smoothly resizing and moving elements on the page. For instance, the first application of these capabilities is in the form of a collapsible list, which is ideal for making lengthy vertical navigation menus far less space consuming. Chapter 6 arms the reader with an understanding of jQuery's many utility functions, which can be used to trim unneeded spaces from strings, iterate through collections and properties, filter and translate arrays, extend objects, load scripts dynamically, and determine the site visitor's user agent and box model. These functions add the capabilities to one's jQuery code; yet one can even extend jQuery itself, by using plug-ins created by other developers or by oneself. In Chapter 7, the authors explain how anyone can write custom utility functions, which they illustrate with a date formatting function. They also explain how-to create custom wrapper methods.
Although it has its detractors, Asynchronous JavaScript and XML (AJAX) has enabled a plethora of new ways to make Web pages respond faster to user events, without requiring the overhead of wholesale page reloads. AJAX is the topic of Chapter 8, and the authors begin with a review of how to make asynchronous requests using the JavaScript XHR object, thus enabling the page to communicate with the server. This can be used for loading content into page elements, making GET and POST requests, and more. Similar to the previous two chapters, this one ends with a detailed examination of sample code. The final chapter in the book begins with a brief overview of jQuery plug-ins, and then examines in detail four highly popular plug-ins for handling HTML forms, controlling the dimensions of elements, declaring element behavior prior to creating the elements themselves, and gaining even greater control over the user interface, such as dragging and dropping elements on the page.
Anyone interested in learning more about the book can consult the publisher's page, which offers a book description, excerpts from reviews, and links to pages containing the supplemental sections of the book, such as the table of contents. It also has the book's errata, of which there are listed (as of this writing) five in the second printing, and three from the previous printing. Two sample chapters (2 and 5) are offered, as well as all of the sample source code. The PDF version of the book can be purchased online, at a discount to the printed version; the two can also be purchased as a bundle. Lastly, there is an authors' forum, where readers are invited to post questions, almost all of which have been kindly answered why the authors.
jQuery in Action illustrates how the primary aim of programming frameworks is to encapsulate much of the details of the language being used, so the developer can focus on the higher-level purpose of the code they are creating, and not the minutia of syntax and, in the case of JavaScript, differences among browsers. The authors successfully demonstrate the major concepts, primarily through the use of what they refer to as "lab pages" — essentially detailed code samples, with explanations, beginning with the second chapter. These exemplify the spirit of Manning's "in Action" series of technical books, which recognizes that in computer programming — as with probably most every other field — the best way to learn is by doing, and in this case, seeing sample code in action. This also makes it easier for the reader to modify the given code and experiment with it, to confirm what they have learned, and perhaps discover something new. Most of the sample code for this book runs fine in a Web browser opening the HTML files, without having to be run on a local Web server.
This book should prove a favorite among jQuery developers. The authors zero in on the core components of the library, and explain everything clearly — providing thorough coverage, without excessive verbiage. They are forthright about the weaknesses of jQuery, just as much as its strengths. The book does not contain a large number of screenshots or other figures, but it does use those in conjunction with code snippets, tables, and command syntax summaries to help break up the text visually. The authors improve the readability of the material with a genuine sense of humor, yet without resorting to the silliness currently found in many books written by programmers.
There are few blemishes, and of those, none are major. Phrasing in a few instances could be confusing to the average reader, such as referring to functions as elements just a few paragraphs after mentioning CSS elements (in the "NOTE" on page 9). The chapter summaries add no value, and should be jettisoned. Also, they should not be used as a place to introduce information not even mentioned in the corresponding chapters, e.g., the jQuery download information noted above. Almost every chapter summary touched upon something that had not proceeded it; such material should be folded into the particular chapter proper. The chapter titles should be in title case, and not sentence case. On the other hand, some phrases are incorrectly put in title case, such as "Rich Internet Applications" — a phrase overused. There were only a few errata not already reported on the publisher's Web page, such as "it incursion" (page 15). As with many computer books nowadays, there is an excessive use of exclamation marks. In terms of the sample code, it is complete and quite handy for trying out the ideas discussed in the book, and learning by modifying it. However, the JavaScript portions of the code can be difficult to read, because most of the code is compressed, with almost no use of whitespace to enhance readability.
With its capable technical coverage, extensive use of sample code, and approachable style, jQuery in Action is a valuable resource for any Web developer seeking to maximize the power of JavaScript, and a must-have for anyone interested in learning jQuery.
Michael J. Ross is a Web developer, writer, and freelance editor.
You can purchase jQuery in Action from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
A simple request (Score:4, Insightful)
Dear web developers,
PLEASE FOR THE LOVE OF GOD, don't use javascript unless there's a need. Keep the content separate from the interface. I see way to many people using javascript to mangle this golden rule.
Don't use it to hide the contents so you can throw up a "but you have cookies disabled and we can't track you."
Don't try and block off your page because your advertisers want to use javascript to enable a billion popups.
Don't use scripting to sanitize your POST submissions; You should handle that on the backend, it's more secure anyway.
Don't use it to load content; That's what CSS and XML are for and it renders faster anyway.
Don't try and use javascript to obfusciate or disable standard web features (like view source). It's not going to stop anyone who wants to make a copy and it'll piss off everyone else.
Don't make your entire site dependent on having javascript enabled. If you're worth your salt as a developer you can find a way to make that page render without enabling javascript. Sure, it may not have all the chrome and pretty-shiny on it, but remember that there's a lot of devices and a lot of browsers that use the web, as well as people who are color blind, blind altogether, or who use low-end systems, or cell phones, or PDAs, etc.
Re:Vs. Mootools? (Score:3, Insightful)
but the only significant benefit I see is better documentation.
A big plus in my book.
Re:Vs. Mootools? (Score:5, Insightful)
I personally like jQuery (and jQueryUI) because it's more terse and elegant. It is not as self-documenting, but it does css selection much better than prototype (IMHO). Most importantly, it was very easy to tack onto our web-based internal applications by referencing a simple .js script (or two) and adding a few function calls to manipulate existing html/css. Finally, I found the libraries of widgets just much more compelling in jQuery (with the exception of grids).
Re:A simple request (Score:4, Insightful)
Script should be used to check POST submissions, before they are rechecked sever side. Saves so many round trips.
Of course, if we had Forms 2.0 and the ability to add a regex to form inputs, this tedious task could be done by the browser saving a whole bunch of script.
Re:A simple request (Score:4, Insightful)
Girlintraining also seems to be developerintraining...
Some of your points make sense, I think most would agree about the futility in trying to lock down right clicks and such.
But there's a lot here that's simply wrong.
Not sanitizing content on the client side? You're right, it should be done on the server side. That's non negotiable. But it should also be done on the client side. It gives users immediate feedback and it prevents a wasted round-trip to the server. There are wrong ways to do this (alert() for example) but it's a must-have.
And your comments about hiding content, loading content, cookies and JS-dependance miss the point entirely: The goal here is graceful degradation.
Why am I going to cripple usability on a site by not supporting JS just because some luddites have it disabled? There's no reason you can't build a UI that relies on JS but degrades gracefully when it's not available, even if that means certain features being disabled.
Not to mention, some of your comments make me wonder if you've ever actually done any of this. How, exactly, is CSS and XML going to provide loading and reloading content on-demand the way JS can?
Furthermore, using JS does not, at all, mean mingling content and interface. Just because it's all composed in the browser as a single page doesn't mean it's developed that way.
Development is about nuance. Your "JS is bad" theory displays no nuance whatsoever.
Re:A simple request (Score:2, Insightful)
Yes, but it shouldn't be necessary to have scripting enabled to submit the data in the first place, which was my point. If the jscript is formatting the data in a particular way that the backend script processes, such that a regular POST submission will fail (and I've seen this) -- it's bad form.
Re:A simple request (Score:0, Insightful)
Re:A simple request (Score:3, Insightful)
"Keep the content separate from the interface."
Great! I like pork chops! What does that have to do with the subject at hand?
Javascript is neither content nor interface. Javascript, HTML, and CSS are more like a MVC-type setup.
Javascript is great, and while I do agree with some of your rules, they really have more to do with *what* you use javascript for, not whether you should use it. Honestly, I worry about people who are *still* scared of javascript and AJAX. These are usually people who do not understand said technologies.
Re:Vs. Mootools? (Score:2, Insightful)
No mention of jQuery versus other similar JS libraries? My company is considering switching from mootools to jQuery for new projects, but the only significant benefit I see is better documentation. So how does it stack up against the competition?
I've used jQuery, Mootools and Prototype/Scriptaculous extensively and I have to say jQuery is my favourite. I can't really compare to extjs since I haven't used it.
You're right, the documentation is much much better than the others that I've used. That alone IMO is a reason to use it.
Two more reasons:
There are reasons not to use it too. It is higher level, so if you're old school and want to do things the old school way, then you'll probably have to fight a bit with jQuery to do it. When I first tried jQuery I hated it because it wouldn't let me do things the way I always had. However after you get used to it, I think it is an investment well made.
Re:A simple request (Score:3, Insightful)
Of course, if we had Forms 2.0 and the ability to add a regex to form inputs, this
tedious task could be done by the browser saving a whole bunch of script.
yeah, that's a great idea. what's stopping me from feeding malformed data to your silly app using CURL or a plain socket on 80? people that try to break your app won't be following any "2.0" rules. and many "developers" already fall for this by relying only on JS validation.
I like JS when it's actually useful (hint: Google shit), but I don't like it people have forms with no submit button, and just a normal button with an onclick event. hitting enter anywhere in the form won't submit just as no JS support won't submit. great job there!
Re:A simple request (Score:4, Insightful)
Checking the form submission in script is like the sign outside a stadium that says, "don't bring knives into the stadium."
Checking the form submission on the server side is the burly guy with the metal detector at the entrance.
The latter can do the job all by himself. The former, by itself, can't be trusted - but the idea of it is to (hopefully) cut down on the other's workload a bit.
Re:A simple request (Score:2, Insightful)
IMO, a better idea is to design your code to enhance [wikipedia.org] progressively [alistapart.com] instead [accessites.org]. A subtle difference, but it's nevertheless worth mentioning. In essence it's designing the basics first and adding style and functionality on top of that, rather than designing the whole thing exactly how it's imagined to be then making sure it works for everybody else and creating fail-safes or degraded versions for the cases in which it doesn't.
powerful but obtuse (Score:3, Insightful)
web programming itself is completely misunderstood. HTML is a "display" mechanism, and people believe it to be "programmable".
then along comes javascript, one of the most fundamentally powerful yet utterly obtuse programming languages, and it gets "thrown in" amongst the "display" mechanism.
we've known for years that mixing HTML into a programming language and vice-versa is a bad idea: you only have to look at how people get themselves into an awful mess with PHP to appreciate that. in that respect, javascript is no different.
my take on this is that it's far better to do web client programming in a higher-level-language such as python or java. fortunately, javascript is an extremely good fit with python, and java has a limited subset of the dynamic capabilities of javascript, so is also a good (one-way) fit.
by programming in python, java or ruby and having it translated into javascript automatically, the fear that people have of getting into an awful AJAX mess goes away.
http://pyjs.org/ [pyjs.org]
http://code.google.com/gwt [google.com]