The Latest Love of My (Programming) Life?

Is it really possible to love jQuery? It certainly seems like it is from the numerous blog and forum posts I've read while trying to figure out how to make it do some fairly simple things. Many of the posts end with rather disturbing terms of endearment: "...this is why I just love jQuery" being a typical example. Yet I'm still not sure that our first blind date will result in a lasting relationship.

Perhaps if you spend your life building websites that incorporate the now mandatory level of flashy UI, animations, and interactivity jQuery is pretty much a given. At least it means that paranoid people like me who have Java, ActiveX, and Flash disabled in their browser actually get to see something. I got fed up with the sites you used to see (or, in my case, not see) a while ago that were basically just a large Flash animation - invariably with the focus on appearance rather than containing any useful content. But disabling script is generally not an option these days.

Mind you, I'm now finding the same problem with sites that are just a single large Silverlight control; though - being a 'Softie - I guess I do tend to trust Silverlight rather more than other animation technologies. Well, marginally more - I'm still a paranoid neurotic. You know what they say: "Just because you're paranoid doesn't mean they aren't watching you."

So, getting back to the main thrust of this diatribe, can I get to the point where jQuery is my newest live-in lover? I have to say that initial impressions were less than favorable; through this was probably a combination of the fact that I've almost forgotten how to use JavaScript, and that much of the documentation I found on the Web seems to assume you are either an idiot or already a jQuery expert.

There's plenty of API information, and plenty of blogs that provide just enough to not quite get things working. As an example, I'm using the load method to reload a partial section of a page into a div element, and I want to change the mouse pointer to a "wait" cursor and display an indeterminate "Please wait..." image while it loads. The docs say I can flip the cursor for the page using the css method of the element that holds the partial page content (though they don't mention that it doesn't work on hyperlinks within it). And that I can display my hidden div containing the loading image using the element's show method.

But, of course, figuring out this is the easy part. Simply calling the methods one after the other to change the mouse pointer, show the image, load the new content, hide the image, and change the mouse pointer back again doesn't work. Instead, you have to chain the method calls so that they only execute after the previous one has completed - mainly, of course, because the load method is asynchronous. The "getting started" docs hint at all this without actually using the dreaded "a" word; while the "real programmer" docs are full of barely comprehensible tips such as "CSS key changes are not executed within the queue."

The trick is to realize that all of the methods (at least all the ones I've found so far) take an event as the final parameter. That's when the aging gray cells slowly spluttered into life and I remembered how we used to use the setInterval method of the window object to execute a delay during some hand-crafted animation in JavaScript. You gave it the name of another function to execute after the delay, and your code ended up as a mass of functions calling other functions after they finish what they're doing (we called it "Dynamic HTML" in those days). It usually required only a couple of hundred lines of JavaScript, and generally no more than a week to debug using alert dialogs, and get it all working properly.

Of course, these days, asynchronous programming is a common scenario, so I'm a bit surprised that the docs don't just bite the bullet and use the "a" word from the start. But I guess there's another issue as well: no programmer with any remaining shred of pride would use separate callback functions. You wouldn't dare let anyone see your code if it didn't use lambda expressions for callbacks - even if you are still a bit frightened by them. Let's face it, finding syntax errors and debugging statements that cover twenty lines and end with a dozen closing curly and round brackets is not a procedure designed to aid mental stability or promote a restful programming experience. Especially when the typical error message is just the amazingly useless phrase "Object expected". So maybe the documentation people want to avoid using the "l" word as well...

But the great thing is that, once you grasp the facts about the unmentionable "a" and "l" factors, it all starts to make sense and even - dare I say it - seems easy. Compared to the effort of doing the same in pure JavaScript, jQuery is starting to look like a distinctly attractive lifetime partner; even if it's really just a library that hides the complex stuff underneath a layer of not quite so complex stuff. And it may even help you get to be less frightened of lambda expressions.

Though what I still can't figure is why, when not so long ago everyone was decrying the eye candy proliferation of scrolling text, sliding sections, and animated content in web pages, everywhere I look now has fancy jQuery effects that often seem designed to be as annoying as possible. And, of course, why we're still using JavaScript more than fifteen years after most people realized it was a rather nasty technology that could never last...


Skip to main content