Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Image

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.
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.
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

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.

*

This discussion has been archived. No new comments can be posted.

jQuery in Action

Comments Filter:
  • Vs. Mootools? (Score:4, Interesting)

    by truthsearch ( 249536 ) on Wednesday November 26, 2008 @01:57PM (#25901389) Homepage Journal

    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?

  • by peter303 ( 12292 ) on Wednesday November 26, 2008 @02:05PM (#25901467)
    Client-side scripting java-syntax language seamlessly compiled into Java and supported by Sun. Supposed to solve the issue of those third party scripting languages out there.
  • Re:GWT FTW (Score:4, Interesting)

    by Rayban ( 13436 ) * on Wednesday November 26, 2008 @02:20PM (#25901577) Homepage

    As a GWT developer I'd agree with the above statement. We're using it for all sorts of Javascript-generation tasks and it works really well - it's just that you need to understand the abstraction.

    I consider it to be a strongly typed version of Javascript, rather than a full abstraction layer. It's just too leaky to cover up all the differences. You still need to understand IE's hasLayout and CSS shortcomings.

    That said, if any of you know GWT inside and out and are looking for a job, we at dotspots.com are hiring (you'll figure out how to find us). :)

  • Comment removed (Score:3, Interesting)

    by account_deleted ( 4530225 ) on Wednesday November 26, 2008 @02:58PM (#25901921)
    Comment removed based on user account deletion
  • Re:Vs. Mootools? (Score:5, Interesting)

    by Teilo ( 91279 ) on Wednesday November 26, 2008 @03:09PM (#25902017) Homepage

    I have not used Mootools. I was first exposed to jQuery when I was trying to integrate WYMEditor into my company's CMS. When we ran into an issue, where we needed to add a CSS class to some server-side-generated code that we could not touch, the answer from somebody on a forum was, "Just use jQuery," and I was shown a one-liner that did exactly what we needed. Not only that, it was instantly understandable. My initial reaction, having struggled with doing this manually in the past, was, "It can't be that easy." Of course, I have used it in countless ways since then. I personally find it quite self-documenting.

  • Re:A simple request (Score:2, Interesting)

    by jbezorg ( 1263978 ) on Wednesday November 26, 2008 @03:10PM (#25902031)

    I have the Web Developer add-on for Firefox and with a Ctrl+Shift+S, all CSS is broken/disabled. Does this mean I should not use CSS?

    I've gone through various stages in web design. At one time I was in the "JS is evil crowd!". Now, I use JS to enhance the user's experience but the pages must not depend on JS.

    I would recommend looking into DOJO [dojotoolkit.org]. Though jQuery is also working on Section 508 compliance. From what I recall, the guy who worked on Dojo's 508 compliance is now working on jQuery's though I cannot cite the source off the top of my head (A catch 22. I do remember it was on the person-in-question's blog).

    Dojo Accessibility Compliance
    People familiar with accessibility and accessibility guidelines such as the W3C's Web Content Accessibility Guidelines, and the US Section 508 requirements, are often interested in a compliance statement for Dojo. While Dojo does not make an explicit claim of compliance to W3C WCAG 2.0 Level A or to US Section 508, every attempt has been made to meet those guidelines and to make the 1.0 and future versions of the core widget set, dijit, accessible to keyboard, low vision and assistive technology users. Keyboard support has been added to all of the dijit widgets and is supported in Firefox 2 & 3 on Mac and Windows as well as IE 6 & 7 on Windows (Safari and Opera do not yet support full keyboard navigation of scripted content). All of the dijit widgets support font resizing and work in Windows High Contrast mode to support low vision users. Dijit utilizes the under development W3C Accessible Rich Internet Applications (ARIA) specification so that all dijit widgets are accessible using the latest versions of the JAWS or Window-Eyes screen readers with Firefox 3. Additional WCAG 2.0 and US Section 508 compliance details are provided below.

  • Re:Vs. Mootools? (Score:3, Interesting)

    by anomalous cohort ( 704239 ) on Wednesday November 26, 2008 @03:34PM (#25902271) Homepage Journal
    Well, this might steer you away from jQuery but it looks like Microsoft will be using jQuery [blogspot.com] under the covers for its future ASP.NET AJAX technology offerings.
  • Re:Vs. Mootools? (Score:4, Interesting)

    by hobo sapiens ( 893427 ) <[ ] ['' in gap]> on Wednesday November 26, 2008 @03:45PM (#25902389) Journal

    "I personally like jQuery (and jQueryUI) because it's more terse and elegant."

    I have used prototype pretty extensively for years now. I recently made the switch to jQuery and have been doing quite a bit with it. jQuery UI is awesome. I have never been a fan of combining prototype with scriptaculous because that *really* bloats your pages. And you really cannot minify prototype, at least as far as I know. jQuery UI is extremely intuitive to use and is lightweight thanks to the awesome build-your-own-download site they have.

    That said, I prefer prototype for straight ahead AJAX stuff, mainly for one reason: jQuery requires you to use the jQuery object. The prototype $() just returns a nice fully qualified object reference with which you can do all sorts of stuff. jQuery lets you do the same things, but requires you to learn all kinds of jQuery stuff. jQuery thus moves you one more layer away from using straight ahead javascript, which in turn makes your skills more about jQuery than the underlying language. That is A Bad Thing.

  • by WebManWalking ( 1225366 ) on Wednesday November 26, 2008 @03:56PM (#25902485)
    My first attempt to teach myself jQuery with a real-world example was a screaming success. I had to fix a huge page in 3 major sections that confused and frustrated users. (Couldn't be helped. Management decision.) In less than an hour, I vastly simplified the page using only one line of jQuery code for each section. I repeat, only one line of code for each section.

    With that experience, I became not just a convert, but a jQuery software evangelist at the Federal Government agency where I work.

    The next intractable problem that jQuery solved here was the old mouseover/mouseout problems with DHTML menus (that sometimes stayed open in some browsers). jQuery's ability to simulate one-event-only mouseenter/mouseleave in all modern browsers solved that problem in only one line of code too. I haven't seen our shared DHTML help menu stay open ever since.

    The ability to bind multiple event handlers to the exact same event is really going to help us refactor and stratify our data validation JS. Everything's getting better and faster and simpler, all at the same time.

    My biggest complaint has been the lack of books explaining the IDEA of how jQuery works. I've had to survive largely by reading the jQuery source code. I bought this book (the one reviewed above), plus Learning jQuery and jQuery Reference Guide, and not one of them has adequately explained how the animation queue works. I believe that I now understand the animation queue better than the authors of those 3 books do. Or better than their ability to explain, at least.

    What I'm saying is, this book and the other 2 constitute a good first wave of jQuery books, but they don't do justice to this marvelously well thought-out JavaScript Object.
  • Re:A simple request (Score:3, Interesting)

    by chaim79 ( 898507 ) on Wednesday November 26, 2008 @04:00PM (#25902549) Homepage

    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."

    Thankfully I've only run into this a couple times, and have never returned

    Don't try and block off your page because your advertisers want to use javascript to enable a billion popups.

    The keyword advertising and the click-anywhere-on-the-page-to-open-a-popup advertising are the worst

    Don't use scripting to sanitize your POST submissions; You should handle that on the backend, it's more secure anyway.

    After reading the other comments and your clarifications I have to agree on your point (of forcing JS POST sanitation and refusing to post otherwise). I've even run into a couple cases where there is no 'submit' button, just a button that runs some JS that will do the form submit...

    Don't use it to load content; That's what CSS and XML are for and it renders faster anyway.

    I'd agree for cases where the entire page content is JS loaded, the HTML you get is an empty DIV and a few headers and CSS files. Those sites take forever to really load and degrade to something even worse on bad connections. However using JS to dynamically load subsets of content VS loading the full list (several mb) or doing multiple page loads to navigate the content is Very handy (for reference, part/model tree, full data set was over 5mb, organized in a tree structure, page loaded root of tree, each selection loaded that branch of information from the tree, really worked out great)

    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.

    Getting source or pics from 'protected' websites is no harder then Firefox -> Web Developer -> Disable Javascript (after page is loaded) :) So much for that protection that irritates 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.

    A good way to see the effects of this is to use something like LORI for Firefox, shows number of items downloaded from the server, the total size of the information loaded, and the total time required for you to get it all. One of our dev sites started getting all fancy with really cool JS libraries and tons of CSS and other functionality, which got dropped once we checked and found out that it was loading nearly 300k for all the content (and minimal images, less then 15k).

    While I agree on all points, the big one I hate is Flash, unless it's for some rich media functionality (YouTube) I hate flash, and will usually run around the web with it disabled. As much as JS can be missused and abused Flash can be exploited to ruin your web experience.

  • Re:Vs. Mootools? (Score:2, Interesting)

    by Anonymous Coward on Wednesday November 26, 2008 @04:42PM (#25902999)

    the prototype.js $() function is super handy, but it is a poor citizen in many respects. Prototype alters the global JavaScript namespace by altering the default nature of objects provided by the browser (e.g. strings, arrays, etc)

    This can cause headaches for legacy JS scripts or integration with other libraries.

    JQuery (and Dojo for that matter) do not pollute the global namespace - and therefore integrate better with other JS solutions.

  • Re:Vs. Mootools? (Score:4, Interesting)

    by aj50 ( 789101 ) on Wednesday November 26, 2008 @05:23PM (#25903413)

    I guess they argue that because JS is a client-side program, you have to send the JS parts of your web application to the user and are therefore distributing it just by letting anyone use it.

    I'm not sure how the GPL works with respect to licensing parts of a webapp. Can you just distribute the JS parts under the GPL and keep the server-side closed source?

    Seeing as you have to send the client the source code to allow them to run the javascript and it's effectively impossible to prevent them from re-using it somewhere else it's not such a big deal to allow your javascript code to be open sourced.

  • Re:Vs. Mootools? (Score:2, Interesting)

    by xmuskrat ( 613243 ) on Wednesday November 26, 2008 @10:11PM (#25905591) Homepage
    That's pretty sad since that they extended upon Yahoo's JavaScript library, YUI. That's how they got the Ext name.
  • Re:Vs. Mootools? (Score:3, Interesting)

    by TheSpoom ( 715771 ) * <{ten.00mrebu} {ta} {todhsals}> on Thursday November 27, 2008 @10:20AM (#25908401) Homepage Journal

    The problem is that they've previously argued that if you use the GPL version, the requirement extends to open sourcing the entire backend code to your webapp because it all becomes a derivative work of Ext.

    I do note that they seem to have since changed their page so their opinion is less evident, but there was a huge row about it previously, both on Slashdot and on their forums.

All seems condemned in the long run to approximate a state akin to Gaussian noise. -- James Martin

Working...