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.
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.
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.
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):