By Craig Buckler

Is jQuery Too Bloated? Try jquip.

By Craig Buckler

It’s been a busy few weeks for jQuery developers. We’ve received jQuery 1.7 and jQuery Mobile, but a third project is now vying for our attention…

At a little over 32KB for the minified and gzipped download, few people could accuse jQuery of obesity. But it’s rare you need all its abilities. Enter jquip — or jQuery-In-Parts; a smaller, leaner and faster fork of library. It contains 90% of the best parts at a fraction of the size — just 4.28KB (even the uncompressed source is a mere 21.5KB).

You get a lot of functionality in that tiny package:

  • the main $(selector)
  • DOM traversal methods such as eq, first, last, slice, prev, next, siblings, children, etc.
  • DOM modification methods such as append, prepend and remove
  • CSS class modification methods such as hasClass, addClass and removeClass
  • Event methods such as bind and unbind with all the standard types (click, mouseenter mouseleave, submit etc.)
  • Utility functions such as each, trim, extend, merge, isArray, etc.

The library has a modular architecture so other jQuery facilities are available as plugins which can be included when you require them:

  • documentReady: $(function()) and $.ready
  • css: css, Width and Height methods
  • ajax: ajax, get and getJSON methods
  • custom: various methods such as queryString and event object isTab, isShift, and cancelEvent

The distribution package provides the plugins as separate scripts and within a single 20KB jquip file — which is just 7.84KB when gzipped. Ultimately, jquip’s developers Demis Bellot and Jey Balachandran hope to implement all the missing jQuery methods as plugins.

I’m impressed. In an age of monolithic multi-megabyte pages, it proves some developers still care about nimble lightweight code. And there are good reasons to trim the fat given the increased popularity of modestly-powered smartphones, eReaders and tablets. jquip could be a magical diet pill for your site’s slimming regime.

  • Dennis

    I have not used jquip myself, but judging solely from your post, I don’t believe I will be. I use dom ready, ajax, and the CSS tools of jQuery day to day. Even if I start a project, whether it be for mobile or not, I know at one point I will at least be using the dom ready and ajax functions. Having these loaded as plugins creates unnecessary requests, why not just keep the “extras”, you might need them as your project matures. 32KB is nothing, even for mobile.

    • Remember, anything over 25K isn’t cached on iPhones.
      Not sure about Android, but it is more.

      Also I would like to read a proper comparison of jquip to jQuery. The important part (besides it working) are what jquip is missing.

  • I’m a fan of this. I’ve been arguing for some time now that jQuery is too bloated. I wonder how much file size would change if they removed support for older browsers.

  • Alex

    I design a control panel for an embedded system with limited bandwidth. I’m definitely going to switch to this new library as I only need the aforementioned methods.

  • This sounds pretty good, but what the article lacks is what you *don’t* get.

    @Dennis, if you need to use the full package from jQuery, then you should certainly continue to do so. However, if you only use the convenience stuff like selecting and modest manipulation of the DOM, then it’s very welcome.

    It’s a bit like not using Word to edit a simple text-file, when a basic editor will do. Sure, on a good PC it won’t matter much, but on a mobile it will. And size aside, it’s not only download speed and cpu power (== battery usage), but also there should be less bugs in a smaller library.

  • Anon

    I would be more concerned about ad broker javascript amounts. This page for example has 554.3KB worth of javascript.

    Even google plus one button takes 38.9KB

  • Does the file size of jQuery become a moot point if we all agree to reference the save version of jQuery, hosted by the same CDN (google)? If it becomes likely that new visitors to our sites have already downloaded the full library from somewhere else, then referencing a different (yet slimmer) version of the library would introduce a greater hit in download speed, correct?

    • CDNs certainly help, but there’s no guarantee a user will have jQuery cached – especially on mobile.

      Also, remember that the browser must execute the full jQuery library on every page when it loads. jquip will certain run faster.

  • As soon as the bug reports roll in, you will understand how a library grows…

    @andy matthews I’m not sure how many times the jQuery development team needs to say this, but _very_ _little_ code would be removed if we dropped support for IE 6, 7. An incredible amount of code is written to “stupid proof” the API from poorly written userland code.

    • Most of CSS selector code would go since modern browsers have native implementations of querySelectorAll. Event handling would also require less code to cater for IE6/7’s non-standard implementation.

      In many ways, jQuery’s success has been built on browser incompatibilities. It smooths over the cracks to provide a consistent API.

  • Also, important to note that jquip removed the most important part of jQuery… the test suite. Untested code is broken code.

  • alexander farkas

    Your information about mobile cache size is outdated. iOS4 is caching 50kb or 100kb (

    @Craig Buckler
    Removing support for IE6 and IE7 wouldn’t really help to decrease filesize of jQuery. You have to also drop support for IE8 to get a significant reducation of file size. Additionally, you have to remove some features, like being able to extend the selector engine etc..

    And if we really can drop support for these browsers, we do not need a library, which has copied some jQuery code, we need a new clean start (like zepto.js).

    @Arne K. Haaje
    smaller code != less bugs
    One reason for jQuerys filesize is the fact, that it deals with a lot of bugs and edge cases. I’m pretty sure, that jquip has more bugs than jQuery.
    less code != faster execution
    Writing performant code, doesn’t mean, it’s less code. Often you will have to add some lazy execution techniques, memoization techniques or some extras to detect which native DOM-method is faster in current browser for the current task etc. to get a fast execution. If the script downloads 10ms faster but has to execute 30ms longer, you haven’t won anything.

    • Yes, dropping IE8 would reduce file sizes further but the browser was a large leap beyond IE6/7.

      Remember also that, where practical, jquip uses jQuery code. And, yes, while shorter code does not necessarily reduce bugs or execution speed, jquip’s developers have already reported faster execution times.

  • My concern is the amount of maintenance this over-granularization that the library makers (jquip) and the library users (developers) will bring about may not be the wort the byte-savings, given that we have technologies like offline storage, html5 cache manifest.

    I see why there’s such a need, and I agree that jQuery core is buffier than it should ideally be.

    This is the fate of any popular library. The user-base demand more on more, and the “core” (which should be kept to a bare minimum) keeps on getting bloated.

    Needless to say there’s a horde of browsers to support.
    For instance, what we can do with a single line of code using “querySelector” (if we target modern browsers only) requires a whole selector engine (Sizzle) to be merged into jQuery.

    So the faster non-standards-supporting browsers (IE?) fade away, the smaller will be the size of jQuery (and other libraries)

    I don’t think jQuery needs a fresh start. It’s modular enough in an of itself. It’s one of the first libraries which evangelized “the module pattern”, so that every component could be developed as independent modules without messing up with the core.

    Indeed, that’s the modular nature of jQuery, which enables quip to easily split out jQuery in parts.

  • Dustin Diaz did something similar with Qwery:
    Right now I’ve started a JavaScript blog at and I’m working on eventually getting some cool libraries like this up there too.

Get the latest in JavaScript, once a week, for free.