After reading yet another blog post about JS classes being “just sugar for prototypal inheritance”, I’ve decided to write this post to help clarifying, one more time, why this statement is misleading; a post that hopefully explains what’s the difference and why it matters to understand it.
Using "use strict"
directive in ES5 won’t forbid constructors to be called without new
keyword.
// ES5
function Test() { "use strict"; }
Test.call({}); // it's OK// ES6+
class Test {}
Test.call({}); // it throws
The reason is that modern classes have a new.target
concept otherwise impossible to replicate in ES5, without…
Lazily evaluating properties is not just handy, but mandatory in some case. This post explains strategies and provides answers regarding this topic.
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.
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!
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}…
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.
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.
“IndexedDB is the best non-blocking database a developer could desire”, said nobody ever, and the reason is simple:
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.
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"}
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.
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.
I’ve created a GitHub discussions repository, which is better than a forum, to hopefully simplify bootstrapping a tiny community around my projects.
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…
TL;DR If you care about raw performance, hooks are likely the wrong abstraction, but if you care about DX, hooks are simply a wonderful, and fast enough, solution.
This post would like to summarize, on a high level, my “Good, Bad and Ugly” thoughts around this topic.
Few days ago there was a Hacker News discussion about reinventing the programming mental model, to make it easier for humans to express their intent, and I believe hooks are something close to this idea.
Mostly suitable for UI tasks, easily adaptable for IoT projects, or anywhere there is a runtime that never…
Web, Mobile, IoT, and all JS things since 00's. Formerly JS engineer at @nokia, @facebook, @twitter.