For the past few years, I’ve been working on a side project at the University of New Mexico. There’s not a public-facing aspect to it that’s worth highlighting, but the administrative side is a very heavy JavaScript application, and it didn’t start that way.
There are several pages to the application, each of which is dedicated to a major piece of functionality. As our registered user base has grown, the amount of information that needs to be managed has grown quite a bit, and some of my earlier pages were really starting to slow down.
When we first started building the application, we went with jQuery. I’d been writing JS since before the libraries and toolkits were really on the scene, and remember playing with things like YUI 1.0 and Prototype in prior websites, but my coworker/team lead was really keen on trying out this tool that was starting to get some traction.
From a CS perspective, at first, jQuery’s interface really bothered me. I liked that Prototype made JS feel a lot more like C++ to me. It felt like I could build some interaction, using an approach that felt natural and proper to me, like it was somehow “fixing” JS. Also, let’s be honest: chaining is ugly.
However, jQuery made working with the DOM so much easier, and Ajax work was just dead simple (especially when cranking out JSON on the backend), so I stuck with it.
After working in jQuery for a while, I stopped thinking about JavaScript. I let jQuery kind of take over my brain. For a while, I fell really heavily in love with it. It felt just magical. Things just worked. Working with IE wasn’t as awful (though still not great, of course).
I was quite the fan of jQuery – and in many ways, I still am. jQuery is really a fantastic tool for doing DOM manipulation and simple Ajax work. The problem is, my application outgrew simple Ajax work and DOM manipulation.
As the application grew in functionality and codebase, performance really started to sink. It was quite awful. However, I was fortunate enough to have stumbled upon a relatively new podcast named yayQuery. Listening to the yQ crew talk about anti-patterns and hiddenhancements and such, I really grew interested in optimization. When jQuery 1.4 came out, I was ready to take advantage of it, and managed to take one particular page from a load time of ~12 seconds to ~3.
Over the past year, I’ve gone through and created a couple of new pages to replace some of the worst offenders, and tried cleaning up here and there where possible, but on the whole, I realized the major problem I’d run into was that I stopped thinking about my data as data, and started thinking about it more as DOM.
If there is one takeaway from my entire ramble here, it is this: Don’t let jQuery DOMinate your thinking. When all you have is a DOM hammer, everything is a DOM node.
I had been creating ridiculously complex markup with a lot of hidden elements in
order to preserve data, rather than using things like jQuery.data to store JS
objects. I was also doing things like not saving my resulting jQuery objects,
running code like $("#foo") repeatedly, not thinking about the impact of
creating several new jQuery collections. It’s almost embarassing to admit that I
was generating a bunch of <li> tags and actively adding them to the DOM one at
a time, for literally hundreds of list items, but I was.
You’ll note that not all of the things I was doing above are jQuery’s fault. It’s just that with jQuery, I stopped thinking about JavaScript – and, in retrospect, that was a really bad thing.
These days, I’m doing a lot with Dojo and while it’s not the JS panacea, it’s the first of all of the toolkits and libraries that’s felt like I’m really writing JavaScript, and not just writing something else that doesn’t feel like JS. I’ve grown to love JavaScript as a language for its own merits.
So, whether you’re coming to this post and you’re a huge jQuery fan who hasn’t tried other tools, or you’re a seasoned vet with the DHTML scars to prove it – I encourage you, reach out and try something else. It doesn’t matter what you go for, so much as you’re trying something different.
Resources
Larger libraries/toolkits (typically cross-browser, all with rich DOM/Ajax support, often including UI frameworks, etc):
Smaller libraries (focused on specific pieces of functionality):
Other reading:
- On jQuery & Large Application (the original impetus for this post)
- jQuery’s Best Friends
- When you’re build a non-trivial JS application…