Skip to content

Instantly share code, notes, and snippets.

Last active September 24, 2021 22:03
  • Star 10 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
Star You must be signed in to star a gist
What would you like to do?
My libraries in bytes

Toward better libraries

I am recently re-branding my libraries as µ (micro), refactoring these when necessary, dropping IE < 11 support, improving the logic where possible, or providing a better, more robust, or faster, API.

In few words, on the right there is the modern version of libraries I've used for the last ~5 years in production or for side projects, and I suggest anyone having one of the earlier dependencies, to have a look at their modern, micro, counterpart.

How to read these tables

All sizes are minified, brotli compressed, and representing these two files, when possible:

  • the min.js file is what{library} returns by default, and IE11 is the target, with polyfills included
  • the es.js file, or, in some case the new.js one, is also published in, but the target is not tarnspiled at all, hence suitable for ES2015 browsers, and polyfills for IE 11 are also out of the equation.

Both files can be used as global utility/library, but all modules are also usable as native ESM without issues:

import {things} from `{library}?module`;

Whenever there are notable differences between the two libraries, I explain what changed, or what has been refactored.

To know more about my other libraries, feel free to check this other gist out.

Why not bumping major version instead?

Beside the fact that bumping major won't allow name rebranding, if the idea is similar but the API or supported features and browser targets are completely different, I think renaming, after rewriting, is a better migration approach.

I am also not planning to rewrite everything I've done to date, but the most useful minimal stack might as well be published behind the µ (micro) prefix, as I've been doing for both client/server libraries in the last 1+ year.

Template literal DOM manipulation

lighterhtml µhtml
min.js 4784 2751
es.js 4147 2516

The biggest difference about these two libraries, is that µhtml doesn't support sparse attributes updates, but it's also something hyperHTML used to not support, and hyperHTML is the most battle-tested library out there, when it comes to template literal based DOM manipulation, reaching ~100 million users in production, so I guess one could live without sparse attributes.

µhtml is also superior in terms of performance, as its reduced logic allows the code to take few shortcuts lighterhtml can't, due the indirection sparse attributes can cause.

Connected / Disconnected

disconnected µconnect
min.js 356 438
es.js 427

Beside having a much better API, µconnect helps passing along listeners right away, reducing overall the code size + it comes with CustomEvent polyfill included, while disconnected requires a WeakSet and a CustomElement polyfill, resulting in a bigger size once combined together.


augmentor µhooks
min.js 1164 880
es.js 814

While augmentor is surely more battle-tested than µhooks, the whole logic has been refactored to "do the right thing" in every condition, with bulk updates for multiple state changes per hooked function, improved performance in general, and the intent to avoid any unnecessary invoke, as example flagging bluks as no-op if the outer controller invoke the same hook before its scheduled changes are meant to happen.

The main difference in terms of exports, is that µhooks exports a hooked utility, as main entry point to enable hooks.

Hooks w/ DOM integration

dom-augmentor µhooks-dom
min.js 1859 1633
es.js 1509

Here µhooks-dom includes µhooks-fx and µconnect, providing all needed polyfills for IE 11, but substantially doing the same thing dom-augmentor does, so it's a drop-in replacement, exporting all µhooks utilities too, but it propagates state updates up to the closest render(...) hook to avoid duplicated invokes, whenever it's possible.

Hooks w/ Components (React-like)

neverland µland
min.js 6796 4838
es.js 4338

Here µland is not only smaller, but much more efficient and performance oriented than neverland, thanks to its new asynchronous core able to bulk every inner state change at once, without repeating callbacks for no reasons.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment