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, it can store blobs (not everywhere) and buffers (bingo!) …

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 we write something like…

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.

// not a hook until wrapped
const callback = (initial) => {
  const [value, update] = useState(initial);
  console.log(value); …

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 built for production, go from ~1K to max ~10K combined, and yet that’s not even nearly enough to convince developers, apparently looking for smaller libraries, to adopt or try these out. …

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.

The Good

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 sleeps, it’s indeed very hard to find other patterns that reason as well with developers…

When there is even a linting rule to enforce a pattern, it usually means that pattern has indeed some issue, so lets see why return await ... is bad.

When to use await

The await keyword can be used either if the top level context is asynchronous, or if the current executing function is.

The peculiarity of await is that it works with any kind of returned value, even primitives.

(async () => {
  // we can await any value or callback
  const regular = () => 'regular';  // but we don't need to await returned promises
  const promise = () => Promise.resolve('promise');  // we also should use `async` *only*
  // if we need to `await` something
  const asynchronous = async () => {
    await regular();
    // we don't need to await promise()
    // we can return *just* promise()
    return promise()…

This is a quick one about a little trick I’ve recently used to ship simplemaps.com’s World Cities Database basic data through my latest geo2city npm package, and as SQLite database.

There are few things that made me ship 690K zip archive instead of 2.3MB database or, once zipped, 1.1MB, but while the current saving doesn’t look too relevant, the same technique made me create a 3MB zip database instead of 280MB file, using a different source of data (check version 0.2, if curious).

Create optimized tables

As obvious as it sounds, most distributed SQLite databases usually just ship a big table with all fields in it, either because these were imported right away from .csv …

After being revolutionary in 2007 to unleash CSS selectors that never existed, the specification moved from v1.0 to the current, recommended, v3.1, but browsers stopped with v1.0 … and we’re missing out!

XPath vs CSS

The fundamental difference between these two standards is that one was born to crawl and analyze the DOM tree in all “axes”, while the other one job is to live-style the DOM, without any way to crawl its content.

That’s it: XPath is a searching tool while CSS is a real-time “drawing” tool, hence rich in functionalities to style, but poor in terms of DOM tree analysis.

What XPath can do that CSS cannot

Here an example: even if the CSS :has(...) selector is part of the most recent specifications, no browser has implemented it to date, while in XPath…