Slashdot Mirror
Learning jQuery
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.
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.
somebody is gonna ask.
jquery This seems like a good place to start.
It's hard to believe that's how Micronians are made. Why don't we see it right now by having you both kiss one another?
At the moment this is the only introduction to jQuery, but in a couple of months Manning will release jQuery in Action . It is a pity that the writer of this review didn't wait until both were available to tell which is the better.
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!
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.
This site doesn't seem to be updated in a few versions, but it's still very applicable:
http://www.visualjquery.com/
-- lol pwned
"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...
the new widget that we all see on /. where by 'dragging' comments are controlled ..can that be implemented with jQuery?
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,
Dan
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 relational query language.
Table-ized A.I.
Don't encourage the use of any frameworks. People should just learn the DOM and code their own javascript. This kind of crap encourages people to not really learn the language. They see oo pretty Javascript Jquery, but can't methodically code a program if I ask them to. Keep your own functions and objects like in any language for reference, but never use a framework.
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 cool features) about JavaScript. By now I find JavaScript actually a nice language to code in, all because of jQuery! (Seriously, I tried the same with YUI and Dojo and just got a headaches) Best JavaScript framework I have ever used, even if I disagree with JohnResig about what important features all the time ;)
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
Notice anything? There's a pretty sweet app that knows which parts of MooTools are dependent on the other parts of MooTools.
But note there's also no apparent way to download all the code -- something someone unfamiliar with the library might want to do in order to (a) read the code as part of the process of familiarizing themselves and (b) have everything present while you're still developing the familiarity required to *know* exactly what you do and don't need.
How is it that these people are smart enough to build something as cool as the sweet dependency app but not smart enough to let someone just download everything?
Well, it turns out there is a way, which they have noted over in the FAQ for the forum:
http://forum.mootools.net/viewtopic.php?id=1964#post-9398
Think about this for a moment. This is a *Frequently Asked Question* -- how to download the whole thing, which means it's obviously something people want to do. There's an answer in the FAQ that would have as easy to add, in code, to the download page, as it would have been to post to the FAQ -- possibly easier. So why is there still no "download all" link on the page?
Because the MooTools team is more interested in having their philosophy of modularity impressed on you than giving you convenient access to the code.
Not a good sign. I investigated further anyway, but found pretty much what I expected after that: in many places (enough to be annoying) the library values certain somewhat arbitrary conceptions of correctness over ease of invocation for the developer.
Prototype is peppered with all kinds of "we can't stand programming in anything other than Ruby"isms that are almost as annoying, but when it comes down to it, it's simply easier to use. And jQuery stands up *very* well in that regard.
I don't begrudge the MooTools developers their choices -- they're the ones doing it, they should write the library that pleases them. And I imagine there are users with the same mindset as the developers who will love it. But MooTools doesn't live up to the broad claims like those the parent poster made here (faster, smaller, "simply" better).
Tweet, tweet.
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.
(To be fair, most of the other libraries have something similar as well.)
Tweet, tweet.
Why isn't anyone mentioning the ext JavaScript library? jQuery is so last year!
-- For Shizzle
Censorship is obscene. Patriotism is bigotry. Faith is a vice. Slashdot 2.0 sucks.
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 three footnotes in the appendix mentioning 'highly advanced' topics like writing C modules.
I want to see MORE of what the reviewer is apparently complaining about. I want to see a Python book that doesn't assume I've never heard of programming before. Who does this? Do people give random programming language books as gifts? My family members are smart enough not to grab a random book off the shelf, but I suppose I can't assume this for everyone.
If you're teaching me something, teach me that something. If I need to know a technology beforehand, then hey, here's a thought - refer me to another book and tell me to buy that one first. If there isn't one then write two and make twice the money, but don't make me pay $79.99 for a book that spends 2/3 of its time telling me the origins of functional programming.
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. jQuery will probably fade away in 5-10 years, because something new will come up.
But I add an exception for manuals that come with a particular product. Those are books about a particular product.
This is my personal opinion.
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?
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.
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 appeals to me most is that jQuery handles most of the cross browser headaches that JavaScript brings as baggage. So I bought Learning jQuery and have been quite satisfied. jQuery is enough different from plain vanilla JavaScript that I was having a bit of trouble wrapping my head around it. A couple of hours spent working quickly through the first few chapters cleared that up.
This is a worthwhile addition to my library. The writing is clear and concepts are presented in a logical order, and the examples are actually useful. Anyone with a solid grounding in HTML and CSS who has even a basic understanding of the DOM will quickly be able to write useful scripts that tap into this lean and efficient framework. I've worked my way through most of the book and have a pretty solid intermediate grasp of jQuery and have been able to easily add it to my last couple of projects as progressive enhancement that leaves pages still usable with JavaScript turned off.
As you would expect from a book with the title, Learning jQuery, it doesn't take you into true expert territory and that's a plus. It's just the right length to provide a solid grounding without being a doorstop that never gets opened. I've bought too many "Bibles" or "Definitive Guides" in the past and never got around to working through them. Start simple and take learning 0ne-step-at-a-time works for me. Having somebody do the hard work of learning the framework, distilling the concepts down and serving them in a concise and logical order makes my learning curve so much shorter that I consider the price to be money well spent.