Over the last year I’ve done more work with jQuery and specifically, widget frameworks atop it. I’ve spent most of my time with jQuery UI and jQuery Tools. I like them both, but I wound up settling on the former and spending quite a bit of time with it.
Thus I’ve watched with some amount of curiosity an anti-jQuery-UI meme emerging in some projects I’ve participated in. It isn’t just that they favor jQuery Tools. Rather, they also seem intent on some broad-brushed jQuery UI bashing to go with it. Most of the time the word “bloat” emerges, and I thought I’d look into it.
“Bloat” is usually something that can be easily measured. For example, ahem, some open source content management systems ship with a significant amount of code, thus a lot of “bloat”. But when looking at jQuery UI (jqUI) vs. jQuery Tools (jqT), I found:
- jqUI: 19 Kb
- jqT: 2.4 Kb
That’s the size of the JS for each, gzip’d (in the way any normal production webserver would deliver it.) For the comparison, I made a jQuery UI download that matches the same widget framework features used by Plone, to make it even. It isn’t utterly apples-to-apples: jQuery UI also has CSS and images which add marginally to the Kb needed on a site.
But just to put this into perspective, the difference is about 1/2 the size of the Plone logo. I don’t think “bloat” could apply to pageload impact, but even if it did…who cares? Any intelligent site uses far-future expires and versioned URLs to ensure visitors only need one request for the JS library…ever.
So perhaps “heavy” and “bloat” don’t mean measurable things. Perhaps the point is conceptual heaviness. It’s true that the jQuery UI widget framework adds some ceremony in the constructor and method dispatch. But two notes in its defense.
First, the method dispatch pattern is the one recommended by the jQuery core team for plugin extensibility. Well, I’m sure “jQuery core team” probably includes lots of viewpoints, but the page I read on the topic seemed authoritative.
Second, there is a reason the ceremony is there: widget re-use and extensibility. There’s always a price to be paid for this. But when building a big system, the price can be worthwhile. I suspect systems like Plone will be paying that price at some point, just with perhaps different ceremony.
I’ve seen “bloat” connected to “CSS bloat”. I’m also not sure what specifically that means, I haven’t seen any comparisons to jqT selector hierarchies. I certainly can sympathize with this point: the jQuery UI CSS Framework has lots of classes for things such as .ui-widget and .ui-widget-container and .ui-widget-content. But so does Plone’s templating, and for the same reason as the above: large systems need fine-grained extensibility and customizability.
Personally I’m happy jqUI went that way, as they are busy stripping their main widgets down dramatically, composed from a small set of building blocks that get extended. Even better, they documented their selector hierarchy in a fairly-visible contract.
At the end of the day, my best guess is that “bloat” is being used in a non-measurable way as a style choice. Which is absolutely fine. It’s great to say “I prefer jQuery Tools”. It’s great that both exist, as I think they target different audiences. jQuery Tools when you want to quickly get something done without learning a lot of ceremony, jQuery UI when you have a big system that needs a focus on extensibility and customization.
Maybe I have it wrong, and “bloat” is something specific and empirical. Either way, they are both good choices and fairly similar in features, size, and support.