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.
All sizes are minified, brotli compressed, and representing these two files, when possible:
- the min.js file is what
https://unpkg.com/{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 unpkg.com, 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 `https://unpkg.com/{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.
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.
| 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.
| 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.
| 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.
| 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.