The Micro Library Phenomenon

A relevant ad will be displayed here soon. These ads help pay for my hosting.
Please consider disabling your ad blocker on Pony Foo. These ads help pay for my hosting.
You can support Pony Foo directly through Patreon or via PayPal.

As of late, there seems to be a steady trend towards minimalist DOM (and BOM) abstractions, these micro-libraries generally trade functionality and flexibility for performance boosts.

The two most common benefits of using this kind of modules are:

  • Dramatic performance boosts, sometimes by a factor of ten, or similar
  • Lightweight footprints. Less functionality translates into less bandwidth going to waste

You can browse for micro libraries here. I’ll examine a couple, and then theorize on the subject.


The first example that pops to mind is ThinDOM, as it only came to light a little over a week ago.

ThinDOM is a thin DOM wrapper out-classes jQuery when it comes to DOM manipulation. It provides only a few methods, which are conveniently named like their jQuery counterparts:

  • .append() is a blisteringly fast alternative to $.append
  • .css() doesn’t do any validation, or value transformation, like $.css does
  • .html() doesn’t provide any safety, no parsing, nothing. $.html is a tad slower
  • .attr() just sets attribute values. That’s it. Here’s $.attr’s take
  • .get() unwraps the element wrapped under ThinDOM

Their API is kind of clunky. Their example isn’t the prettiest.

var captionDOM = new ThinDOM('div').attr('class', 'caption')
    .append(new ThinDOM('div').attr('class', 'votes')
            .append(new ThinDOM('a').attr({'class': 'up', 'href': '#'}))
            .append(new ThinDOM('a').attr({'class': 'down', 'href': '#'})))
    .append(new ThinDOM('div').attr('class', 'meta')
            .append(new ThinDOM('span').text(author + ' - '))
            .append(new ThinDOM('span').text(points + ' point' + plural)))
    .append(new ThinDOM('p').html(body)).get();

But… if it’s performance you need, then it definitely wins out.


This library started out as an alternative to jQuery for the mobile browser. They didn’t need to support IE in mobile browsers, so they cut that from what jQuery offers. To further expand this footprint gap, you can choose to leave out the sub-modules you don’t need, in order to make the footprint even lighter.

jQuery is currently sporting a 32kB footprint, Zepto is a lightweight alternative, currently sitting at a maximum of 9.7kB minified and gzipped.

Zepto offers no support for IE, they recommend you to fall back to jQuery in IE.

In conclusion, Zepto is awesome. If you can get away with it.

There are thousands of micro-libraries like these, and probably even more so in the world of Node and npm.

Why is any of this relevant?

It’s about philosophy. Design philosophy. And I think we owe this, in part, to Node. Most npm modules are very compact, determined to fill that little hole and become the de-facto tool for that super-specific purpose.

All of them are open-source. More people should realize how huge that is. It’s huge because it means you can learn how the best, successfull frameworks and libraries do it. It’s true that open-source is gaining a lot of traction. Ever since GitHub came out in 2008, and then Node in 2009. In the world of JavaScript, the concept of closed-source is something that you can’t even begin to fathom, and that encourages open-source.

Since we were talking about imgur, let’s look at the search results in npm for the keyword “imgur”. There are around ten imgur related modules. Many of these, just upload to imgur. Such is the case of node-imgur.

Sure, micro comes with a cost. Everyone wants to write their own modules. Generally speaking, though, the best ones prevail. The others fall off into oblivion.

In the end, having many alternative frameworks that do the same thing, gives you choice, albeit a tough one sometimes. But, I’d much rather have to pick from a ton of micro-frameworks that, potentially, do what I want. It beats having to use a giant library that can do everything but it’s exaggeratedly complicated, or heavily undocumented.

Identifying the Source

Granted, taking your pick can be tedious at first. But if you are not content with what the existing solutions do, you can always roll out your own, and help the next guy in the process.

When I first wrote about rolling my own packages, I was just getting started in the world of Node, and I considered the vastity of choice an issue. I changed my mind about that.

Micro-frameworks in JavaScript are a phenomenon that we hardly ever see in other communities, and therefore, it’s a hard thing to wrap our head around.

We have tons of packages for handling parallelism in regular code, not just for ocassional and complicated multi-threaded services. But it doesn’t just end with parallelism. We have utility libraries for just about anything. And we owe a large portion of that to the fact that Node is largely unopinionated.

Node barely does anything. It just provides a layer of abstraction over the operating system. Other than that, you’ll probably have to rely in someone’s package, or write your own.

Some packages are absurdly specific. Most other communities don’t even bother to create modules that small.

It’s like the npm community discovered a new sub-atomic particle!

Liked the article? Subscribe below to get an email when new articles come out! Also, follow @ponyfoo on Twitter and @ponyfoo on Facebook.
One-click unsubscribe, anytime. Learn more.