Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Learning jQuery 85

hal10001 writes "One complaint of just about any book that attempts to teach a new language or technology is a presumed level of expertise by the authors. I found it refreshing that in Learning jQuery the book begins... well, at the beginning, and increases in difficulty along with the concepts. It gives designers and entry-level interface developers the opportunity to come up to speed at an acceptable pace."Read below for the rest of Brian's thoughts on the book.
Learning jQuery
author Jonathan Chaffer, Karl Swedberg
pages 352
publisher Packt Publishing
rating 8/10
reviewer Brian Reindel
ISBN 978-1-847192-50-9
summary Better Interaction Design and Web Development with Simple JavaScript Techniques
While I consider the screenshots to be lacking in quality, overall, this book will definitely leave you satisfied. The essentials required to be successful at developing with jQuery are all touched upon, and the depth of explanation for each piece of code is precise and clear. You will not find yourself flipping through chapters of fluff, added only to beef up the number of pages. Each tutorial and example is carefully planned and executed.

Describing concepts in relation to any JavaScript library can be difficult. Since libraries are in fact JavaScript, it can be easy to confuse beginners. The authors are careful not to allow this to happen. This is especially apparent in Chapter 3, when highlighting the event model, event capturing and event bubbling. A clear distinction is made between browser implementations and the unique facets of jQuery. Official documentation is often wanting in these areas, and the book fills in the gaps nicely.

Throughout Learning jQuery, additional notation is included to subtly remind developers of any potential gotchas, which is a nice feature. For instance, while referencing the clone() method, it was noted that only elements of the DOM are copied, and not the events previously associated with those elements. These tips are always appreciated, since in a development environment they can prevent hours of head-scratching, and help eliminate frustration.

I was also impressed that the authors cover both JSON and XML as data-interchange formats in Chapter 6, AJAX-How to Make Your Site Buzzword-Compliant. This illustrates conformity not to a single standard, but to real-world development scenarios, where you might encounter both formats. My only complaint here is that not enough time was spent specifically on jQuery's $.ajax() method for AJAX implementations, since in my experience this tends to be more popular than the $.get() method.

The only change I would make to the format of the book would be to divide it into two parts. It is obvious that the authors intended to begin with jQuery key concepts, and then move into cookbook mode. This does happen after Chapter 6, but it would have been helpful to make that distinction more evident. If you do buy the book, be aware that in order to digest these great tutorials, that you should dedicate more time for the latter half of the book.

Finally, I would like to add that although this book does not cover jQuery v.1.2, or the UI plugin, it is still worth the purchase. If you use the latest version of jQuery, and still want to implement the same XPath selectors covered in the book, you just need to download a plugin. You will not find a better resource online for getting into the guts of the jQuery JavaScript library than you will offline reading the book Learning jQuery.

You can purchase Learning jQuery 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.

Learning jQuery

Comments Filter:
  • what is jquery? (Score:5, Informative)

    by stoolpigeon ( 454276 ) * <bittercode@gmail> on Wednesday October 24, 2007 @03:38PM (#21104035) Homepage Journal
    somebody is gonna ask.
      jquery [jquery.com] This seems like a good place to start.
    • by vondo ( 303621 )
      Knowing the answer to that is a "presumed level of expertise by the author" I guess.
    • Re: (Score:1, Insightful)

      by Anonymous Coward
      Otherwise known as Yet Another Language that no one really needs/wants/or understands, but will command big bucks on the job boards.

      Of course that will be for people with 5+ years experience in it.
      • Re: (Score:1, Informative)

        by Bogtha ( 906264 )

        No, it's not Yet Another Language. It's a JavaScript library, and it's quite easy to have 5+ years experience with JavaScript.

      • Otherwise known as Yet Another Language that no one really needs/wants/or understands...

        Are you saying that no one needs/wants/understands JavaScript or jQuery? If you want to use JavaScript for your web applications jQuery is an awesome way to do it. It's simple to understand and really helps you approach JavaScript in a whole new, non-invasive, way. The fact that it uses CSS selectors is great because it really encourages you to use a good design that separates structure, presentation, and behavior. This

    • by z0ph4r ( 1179099 )
      I've used dojo, jQuery, mochi, mootools, prototype, and rico javascript libraries and I wouldn't bother with jQuery. My personal favorite is mootools [mootools.net], a better javascript framework. Mootools is simply faster [mootools.net], smaller [mootools.net], and more modular [mootools.net] (read: well written) than the competition.
      • Re:what is jquery? (Score:5, Insightful)

        by Goyuix ( 698012 ) on Wednesday October 24, 2007 @05:22PM (#21105433) Homepage
        Perhaps I am just feeding the troll, or perhaps I am just sharing my perspective... but having used many of the same libraries you have we somehow diverged at some point. And that is probably a good thing as I doubt we are really working with the same audience. I really have little to do with design and interaction, I really tend to focus much more on architecture/transport/etc.... the actual "business" logic.

        My evolution went from using prototype to investigating scriptaculous, mootools and YUI - none of which lasted very long as quite frankly they *seemed* more like toys to animate elements on the page rather than providing a clean and transparent way of sending/retrieving data and altering the data on the page. They were quite good at what they did (or their demos showed) but never really seemed to address what I was trying to accomplish. YUI was also VERY cool, but also very bloated feeling and cumbersome to actually use. Put simply, I am much more interested in things like JSON, REST and POX than the various libraries to help transition between those "transports" and display on the page.

        A while back, maybe a year or possibly a bit more, I was introduced to jQuery by another developer and based on his recommendation decided to check it out. I wasn't quite ready to switch over from prototype (which seemed to more closely resemble the custom JS I would write) and adopt a new kind of similar yet strange syntax from a library I didn't quite have an appreciation of. After adopting it for one project to force myself to learn and use it, I have since whole heartedly switched over from prototype and now love and endorse jQuery as the default AJAX library (I hate to call it that, since it really does so much more). Quite honestly I think each of the "major" libraries out there has many benefits, and I am sure you can cite a great variety of reasons why product x is better than product y so check out what is there and see which one is really going to help you the most. If I was doing complex UI manipulation stuff, I would probably look at scriptaculous or mootools again, although the preview for jQuery UI looks promising as well.

        *Disclaimer/Note: this is just my personal experience with them and should not reflect anything on the actual product. I fully recommend checking out the various options to see what works best for you.
        • Check out the Ext library [extjs.com] if you ARE looking for user interface PLUS data constructs. It has a JQuery adapter that let's them work in tandem and I've had lots of luck integrating the two in mixed code, cross-browser clean.

          I'm not too impressed with JQuery UI Interface library OTOH. seems bloated and buggy last time I tried it out.

      • Re: (Score:3, Informative)

        by Bogtha ( 906264 )

        Mootools is simply faster, smaller, and more modular (read: well written) than the competition.

        Faster, smaller and more modular? Firstly, if you are worrying about the speed at which your JavaScript executes, you are almost certainly either prematurely optimising or using way too much JavaScript. Only a minority of developers need to worry about that, even assuming older clients. Having said that, the release notes for jQuery 1.1.3 [jquery.com] have some interesting notes regarding the benchmark you refer to:

      • simply faster, smaller, and more modular (read: well written) than the competition.

        Leaving aside that jQuery has some substantial claims to being fast (fastest in IE6) and small (26k packed, vs MooTools 40+k packed)...

        If the prevailing philosophy amongst the mootools team is in fact "more modular" == "well written" then that explains a good deal. Take a look at the download page:

        http://mootools.net/download [mootools.net]

        Notice anything? There's a pretty sweet app that knows which parts of MooTools are dependent on the ot
        • Re: (Score:3, Funny)

          by Bogtha ( 906264 )

          Take a look at the download page:


          Notice anything?

          Nope. The reason why I don't notice anything is because the contrast between the text and the background is so low that the text is invisible unless I crank up the gamma on my monitor, and even when I do so, the text is unreadable because it's absolutely tiny. They've actually hard-coded a 9px font size in there. Ridiculous.

          What's more, they specify the OS X font Lucida Grande, which has a large x-height, followed

      • Disclaimer: the following is based on very limited experience with MooTools.

        Mootools refuses to namespace their library and redefines the 'Element'. This can (and will) lead to conflicts with other JavaScript libraries. jQuery is fully namespaced and provides a "noConflict" mode so that you can be sure it will play well with others. I would consider that "more modular".

    • jQuery is yet another JavaScript/AJAX abstraction library - just one of a hundred such things. It's littered with random obscure bugs between browsers, just like all others. The one thing that sets it apart from the rest is its ugly and arcane syntax and poor performance compared to others.

      Sound good?
  • by Anonymous Coward
    At the moment this is the only introduction to jQuery, but in a couple of months Manning will release jQuery in Action [amazon.com] . It is a pity that the writer of this review didn't wait until both were available to tell which is the better.
    • The book is actually available for purchase and pre-release download. Its at this point about 90% complete. I am loving jQuery and am new to it. Saw this (http://www.manning.com/bibeault/) on the jQuery blog (http://jquery.com/blog/) last night and went ahead and purchased it. I've made it throught he first couple (pre-publication, mind you) chapters and am impressed. The book is scheduled for release in December but it worth getting into now. It seems the pre-release PDF you get has markup for the printers
  • Bravo (Score:4, Insightful)

    by cromar ( 1103585 ) on Wednesday October 24, 2007 @03:44PM (#21104115)
    While I don't plan to use jQuery, I must commend you on a very well written review. It provides your opinion of the book, without bogging the reader down in chapter-by-chapter recounts of the material.
  • Oh, man, I'm really getting annoyed at that "...well, blah" phrase people use. Next time someone, well, says it, I'm going to, well, sticking a fork in my, well, eye!
  • by Anonymous Coward
    Why did they name a Javascript library with the same prefix used by numerous amounts of Java libraries?

    It would be like creating UltraLib.NET... exclusively for the Java platform.
    • Re: (Score:1, Informative)

      by linuxbz ( 875073 )
      And why, exactly, should Java own every library that begins with the letter "j" ? Is Java the only programming language that starts with "J" ? Well, no, there's ... well ... JavaScript. Now, you could easily argue that JavaScript is a poor name since it has little or nothing to do with Java, but if you say everything that starts with "x" must relate to X-windowing, everything starting with "g" must relate to Gnome, k* must be KDE, w* must be Windows, etc., it seems that we'll run out of meaningful librar
      • Re: (Score:1, Interesting)

        by Anonymous Coward
        I see. So you must be an anticategorism anarchist I take it?
      • Re: (Score:1, Insightful)

        by Anonymous Coward
        They shoudl have prefixed it with "js", because its pretty well understood that js means javascript. I wouldn't create a library for Visual Basic and call it vQuery, that would be stupid. I don't think its out of line to think that most people would assume jQuery is for Java. I did.
  • oldie but a goodie (Score:5, Informative)

    by tehwebguy ( 860335 ) on Wednesday October 24, 2007 @04:11PM (#21104469) Homepage
    This site doesn't seem to be updated in a few versions, but it's still very applicable:
    http://www.visualjquery.com/ [visualjquery.com]
  • by stephend ( 1735 ) on Wednesday October 24, 2007 @04:17PM (#21104559) Homepage
    "One complaint of just about any book that attempts to teach a new language or technology is a presumed level of expertise by the authors."

    Actually I have the exact opposite experience: whenever I try to buy a book for a new language (or whatever) they always assume that I'm starting right from the beginning, to the point of explaining what an "if" statement and a "for" loop are for. I'm sorry, but if I'm learning C++ or Perl it's pretty unlikely that it's going to be my first computer language.

    I know it's difficult to get the level right but not every book has to be 1000 pages long with full colour screen-shots...
    • by geekoid ( 135745 )
      ", but if I'm learning C++ or Perl it's pretty unlikely that it's going to be my first computer language.

      Generally aspeaking, that's not true at all.

      My wish is that id the use the worded "Advanced" on the cover, then they would for go all the basic 'if' and 'for' statements.
    • Re: (Score:2, Funny)

      by jeffstar ( 134407 )
      Perl was my first language! no wonder nobody will hire me now.
    • by walkie ( 794662 )
      I agree 100%. If you're going to explain conditional execution to me, please be kind enough to name your book "An introduction to programming in..." or something similar. Otherwise, just show me what a conditional statement looks like, point out anything that may be unique about it compared to other languages, and move on to more interesting features. Shouldn't take more than a small paragraph, and hopefully less.
    • by Eivind ( 15695 )
      Yeah. All with you there.

      It was my chief complaint with this jQuery-book (we have it at work).

      The actual nuts-and-bolts of jquery are explained clearly and nicely.

      Not many people are reading a book on an advanced, abstracted javascript-library, yet unaware that, for example, HTML has tags, tags are wrapped in less-than and greater-than signs, many tags have an opening and a corresponding end-tag, HTML is often transported over http and any number of other basic concepts that the book saw fit to explain.

  • AJAX Frameworks (Score:5, Informative)

    by dannydawg5 ( 910769 ) on Wednesday October 24, 2007 @04:25PM (#21104693)
    As a web developer, I get asked quite a bit about AJAX frameworks/code libraries. I have nothing but praise for jQuery. Here's my take on some of the major players:

    1. YUI has been object-oriented to the point of uselessness. Everything requires YAHOO.blah.blah.blah(YAHOO.EventUtil.blah.blah.blah), and then they want you to have another line with YAHOO.AddListener.blah.blah(yourFunction) to add it to the execution list. I like objects. Wait, let me clarify, I like MY objects! I stopped doing what they asked and starting writing wrapper functions to their functions.

    2. GWT requires a zillion steps. I spent half a day installing a Java IDE and compiler and running example projects to see how to use it. Perhaps this is useful for massive projects like Gmail, but for the rest of us who are just looking to add a few effects, instead of writing Java to generate JavaScript, you are better off just writing the JavaScript directly.

    3. The Scriptaculous documentation seemed nonexistent. I was trying to find meaty documentation, and every page was essentially "LOOK WHAT I CAN DO!1!11"

    In short:

    1. YUI has a zillion files and still leaves you writing tedious DOM and your HTML ugly. They DO have some good stuff, which I will get to later.

    2. GWT is like installing MS Word when you all needed was a good text editor.

    3. Scriptaculous will leave you hanging.

    (Side Note: I was just learning DOM when I tried out Scriptaculous. The bad taste may be the learning curve all beginner's must go through).

    My recommendation:

    -Go with jQuery + YUI's "reset-fonts-grids.css" file.

    That YUI css file will reset all the browser defaults to an even layout saving you tons cross-browser tweaking. (Some things I disagree with though, like no bullets or numbers on your UL and OL tags. Still worth it though.) YUI Grids also has some nice templates to help you with div-based layouts. They have a few added extras too beyond just JavaScript code libraries.

    jQuery is simply the most elegant and concise JavaScript library I've found. The idea behind it, "find this, and then do that", is great. The code looks simple, and your HTML code is left clean! People have developed modules for it too, so I may can replace my YUI added extras and just worry about 1 code library.

    Hope that helps someone,

    • Re: (Score:1, Informative)

      by j_d ( 26865 )
      scriptaculous' documentation is a goddamn joke, which is particularly embarrassing since its parent lib, Prototype, has a pretty well-organized and straightforward site.
    • by vurg ( 639307 )
      How does JQuery compare with Prototype [prototypejs.org]? I'm trying to decide on which one to use.
      • The Scriptaculous code libraries were built upon Prototype. If you download Scriptaculous, you will be required to get Prototype.


      • Re: (Score:3, Informative)

        by hal10001 ( 1152377 )
        Hi vurg, You will find that Prototype is a bit more verbose than jQuery, and that DOM manipulation is more complicated. However, if you're just using it for effects, then I suggest you take a good look at both, since Scriptaculous (built on top of Prototype) is very well received, while jQuery's UI plug-in is fairly new.
    • That YUI css file will reset all the browser defaults to an even layout saving you tons cross-browser tweaking. (Some things I disagree with though, like no bullets or numbers on your UL and OL tags. Still worth it though.)

      Font sizing? I appreciate that I haven't looked into the YUI css. However, one of my favourite pieces of CSS is:
      font:62.5%/140% Verdana, Arial, Helvetica, sans-serif;

      This is kind of a 'magic calculation' - setting the font size to 10px on every relatively modern browser. From then on in, percentages can be used to increase sizing uniformly.

      My other two standard defaults are:

      1. Setting everything (*) to margin:0 and padding:0 and lists to have no list-style-type. I personally prefer this -

    • I think special mention should be given to Ext JS library
      It provides clean fully implemented widgets and it also supports integration with jquery and other libraries.
      I have not found I library that competes with Ext JS and continues being Open Source Just Check it out extjs.com
    • Huh aren't you missing obvious elephant in the room?

      What about Dojo? The most popular Javascript framework, supported by IBM.

      Basically if you do any kind of serious development you have one of therree choices:

      GWT- which requires that you program in Java and onform to their configuration management model
      YUI - If you are mad and willing to use bloated, slow and badly performing library
      Dojo - none of the above.
  • Maybe I'm just a diehard relational weenie (AKA "Tablizer"), but I feel that DOM should be tossed and replaced with a relational equivalent1[1]. Non-trivial DOM has many the drawbacks and speghetti messiness of "navigational databases" of the 60's that prompted Dr. Codd to formulate relational.

    At least lets give the idea a good hard thinkover.

    [1] Perhaps using a "dynamic" version of relational that has optional types and optional column size limits, and maybe something more powerful/flexible than SQL as a
    • by dugless ( 453465 )
      "His pattern indicates two-dimensional thinking." -Spock
      • by Tablizer ( 95088 )
        "His pattern indicates two-dimensional thinking." -Spock

        I am not quite sure what the implication is here. "Table" is only a conceptual presentation view. You can store 3D coordinates, or 11D coordinates if you want. How you display them in actual space depends on the display device and transformation views you use.
        • I am not quite sure what the implication is here. "Table" is only a conceptual presentation view. You can store 3D coordinates, or 11D coordinates if you want. How you display them in actual space depends on the display device and transformation views you use.

          You're still looking at it from a two-dimensional point of view. Not the data you store, but your data-storage mechanism. There are two axes in a table:

          1. The set of available columns in a table
          2. The set of available rows in a table

          What if you

          • by Tablizer ( 95088 )
            2D is chosen largely because most people can relate to it well. If we make 1D the "atomic" dimension, then we have a wimpy structure. If we go with 3D, when we have something that is hard to use on paper and 2D screens. And trees don't handle new orthogonal factors well. Maybe in the future when we have 3D hollographic displays or direct brain pluggins, this may all change. Until then, 2D seems the best way to go. Perhaps it is in part a personal preference, also.
    • by Maskull ( 636191 )
      The official DOM API was never intended to be the interface to the DOM, merely a kind of portable backend. It was assumed that more appropriate, language-specific bindings would be built on top of this.
      • by Bogtha ( 906264 )

        Do you have a reference for this? As I understand it, the specification was written in a generic way precisely so different languages could implement the exact same interface. If you are referring to this text from the DOM 1 specification [w3.org]:

        Vendors can support the DOM as an interface to their proprietary data structures and APIs, and content authors can write to the standard DOM interfaces rather than product-specific APIs, thus increasing interoperability on the Web.

        ...and this:

        The DOM specifies

        • by Tablizer ( 95088 )
          The distinction between interface, structure, and implementation can get pretty fuzzy at times. Every interface imposes a kind of "flavor" or style in philosophy for how to structure things and how to do things. Another way of saying this is that there are multiple different potential interfaces to perform the same given thing (satisfy result specifications).
          • by Bogtha ( 906264 )

            With all due respect, that's just a bunch of hand-waving that is so vague it's impossible to extract anything relevant to my comment. Of course there are multiple potential interfaces to perform the same thing. That's always true, obvious to everybody, and isn't relevant to the fact that the DOM defines just one canonical interface.

    • by nuzak ( 959558 )
      Yes, you are a diehard relational weenie. Codd would not approve of his theories being promoted as a Magical Golden Hammer to represent all data.

      Documents are hierarchical by their nature. DOM has lousy syntax, but that doesn't make it the wrong data structure.
      • by Tablizer ( 95088 )
        Documents are hierarchical by their nature.

        I disagree. They can be made hierarchical, but I see nothing that says they must be. Besides, relational is perfectly capable of representing hierarchical structures if need be. It ideally "sees" hierarchies as ONE OF MANY possible views of given information, which is how it should be. There is no One Right View that is ideal for everything. Something "has-a" parent, not necessarily "is-a" parent.
      • Documents are hierarchical by their nature.

        I believe the World Wide Web and a href beg to differ. Links simply exist to join document fragments together non-hierarchically.

    • Re: (Score:2, Interesting)

      by Anonymous Coward
      I am trying to think of a worse idea than this, but failing.

      It makes more no sense to shoehorn relational concepts into something -- a Document -- that is inherently non-relational than it does to shoehorn hierarchical concepts into something inherently relational.

      I am more than willing to be proven wrong, however; if you think it is a good idea, you could pretty easily build a jQuery plugin to provide SQL-like access to elements in a document. It would be a good test bed for your ideas that would require
      • by Tablizer ( 95088 )
        It makes more no sense to shoehorn relational concepts into something -- a Document -- that is inherently non-relational than it does to shoehorn hierarchical concepts into something inherently relational.

        Please clarify what you mean by "non-relational". How are you measuring "relational-ness"?
    • I feel that DOM should be tossed and replaced with a relational equivalent

      You mean some sort of method of accessing it via flexible symbolic queries describing attributes and relationships between nodes? One that retrieved arrays of matching results?

      If only someone had invented such a thing [jquery.com]. ;)

      (To be fair, most of the other libraries have something similar as well.)
    • by Maxmin ( 921568 )
      JQuery and related functions (document.getElementByTagName() etc.) are built around the need for a relational view of the hierarchical DOM document. They let you choose "rows" of DOM objects, based on criteria such as className, tagName, and DOM ID.

      Realize first that the DOM is essentially a tree structure, with pockets of collections or arrays of same/similar objects. You can indeed treat it like a relational database, but keep in mind that just about all objects are children, and many are parents.

  • I have used other javascript libraries like Dojo and YUI in the past, but I fell in love with jQuery after a day of playing with it. It's lean and it's mean. I was by no means very good in JavaScript when I started with it (though I did have a lot of experience in other programming languages), but jQuery was really easy to grasp. Then after a few weeks, after reading lots of code for jQuery plugins and the like, I found I knew a hell of a lot of rediculous details and (seemingly) 'quirks' (that are really c
  • Why isn't anyone mentioning the ext [extjs.com] JavaScript library? jQuery is so last year!

    -- For Shizzle [wi-fizzle.com]
  • One complaint of just about any book that attempts to teach a new language or technology is a presumed level of expertise by the authors.

    I'm going to dispute this assertion. I'm sick and tired of browsing through programming books at Chapters, picking up a copy of 'Advanced Python: Things that Guido van Rossam Doesn't Know' and having it start with four chapters on 'What is a programming language?' and 'What is a variable?', treating the user like a simpleton for the majority of the book, before spending t

  • Books about a particular technology(product) in my opinion are not worth the paper. When I buy a book I think of it as an obligation to have it for a long time. I could not throw away a book, its just not an option to me. As for technologies, I believe that magazines are the place that these things have to be published. Magazines are the ones that contain CURRENT knowledge, regardless if it will be outdated tomorrow. Books are for timeless knowledge, or at least for knowledge that would span tens of years.
    • And imagine in 10 years time you find yourself having to convert a mess of an app from some by-then dead language to whatever the fad language of the day will be. You might just be grateful to be able to get a copy of a book on the subject many years after all the magazines relating to it have been consigned to recylcle bins. Not to mention the historical value of such books to scholars in the future.
  • I know, you don't have to read or pay for a book. There's all the information online. But a well written reference can save a lot of time. Following links and ending up finding content that is poorly written and confusing or that requires reading a previous entry that in turn references yet another entry is not something that I want to waste otherwise billable hours doing.

    Like a lot of other people, I've looked at a number of JavaScript libraries and decided that jQuery was the best fit for my needs. What a

The party adjourned to a hot tub, yes. Fully clothed, I might add. -- IBM employee, testifying in California State Supreme Court