Staring keenly at a stack of magazines, I hazard a gaze towards the computer section and lay my eyes upon the newest cover of my sworn enemy, the .NET magazine. Its luring front-page convinces me that it deserves my consideration.

I buy it without looking inside. I want to reserve the surprise for later.

Now sitting in the lounge at London Gatwick Airport, I whip out the magazine and rush to a JavaScript article. I can’t wait. It’s about jQuery and I just know that they’ve gotten their act together since previous encounters. I’m sure this article will contain the best in jQuery techniques and JavaScript best practices.

Well, .NET, now I’m sitting here with the unfortunate duty to inform you of my unsurprising disappointment.

The truth is I expected nothing more from you.

Please turn to page 80 of issue 205 and pay special consideration to the following reservations of mine:

The author doesn’t mention the possibility nor the applicability of creating a jQuery plugin instead of the single globally defined function ‘drawerToggler’. What’s wrong with this? Well, the function happens to contain functionality that could be abstracted to deal with arbitrary sets of nodes and is therefore suited to jQuery’s plugin mechanism. I would understand if at least a mention surfaced, but nothing.

This is certainly not the worst of it though.

The function itself:

function drawerToggler() {
    $('#theme-drawer').slideToggle("normal", function(){
        if ($('#theme-drawer').is(":visible")) {
            $('#wrapper').css("margin-bottom", "150px");
        } else {
            $('#wrapper').css("margin-bottom", "20px");
        }
    });
}

Where it’s being called:

$(document).ready(function(){
    $('.drawer-toggler').click(function(){
        drawerToggler();
    });
});

This function is called within the click event handler for any element with a className containing drawer-toggler. Since it’s getting called on every click, and the elements selected within the drawerToggler do not change between calls, it would be logical to select and “cache” the DOM object references beforehand, and then the function could use these DOM references instead of continually (and redundantly) re-querying the DOM on every single call!

The function itself contains some redundant code too. The ‘theme-wrapper’ to which the slideToggle method is applied, is then re-queried within the callback. Apparently unbeknown to the author, this very element can be accessed via the ‘this’ keyword within the callback function — there is absolutely no need to re-query the DOM for #theme-wrapper!

This isn’t just a case of my preferences versus the author. There are established best practices in the jQuery community and as one of the industry’s top publications you should be providing not only good advice but near enough the best advice according to current industry practices and standards.

Now, I could stop, but the reign of nonsensical JavaScript programming continues.

On page 82, along with the insistence of using $(this).attr('rel') instead of the terser and faster DOM equivalent, this.rel, the author insists, again, on re-querying the DOM for unchanged elements within the click event handler for all anchor elements within #themes-wrapper!

There’s a few more specific issues I’d like to raise but I feel I’ve already made my point in regards to the obvious inadequacy of the article itself.

The article specifically says that it’s geared towards developers with an intermediate-level understanding of HTML, CSS and JavaScript. If you want to further the knowledge and understanding of these developers then you must, as reason would dictate, have a teacher that presents a higher-than-intermediate understanding of these technologies.

Before you suggest that I write an article to amend previously made mistakes (“Instead of complaining write your own article.. blah blah blah”) I’d like to let you know that I will do no such thing. It is your responsibility to find the best authors and the best content featuring the topic at hand.

I write this letter not only because I care, but because I am desperately worried, as are many others, about the state of jQuery within the JavaScript community, and more generally the lacking understanding that is slowly rotting the core principles of JavaScript from under its feet. Let the ignorance stain the ranks of beginners and hobbyists, as it always has and always will, but let it not protrude into a publication that claims to encapsulate the ever-changing essence of the web industry. Stop pandering to the lowest common denominator and be the best!

I realise that, from a monetary perspective, such concerns are likely to be lower on your priority list than getting that new coffee machine for your staff, but for the love of what you claim to stand for, prove to me that you are more than what I dare think you may just be — another profit-based publication whose sole concern is the quantity of its readership rather than the quality of its content.

If you’re going to publish articles relating to JavaScript then you’re going to have to tighten your belt and get to work. It’s not a playground. Currently, you’re only serving as a catalyst to the ignorance that a magazine such as yours should be out to destroy.

If you think this letter is not worthy of your consideration, then discard it as one of many (no doubt) complaints, for I am only too happy to accept that I’m right about you!

Prove me wrong. I dare you.

JAMES PADOLSEY

Be prepared for mildly offensive rhetoric and inappropriate usage of the ellipsis and exclamation mark!!!

• I think this universe is simply awesome. We’re quite tiny when everything is put into perspective. Heck, we’re just one form of life, on one planet, in one star system of hundreds of billions of star systems in this galaxy alone (which itself is accompanied by hundreds of billions of other galaxies), and yet some people still have the arrogance to feel that the human race is at the centre of the whole universe! Our wonderful yet miniscule existence is aptly covered in this beautifully poetic video from the late Carl Sagan.

• I think inline documentation, like that made possible with JSDoc, makes code ugly and unreadable. I want to see the code, and that’s all!
• I love the outdoors. I envy people that have jobs outside. And I don’t mean outside on the street cleaning up human sewage. I mean outside in the real world — the places that we haven’t yet destroyed.
• I think heavy UI abstractions like ExtJS totally take away all of the fun, excitement and challenges that should form a central part in any programmer’s role. To me, it looks like a product built for business people, and business people rarely understand the motives and desires of programmers — they only understand a couple of things: profit margins and economic viability.
• I’ve yet to sit in an office chair that won’t make my back hurt like hell after eight hours.
• I don’t believe in a God. I also don’t believe in fairies or unicorns.
• I get annoyed when people don’t realise the difference between believing that something doesn’t exist and rejecting the belief that something does exist, for it should be apparent that there is a huge difference.
• My favourite comedians of all time are Ricky Gervais, George Carlin, Frankie Boyle and Bill Hicks (watch all the videos!).
• I hate running, but I absolutely love cycling!
• I don’t understand Node.js. I really did try, but it just ended up confusing me. I’m not a Linux wizz so installing it was trouble enough.
• I think modern day advertising and marketing techniques are the bane of western society. Oh, and politicians!
• I didn’t care for the World Cup, and I always find it amusing how people shout at the TV and put flags on their cars when it won’t have the slightest effect on the game itself.
• I’m trying to become a vegetarian. Watch the documentary, Earthlings, and you’ll understand why.
• Pixar made me cry. I don’t know how they did it…
• I’d love to know how to play a musical instrument properly. Preferably the piano.
• I think humans have a responsibility to stop using non-renewable resources, but I don’t think playing the blame-game is helpful. I also don’t think change will happen given the current political and economic powers that be.
• I have a love-hate relationship with PHP. Doing most things is dead simple (which is great), but it’s such an ugly language!
• Even after all this time, jQuery is still my favourite JavaScript library. It’s small, intuitive and doesn’t require me to adopt a new programming paradigm!
• Other movies that have made me weep like a baby include The Stoning of Soraya M, Forrest Gump, The Champ and Pay It Forward.

Okay, that’s enough for today. Comment if you want. If you disagree with me on any of these points, then, GOOD! This world would be such a dull place without such varied opinions and people!

I feel that there are bad events too though — events that we feel we must utilise just because they exist — and we feel we must build into our APIs just because event-driven design dictates absolute submission to this way of thinking.

DOM mutation events

Every single time I’ve ever considered using a DOM-mutation event I’ve subsequently discovered that the problem can be better solved by re-architecting the codebase. The DOM2 mutation events aren’t well supported in less capable browsers but offer an interesting opportunity — to listen for document mutation such as attribute changes, node insertion and node removal.

This sounds cool and I’m sure your mind was buzzing with ideas when you first heard about these events, but have you actually encountered a situation where utilising these events is the only viable solution? If so, I’d love to hear it.

Programmatic events

This is where I lose all sense of comprehension. The premise is a mechanism that allows you to be notified when changes occur to your program — i.e. your objects, arrays and functions. I’m talking about the likes of Object.prototype.watch, IE’s onPropertyChange and a tonne of other new implementations (e.g.) that seem to perpetuate a dangerous disconnect of cogs that should be working together.

It seems pointless — it’s akin to starting your car, and then being notified by the car that you just started the car… an entirely redundant notification.

var a = abstraction.Array(1,2,3);
a.push(4);
// > Abstraction says: "You just changed the array"
// > Me says: "OH RLY"

Left hand, meet right hand!

Events exist so that processes outside the scope of your code can communicate with your code and let you know when certain things occur. Events typically operate up the abstraction chain — you listen for events from lower-level abstractions. I feel that the “outside the scope of your code” aspect is central to the whole concept of events and is why they make so much sense in a browser-scripting environment. The browser listens to events from the operating system and forwards certain events to the DOM where we can listen for them. It’s a simple fluid concept that works!

There’s a lot of hype surrounding event-driven programming/design at the moment and it seems that we’re approaching a risky threshold, where events are used just because they can be, and not because they should be.

If you’re creating an app, and it requires a great deal of client-side functionality, then you’re going to need to interface with the DOM to listen for events and apply certain changes. This is what JavaScript is all about. You write the logic layer of code (your own personal API) and then you write the implementation code that utilises the logic layer. You have authored two distinct layers of abstraction. That’s pretty much the gist of what we do.

What’s approaching, it seems, is an era of haphazard juggling of third-party scripts, multiple abstractions, multiple APIs and consequently, dozens of events. No need to write a consistently encapsulated logic layer — you can just bung these plugins/modules/classes into the app… To heck with maintenance, clean and consistent abstractions, intuitive APIs, self-documenting code and all sense of originality.

I’m not questioning events in general, and I will admit that they can be very helpful to make two scripts work together, but as I mentioned, I feel there’s a threshold where it becomes simply foolish…

As with any good book, the first chapter outlines what the subject matter is. The authors talk about jQuery itself and touch briefly on the DOM. You have to remember that this book is aimed at developers or designers that don’t really know that much about JavaScript, the DOM, or jQuery, so the book is accordingly written in such a way that it won’t confuse the pants off your typical photshop-wizz turned HTML/CSS guy.

So if you know JavaScript well, you might not enjoy this book — it will probably annoy you, simply because it doesn’t go into a huge amount of detail on what’s happening behind the scenes. But, for those that it’s aimed at, I think it does a pretty good job.

One thing that we have a problem with, in the jQuery community bubble, is the overzealous generation of redundant nomenclature. This book doesn’t fall short on this front. jQuery’s methods are referred to as “actions”.

The second chapter covers the most basic usages of jQuery, selecting stuff and doing stuff. It’s all innocent and simple — I like it. To keep the reader focused the authors have slipped in “A few tricks”. Among them is the popular add-a-class-on-mouseover, remove-it-on-mouseout.

Nearing the end of chapter two, the book has the following to say about the hover method:

“It requires two functions as parameters: one to handle the mouseover event, and one to handle the mouseout event.”

The book does claim to be 1.4-ready, so I think it’s only right to mention this. In jQuery 1.4 the hover method accepts either one or two parameters, and they don’t correspond to the mouse(over|out) events; they correspond to the mouse(enter|leave) events, although I guess they’re not totally incorrect on this because jQuery simulates these events using mouse(over|out) in non-supporting browsers, but it is nevertheless an oversight.

Not soon after that did I find what I consider to be a grievous anti-pattern:

$('.spoiler').hide();
$('<span class="revealer">Tell me!</span>')
    .insertBefore('.spoiler');
$('.revealer').click(function() {
    $(this).hide();
    $(this).next().fadeIn();
});

It seems that in their desperation to keep it simple, the authors have chosen to spare the readers of what would be some very good advice. When you add something to the DOM, and it doesn’t need to be referenced within a CSS StyleSheet, then giving it a class or ID, and then getting a reference to that element via that hook, is normally an almost-entirely redundant process. This would be a far better approach:

var spoilers = $('.spoiler').hide(),
    buttons = $('<span>Tell me!</span>').insertBefore(spoilers);
 
buttons.click(function() {
    $(this).hide().next().fadeIn();
});

Or, even:

$('.spoiler').hide().before(
    $('<span/>', {
        text: 'Tell me!',
        click: function(){
            $(this).hide().next().fadeIn();
        }
    })
);

If I was the author, I don’t know what I would have done in this situation… since it’s a teaching exercise, do you show the readers how it should be done, or do you show them in the simplest way possible, so as to not bulldoze them with complexities?

Moving on, the book is very cookbook’y and focuses heavily on an imagined client that has lots of strange requirements (quite typical of your average client). From the introduction to chapter three:

“The client is extremely happy [...] he believes flashy animations will help boost sales.

‘I think it needs some of that Web 2.0 that I’ve been hearing about,’ he says confidently. ‘Can you make it look more like a Web 2.0?’

‘Errrm, indeed we can,’ you assure him, as he passes you his next wish list chock-full of exciting changes—a list that will allow us to move beyond simply hiding and showing, and closer to our goal of being a jQuery ninja.”

I have a soft spot for these kind of tongue-in-cheek introductions, they’re quite popular in other programming books too, and I think it does well to mentally elevate the reader — and to develop that all-important reader-author relationship.

Before you know it, you’re into the third chapter. Chapter three exhaustively covers animation. The detail is great and the authors even take the time touch on jQuery UI’s animation capabilities in addition to covering all of the core methods. I liked this chapter, — it seemed to cover pretty much everything, although I found myself disappointed with some of the code again:

$('<div id="navigation_blob"></div>').css({
    width: $('#navigation li:first a').width() + 10,
    height: $('#navigation li:first a').height() + 10
}).appendTo('#navigation');

Let’s introduce some basic optimisations:

var nav = $('#navigation'),
    firstAnchor = nav.find('li:first a');
 
$('<div id="navigation_blob"></div>').css({
    width: firstAnchor.width() + 10,
    height: firstAnchor.height() + 10
}).appendTo(nav);

Chapter four is all about images, and takes the reader through the process of creating a simple lightbox effect. It also shows you how to download and “install” your typical jQuery lightbox plugin (in this case, ColorBox). It continues to show you how to create a simple slideshow.

The bulk of this book was obviously written before 1.4 was released. I get the impression that, upon 1.4’s release, the authors quickly went through adding in some “actions” only made possible with 1.4. They covered the new way of creating elements in jQuery 1.4, which involves passing an object as the second argument to jQuery():

$('<div/>', {
    text: 'foo',
    click: function(){},
    id: 'muah'
});

The book had the following to say:

“If you use a jQuery method name like text, html, or val, it will use the jQuery methods to set the property. Everything else will be treated as an attribute, as done with the src property.”

This isn’t entirely accurate. jQuery only uses certain methods — not all of them. Methods available for usage in this way are specified under jQuery.attrFn.

Continuing…

Chapter five brings with it a lot of UI icing… tooltips, menus, tabs and accordions. The book takes the reader through the processes involved in creating these interface elements. Just like all the other chapters, chapter five is littered with little titbits of useful information. For example, it covers event propagation and default event actions in pretty decent detail.

The next chapter is probably my favourite — it covers code construction and best practices, including namespacing, encapsulation, commenting, DRY, templating and feature detection! I was pleasantly surprised to see these topics covered in a book like this. Their templating techniques were a little lacking — I would’ve liked to see some custom-typed <script> elements (like in Resig’s solution), or perhaps some templates stuffed into HTML comments.

Chapter six continues by explaining Ajax and showing the reader what jQuery offers in the way of Ajax/XHR utilities. You’re also taken through the process of creating an Ajax-driven image gallery among some other gems.

I’m going to stop outlining the chapters now… I’m bored, and you’re probably not getting much from that (heck, you could probably just look through the TOC). The rest of book covers forms, controls, dialogs, validation, lists, trees, tables, plugins, themes and some “advanced topics”. There’s also a hefty appendices that has bunch of useful information, including a brief JavaScript tutorial for those new to the language.

Just so we’re clear, this is a good book, and if you fit the bill of a front-end wizz that wants to pick up jQuery, then this book will easily deliver. There are a couple of oversights, but in a book over 400 pages long I’d say that’s pretty amazing! Earl Castledine and Craig Sharkie have done a pretty awesome job!

I downloaded Eclipse and the “Java runtime”, only, of course, to find out that I already had about 10 different Java runtimes already installed. I fired everything up and then stopped; I had absolutely no idea what to create… What can I say? The command-line doesn’t excite me! Yes, I know pretty much anything can be created with Java, even hardware-accelerated games, but all the beginner-tutorials out there only show you the monotonous command-line drivel.

I also purchased a book recommended by the University; I believe it’s the one we’ll be learning from in the first year. It’s called “Objects first with Java” and goes into a tremendous amount of (unnecessary?) detail; I haven’t really got past the first few pages. I’ll tell you something about objects; you’re never going to learn squat about them from tutorials or books. Yeh sure, you’ll get an idea about what they are but you’ll never appreciate the abstraction provided by OO language until you dive in.

Now, don’t get me wrong about this whole University thing; I am looking forward to the “experience” but I’m not exactly overly-excited about the impending course material. I haven’t even begun and I’m already finding it dull; I’ve no doubt that I’ll be pleasantly surprised though… I’m sure the first lecture will prove enthralling!

I’ll be honest with you; I’m only going to University because “that’s what one does after school”. Heck, most people go to Uni for exactly the same reason (they just don’t know it); it’s what’s expected of us. You can say what you want about it but essentially, University is yet another device used to extend and perpetuate the status-quo; i.e. us working and the government getting richer. I just can’t wait; out of uni with a load of debts and then into the monotony of a “career”. Eventually I’ll have additional burdens that will require monetary attention and before you know it I’ll be where most of the British upper-middle-class finds itself, paying off debts… living the dream!

Isn’t it amazing, I haven’t experienced any of this impending fate yet and I already have the capacity to be utterly dismissive and totally negative about it all! Here’s hoping the grass is greener!

Yes, a recent survey by Digg revealed that only one quarter of all IE6 users have the power to change. This minority is made up of two groups: those that simply don’t see a need to upgrade and those that prefer IE6 to other browsers.

So, without sounding too pessimistic, trying to get IE6 users to upgrade is almost entirely pointless! Your efforts would be better spent teaching 75% of humankind how to fly!

I haven’t really got a good idea; in fact, I’m equally as clueless as most of you… How on earth are we going to solve the IE problem, or, rather the “Microsoft” problem?

Have you ever read about that world record that was set when a bunch of people somewhere jumped up at exactly the same time? Speculation has it that the earth was temporarily knocked off its axis, which, consequently saved the earth from a massive meteor strike!? Well I haven’t, but I do have a similar idea that is almost guaranteed to work.

Imagine, if every single website on earth suddenly broke in IE – users of IE would be utterly confused and annoyed – there would be an epic stream of complaints battering every IT department this side of the sun! Eventually it would result in the demise of IE (all versions). So you see, it is possible! Together we can bring down IE, it just takes a tad of collaboration!

Kill it with fire apathy!

It’s not irresponsible; it’s only logical.

I think the personality types associated with workers in this industry (the “web” industry) prevents us from taking the kind of action inherent in other FFS (frequently-found-striking) industries! At our fingertips we have the ability to destroy or to save; with a single line of code we can affect millions!

Take a stand! Indifference will, for once, save the world! Long live Web Standards!

For me, the comments section of a blog post is where users can contribute thoughts concerning the material covered in the post; not spelling mistakes, or a complaint about the site’s content. Apparently not everyone feels this way, because whenever I go to read the comments there’s always a few egotistical children leaving comments about the damn grammar!

Now, I’ve probably done it a couple of times in the past myself but I’ve stopped – I eventually realised I was only doing it to gratify my own needs; I wasn’t really interested in the grammatical correctness of any post – my ego just required a frequent pampering, apparently in the form of grammatical superiority.

Sometimes it may be appropriate to point out these mistakes; if the mistake will cause obvious grief to other readers who take heed from the post then by all means contribute your correction, but if it’s a tiny, barely-noticeable mistake then please keep it to yourself… or, if you feel your alter-ego “Grammar Nazi” kicking in then, by all means, send the owner of the site an angry email.

I have a secret; I delete non-spam comments sometimes! Yes, it’s true! Do you know why? Because this is my website and as such I feel it my responsibility to police the content of it – if a comment is defamatory or just downright rude then I’ll delete it, or if I feel the comment adds absolutely nothing to the post then I’ll delete it. For example, if your comment contains just one word like “Wow!” or “First!” or “Interesting!” then it’ll probably be deleted; why are you wasting your time writing such drivel?

I rarely have a problem though; this is a tiny blog with a tiny readership; something I’ve come to appreciate greatly!

I do feel sorry for the guys at Smashing Magazine! With over 100,000 subscribers they really do get some crap appearing in their comments!

“literalHTML”

A tiny but powerful modification allowing you to specify HTML/DOM structures inline in your JavaScript code, an example:

var className = 'active';
var myMenu = |
    <ul>
        <li class="{className}">Item 1</li>
        <li>Item 2</li>
        <li>Item 3</li>
    </ul>
|;
 
// myMenu is now a DOM object:
myMenu.nodeName; // "ul"
myMenu.childNodes; // [ <li.active>, <li>, <li> ]
 
// Do something:
jQuery('body').append(myMenu);

View here »

“getDescendants”

Something I required for a project; a function to gather all descendant-elements down until a certain depth is reached:

<div>
    <ul>
        <li>Something <strong>interesting</strong></li>
    </ul>
    <p>Something <span>else</span></p>
</div>

Examples:

var div = document.getElementsByTagName('div')[0];
getDescendants(div, 1); // -> [ <ul>, <p> ]
                        // i.e. children
getDescendants(div, 2); // -> [ <ul>, <p>, <li>, <span> ]
                        // i.e. children + grandchildren
getDescendants(div, 3); // -> [ <ul>, <p>, <li>, <span>, <strong> ]
                        // i.e. children + grandchildren + great-grandchildren

View here »

I’ll hopefully be adding to the repositroy with new exciting discoveries in the near future; visit my profile and “follow me” to stay updated!

The book is mostly aimed at beginners but does cover some more advanced topics so may be of interest to the more savvy web designer or developer. Actually, anyone wanting a solid jQuery reference would benefit from this book!

I’d guess that one of the troubles with writing a book just about a specific topic is that you’re limited to its confines. This book does not start by discussing the DOM API or JavaScript itself, but instead it begins by first explaining the intent of jQuery and then by detailing the jQuery wrapper function and how you can utilise the power of CSS within this magical dollar symbol. jQuery is wonderful but, in my opinion, without a solid foundation in JavaScript you can never be as good as you could be.

The authors did a wonderful job and I don’t think anyone could ask for a better book about jQuery but I cannot help but raise the question of whether or not jQuery is the practical place to start.

I have this image in my head of some hotshot interface designer longing for some hotshot Ajax’y coolness to suit his ego; he wanders into Waterstones and picks up a copy of this jQuery book he’d heard of, he takes it home, and willingly begins on the long journey of learning “jQuery”. If the world were what I wanted, then this guy would soon realise the error of his ways and how he should have learnt JavaScript before venturing into it’s squeeky clean abstractions; but, unfortunately, the world is not like that; the reality is more upsetting – not only will this designer never realise the error of his ways but he’ll live on, writing jQuery everyday, creating bouncy effects and “jQueryfied” web interfaces. Why is that a problem? – Because he will never be able to program in JavaScript he’ll lack the fundamental knowledge that would otherwise ensure him complete cross-browser and timeless sanity!

Did you see that!? While discussing the necessity of learning JavaScript before jQuery, I went off at a tangent; Something book authors are not afforded the luxury of doing… But that isn’t to say it was a worthless moment! That’s why books bug me a little, it’s all about size, specification and compensation! It’s never really about the information. ¹

Back to the book…

The book goes into considerable depth and manages to cover most, if not all, aspects of jQuery. In addition to feature descriptions and examples, Karl and Jonathan discuss best practices and continually advise the reader on the best course of action in various situations. jQuery’s UI framework and other various plugins are also discussed near the end.

I only have a couple of concerns about the book and its content. I don’t feel that the surrounding technologies are given enough time in the book. A preliminary chapter on the basics of JavaScript (and the DOM) would’ve certainly benefited beginners. While the average reader might not see the relevance of such a chapter, they’ll probably have a better understanding of the syntactic discrepancies of jQuery because of it. Even though having knowledge of JavaScript is a noted prerequisite, I doubt many readers of the book would accept this necessity. Beginners are vulnerable to the classic mistake of learning a framework before learning the language on which it’s based.

The only issue with offering such a chapter would be that half the readers would probably find it either useless or not worth reading… yet another reason why books bug me, you’ve got to cater to such a large audience with such varying motives that you’re bound to disappoint at least a few of them!

I only have one other tiny problem with the book, and this is very specific issue and probably a little over-zealous of me to even mention it: In the first chapter the authors state that without jQuery’s bespoke ready event you’d have to rely on the onload event to run code when the DOM is loaded. Then they continue by saying how you’d have to bind a named function to the event by obtrusively placing it in the HTML (<body onload="...">). These assumptions highlight a notable problem with jQuery and its “marketing” techniques: The conception that unobtrusive JavaScript is only possible with jQuery is far too widespread, even the assumption that jQuery makes unobtrusive coding easy is, in my view, rubbish. There are far more respectable ways to market a product (i.e. jQuery) than slamming the competition (i.e. JavaScript without jQuery). ²

Conclusions

The content of the book, as it is, is definitely up to scratch. The only issues I have are more theoretical and are largely unrelated to this particular publication.

If you are considering buying a book of this type or are possibly on the edge of a decision then I absolutely suggest this one! Everything you’d want to know about the jQuery library is neatly squeezed inside the covers of “Learning jQuery 1.3“. Don’t be put off by my negativity; like I said, those are just a couple of my opinions concerning the general approach of books like these, not the content of this particular one.

Even if you’re not considering buying any book at all, I would definitely consider looking at this one. Although, if you’re a total beginner I might suggest a more gentle and progressive introduction to the world of JavaScript, possibly “JavaScript: The Definitive Guide“. If you can’t be bothered with “regular JS” and just want to get at the cool stuff then I urge you to reconsider your stance. JavaScript isn’t as bad as people make it out to be, and it’s only getting more popular; learn JavaScript, then learn jQuery (or a library/framework of your choice).

¹ – By this, I mean “information” is rarely the prime concern when publishing a book. While creating an informative book may be the sole objective of the author it’s not going to be the publisher’s primary concern!
² – Library’less JavaScript is not in competition with any particular library but the marketing techniques of these libraries has created this dillusion; that JavaScript is not good enough, and that somehow it’s all too hard…

I reckon the great majority of people in this industry would unconditionally subscribe to the conception that an Apple Mac makes you more productive. This little white magical box somehow enhances your ability to produce amazing things, right? Oh and let’s not forget all the other Apple stuff. The iPhone, Ipod, iMac, MacBook, Mac mini – they’re all magical creations tht enhance our existence!

I guess it’s all down to the modern-day infatuation with shiny new technology coupled with manipulative marketeers operating you like a puppet! I mean, seriously, do any of you think that Apple, the corporation, cares a smidge about how productive you are or how innovative your creations are? They don’t! They really don’t give a damn!

Don’t get me wrong, I love new technology – I think it’s great. But I’m not going to consign to this crazed kind of addiction that so many people have. No, I don’t need that new MacBook, I’m perfectly happy with my three year old PC running XP! And speaking of Operating Systems, no! I don’t need Vista, OSX or Windows 7 – I can manage quite happily without all that!

Real web designers use Macs!

Oh I see; all this time I was under the delusion that one’s credibility in this industry was platform agnostic but obviously I’m totally wrong. What was I thinking!? Of course, I see it now, the extent to which a developer is good at his/her job can be solely measured by the software and hardware they use! How could I have ever thought otherwise!?

Grow up! This industry isn’t about my hammer being better than yours; it’s about what I create with my hammer, and what you create with yours! Like the old saying goes "A bad workman blames his tools" – actually, I’d take it further: "A bad workman feels so passionately about his tools that he values them more than his actual work!"

I actually find this quite comical:

There is absolutely no reason in the world you should use anything other than Keynote. Period. I don’t care if you’re on a PC — if you’re serious about speaking, buy a MacBook just for presenting. There is an astounding difference (not an exaggeration) between the tools, canvas placement, typographic control, and overall aesthetics in Keynote compared to PowerPoint. Once you become familiar with Keynote, which isn’t an arduous process, the productivity and just plain enjoyment you’ll experience using it over PowerPoint is completely worth any switching costs.

Obviously Cameron Moll feels that to succeed as a speaker you MUST BUY A MACBOOK!

I’m going to stop now, I feel I may explode!

If you suck at something on a PC you will also suck at it on a Mac!

PS, congratulations Apple, you’ve actually made me want to hold on to my PC out of protest!