Lazily evaluating properties is not just handy, but mandatory in some case. This post explains strategies and provides answers regarding this topic.

Some Background

Where I work, we deal daily with hundred thousand things to eventually parse when needed, and having lazy resolutions, in terms of parsing time, to provide meaningful results on demand is not an option!

Without boring you with too many details, I wanted to understand if the way we are lazy-parsing things is efficient, and here there’s some result.

The Pattern

JS provides many ways to do the same thing, and that’s both awesome and cumbersome, as we don’t have…

Heavily inspired by hyperHTML intents ability, exploring a way to easily migrate from hyperHTML to uhtml, this 3 LOC commit enabled exponential features within the lightest, fastest, template literal engine, of its kind, out there.

The TL;DR version of this post, is that µhtml now accepts interpolations callbacks as elements content, passing along the comment node used to hold whatever value such callback will return: strings, numbers, arrays, … whatever!

A wild uhtml-intents helper appears

Still based on few, size-irrelevant, extra lines of code, the uhtml-intents module does nothing more than register an intent, and be sure this gets executed while rendering.

import {define, intent}…

Update

Check my talk at Speakeasy JS 👋

JSDOM is awesome, but it’s slow at pretty much everything, except repeated querySelectorAll, which is a “not so interesting” use case to me.

It’s also something downloaded 14M times per week, accordingly to npm stats, making it the most battle-tested, non-browser, DOM module available: hard to compete there.

There are alternatives too, such as basicHTML, but it never really had momentum and, after my latest tests, I’m glad it didn’t, as it’s surely faster than JSDOM, but it fails at pretty much everything, being born to solve mostly viperHTML and herey-ssr use…

There is a “slightly annoying” difference, or better, a limitation, in native ESM import, compared to CommonJS require: it’s not possible to deal with the module system internal cache, hence it’s not possible to invalidate such cache, or tell NodeJS that module-x is actually referring to file://x.js, unless importmap lands officially in NodeJS core too.

“… but I’m sure there is a module for that …” and you’re obviously right, although we don’t always control how NodeJS is bootstrapped, as example via serverless services, or server side workers, so I’ve decided to explore a different approach.

A Home Made Registry

The technique I am…

WebSQL left the Web a while ago, but WebAssembly brought it back, as nothing on the Web is as simple, yet powerful, as this wonderful Open Source project.

This post summarizes my idea behind sqlite-worker, a module that brings sql.js in Web pages and/or workers, and persists through the only option we have these days: IndexedDB.

A quick recap

“IndexedDB is the best non-blocking database a developer could desire”, said nobody ever, and the reason is simple:

• the API is everything but straight forward (low-level is the excuse)
• querying it makes little sense, as it cannot do much, compared to SQL
• but hey…

While most developers use this utility to enrich object literals and data, in more than one occasion I’ve found myself loving its usage elsewhere.

What does Object.assign do?

Well, the short answer is that it copies one or more objects properties to its very first argument, but that’s a boring story.

const data = {};
Object.assign(data, {other: "data"}, {and: "more"});
data;
// {other: "data", and: "more"}

It also returns the very first argument, so that creating a fresh new object with one or more extra properties is “easy-peasy”:

const data = Object.assign({nough: 1}, {moar: "data"});
data;
// {nough: 1, moar: "data"}

How else can we use Object.assign?

Every single time…

Hooks are a pattern, not something usable with React library only, and this post would like to explain, and walk through, some interesting possibility.

What are hooks?

Hooks are nothing more, and nothing less, than a wrap around a generic callback. The callback itself is not a hook, unless it’s being handled by a hook-helper, in this case provided by µhooks library, which is the tiniest, and fastest, I know out there, and “it just works” ™.

As example, this is a generic callback that uses internally some hook-helper, but it won’t ever work as expected, unless it’s wrapped by a hook-library helper.

…

I write, and sometimes rewrite, various libraries, and I’ve received the “too many libraries” complain more than once … but let me try to explain what’s behind my Open Source Software ideas.

Update

I’ve created a GitHub discussions repository, which is better than a forum, to hopefully simplify bootstrapping a tiny community around my projects.

As Independent Libraries Author

I try to read carefully trends on mailing lists and Twitter, where apparently everyone complains about JS’ fatigue, libraries size, bloated and slow Web, and all I think about, every single time, is the following:

I’m providing pretty much every popular pattern through modules that, once…