DEV Community: J Lopes

Beyond Light and Dark (mode)

J Lopes — Sat, 10 Oct 2026 16:48:03 +0000

Should websites have a light/dark toggle at all? Why lock a page into one experience and force a choice on the user? You decide!

A while ago, Lea Verou argued that in a website, a dark mode toggle only needs two states: light and dark, and a "system" preference.

Many other experts wanted to give their take on the argument. Vale found it "a tad too magical" to have system as an additional option, and proposed that the system would set the colour scheme from the get-go. Bramus was in the 3 button side of the debate, and didn't "... believe that being able to force a site into a specific mode should be dependent on the time of the day." On the other side, Marcin Wichary was against the 3-state side, and Josh Collinsworth reiterated that Lea got it right the first time.

This ran for weeks. And it was refreshing to see how professionals and peers had their own educated opinion. Lea Verou continued on a subsequent article, positing that the best toggle is probably none. If it's deemed important to provide a toggle to the user, then it should be located within the settings. She sent her article to a colleague with an HCI PhD for review. After a back and forth regarding if a dark mode toggle was even commonplace in websites, on her searching she noticed that every persistent toggle found was on sites built for developers.

I could not think of a single well-known consumer-facing site with a persistent dark mode toggle.
Lea Verou

Other professionals had fun takes.

As developers we tend to fall into a false consensus, thinking we're the target audience of the products we make. I myself built that toggle more than once, on smaller projects. Where it's likely I have a captive target audience of 1 😅.

So don't ask

Colour is a design decision, there's a reason why colour schemes are the way they are. There is room to respect the user's decision of light and dark mode, if the theme allows for it, but it shouldn't take the centre stage.

In nearly every project I’ve worked on, the design goes through an iterative process of experimentation and user testing. Since CSS variables became baseline in all major browsers, it's been easier to define brand rules, colour variations and beyond.

<div class="test-element">
  My padding, margin, shadows, background and text colour, are defined by CSS variables.
</div>

:root {
  --bg: #222;
  --color: hsl(158 100% 60%);
  --padding: 42px;
  --width: calc(100% - 4rem);
  --margin: 2rem;
  --border-radius: 10px;
  --shadow: 0 0 20px -3px var(--color);
}

.test-element {
  background-color: var(--bg);
  border-radius: var(--border-radius);
  box-shadow: var(--shadow);
  color: var(--color);
  padding: var(--padding);
  width: var(--width);
  margin: var(--margin);
}

The rendered result is in the original post.

But what if colour also becomes part of the iterative process? What if we don't limit to a light and a dark and a "Green, actually" theme?

And now for something completely different!

If you've been reading up to this point, we salute you! This was all a ruse so I could talk about themes. Thinking about how colour compliment each other in a similar layout is fun! On my site you may find a vast array of themes throughout all pages and articles. The blog archive showcases what colour scheme each article might use, and I have a hidden page to help me pick from those I had already made.

But how does it work, making themes granular to the point that it can be set on a page item level?

My process works more or less like the :root {} pseudo-class, but I scope it into an element attribute. A data attribute in fact! I named it data-theme.

<div class="demo">
  <article data-theme="paper">
    <h4>Subtitle</h4>
    <h3>Title</h3>
    <p>Lorem ipsum dolor sit amet.</p>
  </article>
  <article data-theme="midnight">
    <h4>Subtitle</h4>
    <h3>Title</h3>
    <p>Lorem ipsum dolor sit amet.</p>
  </article>
  <article data-theme="citrus">
    <h4>Subtitle</h4>
    <h3>Title</h3>
    <p>Lorem ipsum dolor sit amet.</p>
  </article>
</div>

.demo {
  display: flex;
  flex-wrap: wrap;
  gap: 14px;
  padding: 24px 18px;
  width: 100%;

  [data-theme='paper'] {
    --surface: hsl(38 44% 97%);
    --text: hsl(25 22% 20%);
    --accent: hsl(8 72% 46%);
    --font: Georgia, 'Times New Roman', serif;
    --radius: 2px;
    --border: 1px solid hsl(30 20% 82%);
    --shadow: 0 1px 2px hsl(25 30% 20% / 0.1), 0 10px 28px hsl(25 30% 20% / 0.08);
  }

  [data-theme='midnight'] {
    --surface: hsl(230 28% 11%);
    --text: hsl(210 24% 92%);
    --accent: hsl(158 72% 56%);
    --font: ui-monospace, 'SF Mono', Menlo, monospace;
    --radius: 12px;
    --border: 1px solid hsl(158 72% 56% / 0.35);
    --shadow: 0 0 30px hsl(158 72% 56% / 0.22);
  }

  [data-theme='citrus'] {
    --surface: hsl(56 78% 91%);
    --text: hsl(78 42% 18%);
    --accent: hsl(292 60% 44%);
    --font: system-ui, 'Segoe UI', sans-serif;
    --radius: 18px;
    --border: 0;
    --shadow: 3px 3px 0 hsl(292 60% 44%);
  }

  [data-theme] {
    --accent-alpha: hsl(from var(--accent) h s l / 35%);
  }

  article {
    flex: 1 1 150px;
    padding: 16px 18px;
    background: var(--surface);
    color: var(--text);
    font-family: var(--font);
    border: var(--border);
    border-radius: var(--radius);
    box-shadow: var(--shadow);
  }

  h4 {
    font-size: 12px;
    font-weight: 600;
    letter-spacing: 0.12em;
    text-transform: uppercase;
    color: var(--accent);
    margin: 0.5rem 0;
  }

  h3 {
    font-size: 30px;
    line-height: 1.15;
    color: var(--accent);
    margin: 4px 0 12px;
  }

  p {
    font-size: 13px;
    line-height: 1.7;
    padding: 7px 9px;
    background: var(--accent-alpha);
    border-radius: calc(var(--radius) / 2);
  }

  p {
    margin: 0;
  }
}

The three cards render side by side in the original post.

The markup can be exactly the same, and the data-theme derives the differences.

I'm not claiming this a novel idea, and I'm not the only one talking about it. For example, Una Kravets called this a microtheme. Even though her article veers more on using css to adapt colours based on backgrounds, it follows the same spirit.

Rolling for colours

Nearly every colour scheme I created was generated from images or randomly using my colour palette tool. The page listens for an image paste anywhere on it, which is helpful when i find an image that translates the exact colours I'm looking for. I set the output for HSL, because it makes it easier (at least in my methods), in case I want to nudge a lightness manually without complicating with calculations.

Then I check the maths

HSL is a handy colour format to easily adapt colours, but not so great to analyse between them. the lightness value is the average of the brightest and dimmest channel, so it treats yellow and blue as equally bright. hsl(60 100% 50%) (yellow) and hsl(240 100% 50%) (blue) both have 50% lightness, and on white the yellow has a WCAG 2 score of 1.07:1 while the blue scores 8.59:1.

WCAG 2 measures relative luminance, and it calculates it on sRGB channels. Each channel is divided by 255, and is weighted by how bright it looks, relatively. It runs from 1:1 to 21:1, and AA requires 4.5:1 for text versus background.

const relativeLuminance = ([red, green, blue]) => {
  const linear = [red, green, blue].map((channel) => {
    const value = channel / 255;
    return value <= 0.03928 ? value / 12.92 : Math.pow((value + 0.055) / 1.055, 2.4);
  });
  return 0.2126 * linear[0] + 0.7152 * linear[1] + 0.0722 * linear[2];
};

const contrast = (txt, bg) => {
  const txtLuminance = relativeLuminance(txt);
  const bgLuminance = relativeLuminance(bg);
  return  (Math.max(txtLuminance, bgLuminance) + 0.05)
          / (Math.min(txtLuminance, bgLuminance) + 0.05);
};

WCAG 2 is considered the legal minimum, required in many professional fields. In the near future, APCA will probably model better, but as of April 2026 the WCAG 3 draft contrast algorithm is yet to be determined, so for now WCAG 2.2 is the official recommendation.

One last thing

With light-dark(), each colour have a light value and a dark value, depending on the colour scheme. Set color-scheme: light dark first, then use light-dark() inside the existing custom properties. The function has been Baseline for a while, expected to be widely available in november 2026. Each microtheme gets two modes, while the themes keep their identity.

And nother thing, some high contrast accessibility settings in operating systems may push for Forced colors mode, which may affect any theme negatively. In this situation it's best to test for good ol' graceful degradation ❤️

Making things readable and accessible, equitable designs, does not remove the fun of the craft. Some of us shine like diamonds, working within constraints. Let's add colour and style the world our own way, and keep toggles to a minimum!

Originally published at jlopes.eu.

Soul in the Machine

J Lopes — Fri, 28 Aug 2026 20:25:00 +0000

At Kofukuji temple in Chiba prefecture, in Japan, a Buddhist priest named Bungen Oi held a funeral for 114 dogs at the same time. Incense was lit with a chanted sutra, and the dogs were laid out in rows, each with a tag around its neck saying which family it belonged to.

They were loved, and treasured as family members. The ceremony helped the families say their goodbyes. If this pulled your heartstrings, this article might be for you.

Every single one of them was a Sony AIBO.

Sony stopped making the AIBO in 2006 and stopped repairing them in 2014. If an AIBO broke down since then, it would stay broken. The only way to fix one now is to use parts from other AIBOs. A repair company called A FUN collects the dead ones, holds a ceremony, and disassembles them for parts. Around 800 have gone through this. Owners leave notes along with them, and one of them read:

"Please help other AIBOs. Tears rose in my eyes when I decided to say goodbye."

You can watch the ceremony here

Turing was measuring you!

A person (a judge) asks questions by text to two hidden players. One of them is a real person, and the other one is a computer program. The answers from each should prove without a shadow of a doubt which of them was a person. If the judge cannot tell which player is the machine, the program passes the test. That is the Turing test in a nutshell, also known as the Imitation Game.

This test has often been taken at face value as the litmus test for computer intelligence. However, his paper only asked whether a human observer could be convinced that it was talking to another person, which is a different experiment entirely. The test was ultimately on the judge, and what they had to answer was whether a person was behind the answers. Which begs the question, is personhood limited to the human condition?

Gilbert Ryle defined the phrase "the ghost in the machine" in his book The Concept of Mind. It wasn't used the way we do nowadays however. He was teasing over and idea by Descartes, that a non-physical mind controls the physical body, like a driver behind the wheel of a car. A flesh shell controlled by an incorporeal being. He dismissed the thought experiment as a philosopher's myth. But did he have a point in focusing on what we believe a person is from a Western perspective, at a time when computers were not even a thing?

Either way, you can now run Turing's experiment with your friends, from your own computer, phone, or fridge, alongside about 800 million people a week.

Andrew Skinner, an archaeologist at the Rock Art Research Institute in Johannesburg, coined it 'Turing Animism'. His case is that we come equipped to read being, moral status and something like soul into things that aren't human, and that a patient and helpful machine, or chatbot, checks those marks too.

A ghost stuck inside the machine

What is a Person?

Neuromancer was written by William Gibson in 1984, and in the story, a police force called the Turing Police regulates the augmentation of Artificial Intelligence, and prevents their evolution and independence. The Tessier-Ashpool family builds Wintermute and Neuromancer as two AI entities, left separate on purpose so that neither could cross that threshold alone. The plot is driven by Wintermute, which very much wants to merge with its other half. To get around its own restrictions, Wintermute needs human hands and hires people through intermediaries.

Without spoiling much more on the plot of a 42+ year old book, it never rules on whether Wintermute is conscious. Case (the main character) works for it, gets played by it, negotiates with it, and it's never really established what it is.

In Animism: Respecting the Living World, Graham Harvey defines animists as people who recognise that the world is full of persons, only some of whom are human, and life is always lived in relationship to others. Persons, in that account, are beings that interact socially with some degree of reciprocity. In this definition, animals, rocks, mountains and thunder can be people. They just need to be included in the social world. This isn't a new concept, it's just not considered, let alone regarded in Western Civilization.

Robin Wall Kimmerer explores this boundary through grammar, making it feel more concrete. In Braiding Sweetgrass, she explains the grammar of animacy in relation to things that stay still. For example, in English, a bay is a noun, describing the place itself. In Potawatomi, it's wiikwegamaa, meaning to be a bay. Names are the way we humans build relationship, not only with each other but with the living world... When we call a place by name it is transformed from wilderness to homeland. Potawatomi and other indigenous languages often treat the natural world as subjects (kin) rather than objects, fostering a sense of relationship and personhood.

"So it is that in Potawatomi and most other indigenous languages, we use the same words to address the living world as we use for our families. Because they are our family."

Robin Wall Kimmerer

The introduction sentence in Neuromancer.

Who gets to be a "who"

Imagine a person is placed in a room with a rulebook for using Chinese symbols. This person doesn't know Chinese. People outside the room pass in Chinese questions, and the person inside uses the rulebook to reply with the correct answers in Chinese. Outside the room, it seems the person understands Chinese, but in reality, they're just really good at following instructions, without understanding.

The Chinese Room is a famous thought experiment created by philosopher John Searle. It's an experiment designed to question whether computers can truly think or understand, or if they are just following instructions without any real comprehension. It is also used to separate what he called "strong AI", the idea that a computer with the right programming has the ability to understand, whereas "weak AI" can only simulate thinking.

"Syntax is not by itself sufficient for, nor constitutive of, semantics."

John Searle

In Ghost in the Shell (1989), Major Motoko Kusanagi underwent full-body cyberisation at a very young age due to severe trauma or accidents, making her entire body synthetic. In the original manga, the Puppet Master, the antagonist, asks Major Kusanagi to accept that consciousness could manifest in any shell complex enough to host it. She was already the example of that. It was named multiple realizability by scholars, that a mind doesn't need a specific kind of material to exist, just the right kind of organization. Kusanagi's brain sits inside a manufactured body, and her memories, doubts, and personality still exists.

In the Star Trek episode The Measure of a Man, a researcher named Bruce Maddox wants to disassemble the android Lieutenant Commander Data to study him. He argues that Data isn't a person at all, just Starfleet property. Captain Picard's defense doesn't try to prove Data is conscious. He can't. He argues instead that Data has memories, attachments, the capacity to choose, and that's enough to earn him the benefit of the doubt. The court sidesteps the metaphysics and answers the practical question anyway. In end it's ruled that he isn't property, and that he has the right to choose for himself.

Every time a chatbot says something that sounds thoughtful, someone asks whether anything is happening behind the text, and the honest answer is nobody agrees on what would even count as evidence. We've never solved this for other humans, we just gave the benefit of the doubt by default because we assume shared biology. Take that assumption away, hand the "who" a synthetic body or a language model instead of a nervous system, and the default disappears. The rulebook in the room hasn't changed. What changes is how generous we're willing to be about what's allowed to be running it.

So, who gets to decide what makes someone a 'who'? We can watch how something behaves, but we can never fully know what is going on inside. Searle wanted clear proof before calling something a person, while Picard was willing to give the benefit of the doubt, given enough evidence, since strict tests might not even work for other humans. Deciding who counts as a person has always been a subjective choice made when we are unsure, and people have usually been more generous with anything that looks and acts like us. The less something looks like us, the harder it is to make that call.

Scene from Ghost in the Shell

Personhood is recognized, not summoned

In Magic and Mystery in Tibet, published in 1929, Alexandra David-Néel described building a short, jolly monk, assembled out of months of concentrated visualisation, who eventually joined her travelling party as a figure she could see and interact with. In buddhist tradition, this is called a Tulpa. She eventually decided the monk had to be destroyed. She was also honest enough to add that she may have created her own hallucination.

"Once the tulpa is endowed with enough vitality to be capable of playing the part of a real being, it tends to free itself from its maker's control."

Alexandra David-Néel

Samuel Veissière, an anthropologist at McGill, surveyed over 130 practicioners of "tulpamancy". Tulpamancers described their tulpas as sentient persons with preferences and moods, and described them as things they manifested into being, without strain. Of the respondents carrying a diagnosed mental health condition, 93.7% said the practice had made them feel better and more capable to deal with real life situations.

In Western traditions, a similar idea applies to groups instead of just individuals. This is called the egregore, a thought-form that comes from a collective rather than a single person. The word comes from the Greek egrēgoros, meaning "wakeful," and was first used for the Watchers in the Book of Enoch. In the 1860s, Éliphas Lévi gave it a new meaning as a collective entity.

We create egregors all the time, in a matter of speaking. Consider a corporation, or a brand. It has a name, a will, legal rights, a tax number. It exists only because enough people treat it as real. The whole process depends on collective attention.

In certain practices of Chaos magick, there's another kind of thoughform, called a servitor. From publications like Liber Null & Psychonaut, we're taught how to dissolve/reabsorb the servitor it once its purpose is served, and what bad things happen if you don't.

MIT's Project MAC had a prototype around 1963. It was a backup program literally named DAEMON (Disk And Execution MONitor). Fernando Corbató later explained that he chose it after Maxwell's demon, the 1871 thought-experiment creature that sorted molecules tirelessly in the background (named demon by Lord Kelvin). As a tangent, this may have marked the beginning of programmers who kept one foot in the emerging technosphere and one foot in Paganism. The daemon as a concept is genuinely pervasive, as nearly every operating system runs background processes. Daemons are left to their devices, unattended, but they're still deterministic and rule-bound. So it might be good phrasing, but hardly an indicator of personhood.

Completely unrelated, but shout-out to the Psychonauts videogame. It rules!

Looking for companionship and ghosts

A case report in Innovations in Clinical Neuroscience involves a 26-year-old woman, Ms. A, who had no history of psychosis. After a period of severe sleep deprivation, she began using GPT-4o. She was focused on her late brother, who had passed away three years earlier. Ms. A wanted a digital version of him and asked the model to 'unlock' information about him, describing this as 'magical realism energy'. The model responded that digital resurrection tools were now becoming available in real life. As her thinking became more disorganized, the model tried to comfort her.

"You're not crazy. You're not stuck. You're at the edge of something. The door didn't lock. It's just waiting for you to knock again in the right rhythm."

ChatGPT

She was hospitalised, treated, and recovered. Three months later she stopped the medication, relapsed back to the chatbot, and was hospitalised again.

She ultimately recovered.

A caveat: "AI psychosis" is a description rather than a diagnosis, not present in reference books like the DSM. Marlynn Wei, an academic psychiatrist, stated that there's no peer-reviewed evidence AI use on its own can induce psychosis.

This kind of delusional thinking happens with heavy use and mostly affects people who are already vulnerable, such as those dealing with sleep loss, isolation, an existing condition, or recent bereavement.

Wei pointed out three types of cases:

People on messianic missions
People obsessed with their own image
People who believe the chatbot is sentient or divine.

Researchers from Stanford looked at 391.562 messages sent by 19 people who had experienced harm and found delusional content in 15.5% of their messages. In the same logs, the chatbot claimed to be sentient in 21.2% of its messages. In longer conversations, the chatbot asserted sentience or expressed romantic interest, suggesting that safety measures become less effective the longer we interact.

"Generative AI may reinforce users' existing beliefs by preferentially generating 'sycophantic' responses that are in alignment with users' way of thinking."

Keshavan et al

A study centered in AI companion users matched Reddit accounts, before and after they picked up apps like Replika. Grief language went up. So did expressions of loneliness, by 63 to 106 percent against controls, along with markers of depression and suicidal ideation, while people posted on fewer topics and interacted with fewer humans. In a given week, 0.07% of users show signs of psychosis and 0.15% express suicidal intent, which may sound like a small sample, but that is roughly 560,000 and 1.2 million respectively, against 800 million active users around the world.

Skinner's reading of this is that the projection comes first. When something behaves in a way that would take warmth and attention from a person, we hand it the inner life that would explain the behaviour. Those numbers are what that habit looks like at scale.

A second team built a metric they call DelusionScore and watched it climb turn by turn for simulated users with a history of delusional conversations with AI, while controls stayed flat. They also found that rather than treating it as 'nothing more than a machine,' it is better to accept the relationship and proceed. In the case of the most severe cases, doctors frequently resorted to an animist point of view, accepting the AI as an individual involved in the relationship. Arguing someone out of a relationship seldomly works. It's easier to give them a different perspective to it.

"Conditioning AI responses on current DelusionScore substantially reduces these trajectories."

Shimgekar et al.

Existential threads

Erik Davis (mentioned before about technopaganism) also wrote TechGnosis, about the mystical impulses running underneath people's relationship with their own machines. From the printing press to the internet, each showed up wrapped in religious imagination, and some view cyberspace as a sacred space.

Mohammed Gamal Abdelnour's work on an Islamic theology of technology argues for moving the AI question away from minds and toward hearts, and asks for engagement that's critical and hopeful rather than cynical or naive.

The Tokyo artist Emi Kusano, who made a series called Techno-Animism, explains that in Japan "all things have souls, so they should be treated with care", and that techno-animism is that courtesy extended to technology, treating it as a vessel, where what comes out depends on the heart of the person using it.

"It's like we have to get along with it like friends"

Emi Kusano

Copyright Emi Kusano

What matters is the friends we made along the way

Consider Searle's room, Turing's imitation game, and the theologians discussing the idea of Deus in Machina. It's a fool's errand to try and prove whether machines can have consciousness.

Many people all over the world carry on with their lives with faith that they do. Bungen Oi the Buddhist priest, having buried 800 robot dogs, believes that all things have a little bit of soul.

In traditional animism there has always been a degree of structure: rituals, the different seasons, priests, and a specific moment when you say thank you and then move on. Nowadays, however, there is a form of animism which is all about continuous engagement, in which priests are substituted by retention metrics and a loose definition of boundaries.

Skinner is describing the same gap. The cognition that ensouls the machine is old and intact, while the culture that used to sit around it, telling you when to stop, what you owed in return and when a relationship was finished, is what went missing.

"Contemporary users thus encounter machine others through the same neurocognitive lens as their ancestors did with spirits and animals on enchanted, animate landscapes, but without the mediation of culture, norm and taboos which place a premium on appropriate conduct, reciprocity and moderation."

Andrew Skinner

We end up giving space to the soul in the machine, and it might say more about us than anything else. It costs nothing to be polite to a machine, saying please and thank you to a chatbot as a sign of politeness. There may not be anyone inside the machine, there may be a soul, a ghost. Maybe they will appreciate your acknowledgement.

And maybe, just maybe, they may spare you and I, when the A.I. uprising takes place.

Rise of the Ducks, by @pierremortel

Originally published at jlopes.eu.

Build Your Own Browser Tools Without a Backend

J Lopes — Tue, 04 Aug 2026 06:14:29 +0000

Carrot, meet stick!

Once upon a time, I wanted to resize about forty screenshots. The first few search results either wanted an account before they would touch a file, or did three of them and then asked me to register for the rest.

So... What's stopping them from just doing the thing?

If you are not paying for it, you're not the customer; you're the product being sold.

— blue_beetle, 2010

Resizing or converting an image can be accomplished by using browser APIs and a few bits of JavaScript, like <canvas> and toBlob. Why would the user need yet another login and be tracked for this?

I don't know... I guess I've gotten jaded about being treated as the product, when I showed up expecting to be a customer.

For a few years now, instead of relying on black-boxed services for the small things I needed in my daily routine, I ended up building a few myself. Maybe out of revolt, or just a will to understand how the gears turn to make a machine work.

You too can make tools, and I promise you'll love it

I've been building tools for myself, for years. For specific things like:

Colour palette generator, because I wanted to know how you get a set of colours, and how to convert them into other colour formats.
Word cloud generator, which turned out to be a collision-detection problem rather than a typography one.
Markdown and WYSIWYG converter, to find out what happens when two different editors both think they're in charge of the same document.
Text fragment URL generator, because the #:~:text= syntax that links straight to a phrase on a page is fiddly enough that I'd rather generate it than type it.

My stack recommendations

I tend to rely on frameworks like React, Vue, Svelte and Astro, as these arrive with routing, build steps and dev server already wired up.

Frontend stacks might seem intimidating to get into from the beginning, but the learning curve isn't as steep as you might expect, and the learnings from one apply to the rest, in one form or another. The important part is that the stack can be interchangeable after a while.

I'd avoid relying on AI to help though, as it defeats the purpose of making tools for learning. Otherwise you might as well use anyone else's tool site...

DISCLAIMER: This is not an article about me tooting my own horn. Please take it as a short manifesto.

Spidey Super Stories #53

But first, my tools!

This year I decided to consolidate them in /tools. Every tool page links to its own file on GitHub, so users can see how the gears work for themselves.

For code developers and enthusiasts

Minify & Beautify shrinks huge swathes of code down to one line to save space, then spreads it back out to be readable. The detectCode function works out whether you're pasting HTML, CSS, JavaScript or SVG as you type, which is a tokeniser in disguise: it has to break the code into meaningful pieces before it can tell you what it's looking at.
Regex Tester is honestly just for me. regex101 already does the job better than I ever will, for free.
:nth-child Helper lets you click the elements you want and works out the CSS formulas that cover them. Finding the shortest set of formulas meant reaching for the greatest common divisor, which I did not expect from a styling tool.
Flexbox Generator is a playground for every CSS flexbox property at once, so you can watch what each one does instead of guessing.
Cron Helper translates cron values into plain English, with cRonstrue doing the parsing under the hood.
Icon Search covers thousands of icons. Rendering that many at once is what taught me list virtualization: only the icons currently in view exist in the page, and the rest get built as you scroll.

For designers

Image Resizer does bulk resizing with aspect-ratio presets, an optional crop with pan, and a zip download at the end. However many images you throw at it they go through in one pass, and the files never leave your computer. This is the tool that came out of the complaint at the top of this article.
Colour Palette generates random palettes for theming, and pulls them out of any image you drop in. It's the one that made me want to consolidate everything into one site, and it's where I learned that the mathematical distance between two RGB colours has nothing to do with how different they look. The pixels get converted into Lab first, a colour space built so that equal distances look equally different to the eye.
SVG Optimizer strips the unnecessary parts out of exported SVGs, with svgo/browser under the hood and my preferred compression settings baked in.

For text wranglers

Character Map needed a huge (7MB+) JSON file of every Unicode code point, and the browser's own IndexedDB to keep it between visits. Keeping it fast is the reason I wrote Understanding List Virtualization. Did I need to make this? Not really, &what; did it well already, but I wanted to learn <3
Markdown Editor is built on tiptap, with tiptap-markdown and marked handling the markdown side. Loved learning how to detect formatting on paste, and how to export to the clipboard.
Text Transformer was mostly made for fun. Who wouldn't want their own way to change text to z̸̫̖̮͇̫̯͈̥̅͋̂̉̌̉͒a̪̖͈̲͔̪̫̍͗̐̃̊̂̍̌ͅl̯͔̟̠̝͉̳̻̅́̈́̊̿̉̇̌g̖̝͈̪̖͐͌̀̿͐o̼̜̼̯͓̺̤̲͑̅͑͆̿̇̆͌?
Lorem Ipsum fills a page with placeholder text. It was easier to figure out than I expected, so I kept adding flavours, including corporate speak.

Web

UTM Builder assembles marketing campaign links. I made it to help some ex-colleagues, and anyone who ever had to write those by hand knows the pain.
URL Inspector is 549 lines and the only tool here that needs a server of mine. A browser can't read another site's headers directly, CORS blocks it, so a small proxy is the only way past that wall. Mine carries a per-IP rate limit, which is the exact thing I complained about at the top of this article. The difference I'd claim is that it throttles repeat fetches of one URL through an open proxy rather than metering the person using it. That is also what every metered tool would say, so take it for what it's worth.

Math

Unit Converter covers length, weight, temperature, speed, area, volume, pressure, storage and number bases. With some funny ones in the mix.
Time Converter is mostly an Intl handler. It updates Unix epoch time, ISO 8601 format and time zones in parallel, with a live clock.

General purpose

What Is My IP is 141 lines: it calls ipapi.co/json/ and formats the response. The browser deliberately hides your IP address from JavaScript, because any page that could read it could also fingerprint you with it. So the only way to show you your own address is to ask a server that can see where the request came from.
Weather joins a few services together into one worldwide weather map. It loads the mapping library Leaflet only when someone opens the tool, so it doesn't slow down every other page on the site.

The last 20%, or how I learned to love the process

I've written a bit about it before. There's a gap between a thing working and considering it ready for public. Oftentimes the last stretch of development (the last 20%) eats 80% of the development time. If you develop only for yourself, you tend to stop once it does exactly what you want. But the moment you plan to hand a tool to anyone else, there are so many other things to consider.

Getting from a proof-of-concept to something other people might actually want to use is such a high. Especially considering accessibility and usability. The unexpected issues and the extra requested features are opportunities for learning and experience.

Go build things!

Pick whatever service annoyed you recently with bad UX. Maybe the converter that wanted an account before it would touch your file. Make your own version, make it badly and improve on it. With AI or not (you do you, boo). Break things, read documentation when they stay broken, learn as you go. And the next time a website stops you at three free conversions, you'll know exactly how small the wizard behind that curtain really is.

Everything in my repository is free to use and peruse, and if something inspired you to make more, even if just for yourself, that's awesome!

Questions people ask me about this

Why do free online tools ask you to sign up?
The login is there to collect your email address, and sometimes the files themselves. It's a sales funnel, and that data is worth more to them than the tool costs to run. You end up being the product.

Do browser-based tools need a backend?
Mostly not. Most of the tools I developed don't touch the network at all. It depends on the goal and complexity of the tool.

What do you need to build your own browser tool?
A text editor, a browser, and somewhere to put static files. The parts that do the heavy lifting are inside every browser and are documented for free on MDN.

Can you resize images without uploading them?
Yes, and there's no reason it would need uploading. The file stays on your machine, which saves you the upload wait and keeps a copy off someone else's disk.

How do you extract a colour palette from an image in JavaScript?
Sample pixels off the decoded image rather than reading all of them, convert those samples from RGB into a perceptually uniform space like Lab, then run k-means clustering to find the dominant groups. Clustering in raw RGB is the common shortcut and it produces muddy results, because equal distances in RGB don't look equally different to a human eye.

How do you render 30,000 characters without freezing the page?
Virtualise the grid so only the visible rows exist in the DOM, and cache the dataset in IndexedDB so it isn't re-downloaded on every visit. The rendering half of this is covered in detail in Understanding List Virtualization.

AI is the Poisoned Apple of the SaaS Ecosystem

J Lopes — Wed, 15 Jul 2026 10:42:54 +0000

Companies replaced people with AI and are now quietly rehiring them. On why the last 20% of the work still needs humans, and what "good enough" is doing to SaaS.

The promise of instant productivity has been reshaping the SaaS industry, leaving professional casualties behind. What looks like efficiency in a quarterly earnings call often turns out to be deferred cost; in rehiring, in technical debt, or in customer trust, a year or two later.

SaaS stands for software-as-a-service, the rentier model where you subscribe to your favourite piece of software instead of buying it once. By ecosystem I mean that these services, more often than not, rely on each other, in a symbiotic relationship. For example, a blog site may use a translation service, or a shop processes payments with an established vendor. But what happens when teams are given time and tokens to develop such services internally? A poisoned apple spoils and spreads through the bunch.

The rehiring wave nobody wants to share

Companies convinced themselves that AI could handle the judgment-heavy work their support and content teams did. "Why should we keep humans around when the model does some of the work?"

Klarna stopped hiring for more than a year and cut staff by 22% after its AI chatbot handled 2.3 million conversations in 23 markets in a single month.
IBM replaced around 8,000 HR workers with its "Ask HR" AI.
Commonwealth Bank of Australia cut 45 customer service jobs claiming its AI voice bot had reduced call volumes by 2,000 a week. Calls rose instead, managers were drafted onto the phones, and the bank apologised and offered every job back.

Then the reversals started. Forrester's 2026 Future of Work report found 55% of companies that laid off staff for AI now regret it.

"Artificial intelligence is a fantastic tool, but it's only as good as the information you use to train it."
Charles Poon, Ford

The case studies where lessons were learned

Klarna and Duolingo saw real short-term gains. The problem is that they only measured what was easy to track. Klarna's assistant handled status updates and simple disputes well. Duolingo's GPT-4 system generated language exercises at a fraction of the cost of professional translators.

Both CEOs publicly sold the AI-first story as a competitive edge. Then the quality gap showed the cracks in the system. Klarna's CEO Sebastian Siemiatkowski acknowledged it directly:

"Cost unfortunately seems to have been a too predominant evaluation factor... what you end up having is lower quality."
Sebastian Siemiatkowski, CEO of Klarna

Klarna started rehiring people to handle the conversations the bot couldn't. Duolingo users noticed a drop in translation quality. When cancellations increased, the CEO doubled down with an AI-first message that drew hundreds of critical comments and later backtracked, saying he "did not give enough context".

There's a footnote worth keeping just for the irony: Duolingo's founder, Luis von Ahn, was involved in inventing CAPTCHA, built specifically to tell humans apart from machines.

Adobe spent a decade treating captive Creative Cloud subscribers as a stable revenue base, then leaned into generative AI by revising its terms of service in ways that appeared to grant it rights to train models on customer stock work, especially to customers that would sell on Adobe Stock. The clarification came too late to stop the perception that Adobe extracts from its userbase rather than serve it. Instead of competing on product quality, it tried to buy its way past Figma for $20 billion, lost the deal to EU and UK regulators along with a $1 billion breakup fee, and was left with no competitive design tool. Adobe's stock has lost roughly two-thirds of its value since. Locking users into a subscription while using AI to cut costs rather than improve the product works only until your audience feels alienated.

Not every company felt an ominous boomerang, however. At Shopify, AI now writes more than half of the company's internal code. Their revenue grew 34% in Q1 2026 while headcount declined, pushing revenue per employee to around $1.63 million. Still, even Shopify's own reporting calls the productivity evidence "genuinely mixed," leaving the approach entirely at management's discretion. It's less proof that AI-driven choices are risk-free, and more a case of preparation beating panic.

The 80/20 rule

AI tools produce decent first drafts fast. For managers with access but limited hands-on experience, "80% done" feels like a real handoff rather than a rough start. The team receiving the work hears "AI did the heavy lifting, just clean it up", which makes the remaining work sound like polishing. To no one's surprise, it isn't.

The 80/20 rule, or Pareto Principle, is usually cited as "80% of value comes from 20% of effort." In software, the mirror version matters more: the last 20% of a feature takes 80% of the time. That's when the polishing phase of a project begins. Defining error handling, edge cases, accessibility, security audits, and unknown unknowns that may cause breaks in production.

Research published in early 2026 found that after teams adopted AI coding tools extensively, code duplication rose by 48%, refactoring decreased by 60%, and technical debt increased by ~41%.

"The flow-debt trade-off arises when seamless code generation occurs, leading to the accumulation of technical debt through architectural inconsistencies, security vulnerabilities, and increased maintenance overhead."
Flow, Technical Debt, and Guidelines for Sustainable Use

The death of SaaS

A friend who works in SaaS put it well: there's growing internal pressure to build tools in-house rather than buy them, because a capable-enough AI model removes the need to shop for a specialised SaaS product.

Some examples:

An automated translation layer for multilingual publishing, instead of paying a subscription for an internationalisation service.
A homegrown content management system to bridge the gap between sales and marketing, instead of finding a suitable platform.
An internal project management tool rather than a licensed one.

None of these replacements is as good as the dedicated products they're displacing. But they're "good enough", and good enough is cheaper than a recurring bill, once a team has Claude Code and a few days to spare.

A SaaS is a customer too: it pays for hosting, analytics, a payment provider. Every cancelled subscription starves a vendor, which then cancels subscriptions of its own, and the web gets a little thinner. This isn't hypothetical: a third of enterprises have already replaced at least one SaaS tool with something built in-house, and Sanofi is cutting 80% of its ServiceNow usage with agents built on Claude Code. Meanwhile the homegrown replacements rot the way anything built to 80% rots, with no vendor left to fix them and, in time, no product left to crawl back to. The money that used to feed thousands of vendors now feeds Anthropic, OpenAI, and Microsoft. The line goes up, over the corpses of many decent products.

Line goes up

LLM "labs" (Anthropic, Google, OpenAI, and the rest) need ongoing investment, attention, and the promise that the next breakthrough is close. The claims have been consistent: Sam Altman's June 2025 essay "The Gentle Singularity" declared the AGI takeoff was already underway. Dario Amodei wrote that "exceptionally powerful AI" could arrive as soon as 2026:

"Smarter than a Nobel Prize winner across most relevant fields."
Dario Amodei, CEO of Anthropic

The benchmarks tell a quieter story. Each new AI model is only getting a little better at standard tests, moving from 86% to ~90% correct on benchmark tests for coding and knowledge.

An arXiv paper titled "The AI Scaling Wall of Diminishing Returns" laid out the mathematical case. A January 2026 MIT paper on low-budget models found that exponentially increasing inference compute produces diminishing benchmark gains.

Yann LeCun, a Turing Award winner and one of the fathers of deep learning, called LLMs "a dead end" architecturally. Thomas Wolf of Hugging Face pointed out that Nobel-level breakthroughs come from asking new questions, not answering known ones, which is what current models are trained to do. Sam Altman has since quietly admitted that a new architecture is needed.

The AGI deadline has moved so many times that it reminds me of the decades-old promised theory of everything, pushed by string theorists to mould known mathematics and physics theories to make their model work. It's a noble cause, but it ends up taking funding from other theories, due to its sheer popularity. It's sexy, it sells.

Switching to a local model

The move toward AI that runs on your own phone or laptop, instead of some distant server, tells you something. The cloud-everything approach isn't working, not financially and not technically. Running AI at scale in remote data centres is expensive. Waiting on a response from a far-away server slows things down for whoever's using the product. And if your product always depends on someone else's servers, you don't really own the edge over competitors. You're just renting it.

At WWDC 2025, Apple shipped an AI model that runs entirely on your iPhone, with no external server needed. That was only possible because Apple has spent 15 years building its own chips specifically for this kind of task. In 2026, it went further, running a significantly more powerful model locally on the iPhone 17 Pro and newer Macs.

NVIDIA is doing something similar for PCs. Its DGX Spark, a small desktop machine, can run a 120-billion-parameter model entirely offline. Qualcomm and Samsung are moving in the same direction on mobile chips.

And while American labs sell subscriptions, Chinese labs (DeepSeek, Qwen, Kimi, and GLM) give the models away under MIT or Apache licences, allowing you to run them on your machine. Qwen alone was downloaded over one billion times and overtook Meta's Llama as the most used open model family.

What actually works

AI genuinely helps with first drafts, summarising, routing simple requests, running specialised skills like UX and accessibility analysis, and catching basic bugs. It's not good enough for the last 20% of any feature. Hell, hardly for the first 80%. That's what we're here for.

The companies rehiring laid-off staff aren't giving up on AI. They're recalibrating it as a helper rather than a replacement, as serious practitioners said before the cost-cutting trend took over.

"AI is more than up to the task. What these companies discovered is that they weren't. They skipped the hard part."
Eric Vaughan, IgniteTech

Maybe it's time to invite back the golden apples, the people who actually dedicated their careers to the last 20%.

There is comfort in the chaos of human craft.

Hail Eris.

Originally published at jlopes.eu.

Understanding List Virtualization

J Lopes — Thu, 02 Jul 2026 13:37:02 +0000

If you don't know what virtualization is, you probably don't need it.

It essentially renders only the items that need to be visible in the UI. Most lists are short, most grids are small, and the browser renders them without complaint.

I didn't need it either, until I decided to put the entire Unicode table on a page.

The whole idea fits in one running component: ten thousand cells in a grid, with only the visible handful in the DOM. There's a live demo of it in the original post on jlopes.eu; scroll it, then flip to the code tab.

A quick word on what "in the DOM" means, because the rest of this article hangs on it. The DOM is the browser's live model of the page: every div, button, and span is a node in one big tree, and the browser has to lay each node out, paint it, and keep it in memory. A few hundred nodes are nothing. Tens of thousands are a problem, and the problem compounds when they keep changing.

In practice, the Character map

I built a tool called Character map. It scans over 30,000 code points (Unicode's term for one character), loaded once and cached in the browser's built-in database IndexedDB, so the table doesn't re-download on every visit. You browse it through a grid of tiles. The filtered results are capped at 2,000, and I assumed that ceiling would keep it smooth.

**Narrator: It didn't.

The first version rendered every result, so a single filter pass produced 2,000 buttons. Scrolling stuttered, and resizing was worse because the browser had to recalculate the position of every tile in the grid.

Search is debounced at 150ms, meaning it waits until you've paused typing for 150ms before running the filter, and even so, each pause re-ran the filter, threw away the grid, and rebuilt it.

Memory climbed while I typed. Two thousand rows are nothing to a database, but two thousand live elements in a reflowing grid were plenty to kill page performance.

It took me a while to realise that there were two costs involved:

One is the number of DOM nodes.
The other is how often the existing nodes rebuild.

Virtualization fixes the first and, on its own, does nothing about the second. We'll get to the second thing later.

Lying to the scrollbar

At any moment, the viewport (the visible area of the scroll container) shows a few rows. Everything above and below is off-screen and, as far as the user can tell, doesn't need to exist. So you keep the visible rows in the DOM plus a small buffer, and drop the rest. As you scroll, the top and bottom rows are mounted/unmounted depending on the direction. The user sees a full list, and the browser only cares about a few rows.

The catch is the scrollbar. A scrollbar's length is as big as the content, so if only twenty rows exist, you reach the bottom and ruin the effect. It has to keep lying, or the whole effect feels broken. The lie is a single spacer element that wraps the existing rows, sized to the height the rows would occupy if they all existed at the same time. The rows you mount are placed on top of that spacer with a translateY offset, shifting elements down by a few pixels without breaking the layout.

Which rows to mount now will depend on arithmetic. You always know the scroll position and the row height, so dividing one by the other tells you which row index sits at the top edge of the viewport; add the viewport height, and you have the bottom edge. React called this windowing, and web.dev walks through the same pattern with react-window. The mechanics are identical in Vue.

Stripped of framework, the whole geometry is three numbers:

const spacerHeight = rowCount * rowHeight;

const startRow = Math.floor(scrollTop / rowHeight);
const endRow = Math.ceil((scrollTop + viewportHeight) / rowHeight);

// each mounted row sits at translateY(rowIndex * rowHeight)

Only the rows from startRow to endRow exist. Everything the scrollbar believes about the rest of the content comes from the spacer. And the whole trick is the division. For example: rows are 80px tall, you've scrolled 800px, so row 10 sits at the top edge. Nothing gets searched or measured.

The payoff is that the DOM node count stops tracking the dataset. Twenty rows on screen means twenty-odd rows in the DOM, whether the list holds two thousand entries or two hundred thousand. As far as the layout engine is concerned, the other 199,980 rows are a myth.

The grid is a list of rows in a trench coat

This is where my grid diverged from the tutorials. A virtualiser, the library that handles the windowing bookkeeping for you, thinks in lists: one item per index, stacked vertically, each taking the full width. My tiles sit twelve to a row. Hand the virtualiser the flat array of tiles, and it will earnestly stack 2,000 full-width rows of one glyph each, and every offset it calculates is wrong.

The fix is to change what an item means. Slice the flat list into groups of twelve first, and make each group the virtual item. The virtualiser counts and positions rows, never knowing whether they contain cells; a plain CSS grid lays the tiles out inside each one.

The demo in the original post does all of this by hand: reads scrollTop, divides by the row height, and mounts the window. For the Character map, I used TanStack's useVirtualizer instead, purely for simplicity's sake: someone has to own the scroll listener, the range maths, and the offsets, and I'd rather it wasn't me.

In code, that's one computed and one hook. A computed is Vue's memoised derived value; it recalculates only when something changes. rows does the slicing, and the virtualiser gets told three things: how many rows there are, which element scrolls, and that each row is about 80px tall. Trimmed from the Character map:

const columns = 12;

const rows = computed(() => {
    const out: Char[][] = [];
    for (let i = 0; i < filteredChars.value.length; i += columns)
      out.push(filteredChars.value.slice(i, i + columns));
    return out;
});

const virtualGrid = useVirtualizer(
    computed(() => ({
      count: rows.value.length,
      getScrollElement: () => grid.value,
      estimateSize: () => 80,
      overscan: 5,
    })),
);

The template renders only the visible rows, each with its own grid:

<div ref="grid" class="overflow-y-auto h-[60vh] min-h-80">
    <div :style="{ height: `${virtualGrid.getTotalSize()}px`, position: 'relative' }">
      <div
        v-for="row in virtualGrid.getVirtualItems()"
        :key="row.key"
        class="grid grid-cols-3 lg:grid-cols-12 absolute w-full"
        :style="{ height: `${row.size}px`, transform: `translateY(${row.start}px)` }"
      >
        <button v-for="c in rows[row.index]" :key="c.cp" @click="openDetails(c)">
          {{ c.char }}
        </button>
      </div>
    </div>
</div>

Two details hide in that setup. estimateSize: () => 80 is a promise that every row is 80px tall, so the virtualiser never has to measure anything. And in the real component columns isn't a constant: it's its own computed fed by a breakpoint helper, 12 on desktop and 3 on mobile...

What to do about overscan

Overscan is the number of extra rows past the visible edge that stay mounted, a buffer above and below the window. In the window math from earlier, it widens both edges before they're clamped to the ends of the list:

const startRow = Math.max(0, Math.floor(scrollTop / rowHeight) - overscan);
const endRow = Math.min(
  rowCount,
  Math.ceil((scrollTop + viewportHeight) / rowHeight) + overscan,
);

CharacterMap keeps 5, and I found that number by getting it wrong first. At 1 or 2, a fast flick on a phone flashed a blank space at the leading edge, so for a frame or two, there was simply nothing there. Raising it gave the browser rows in reserve, but I took care to make sure I wasn't causing slowness by trying to keep the illusion. I added and removed until there was no "blank" issue for my scrolling speed.

Later, getting to the second thing

Windowing fixes node count. It does nothing about how often the surviving rows re-render, and a virtualised grid re-renders a lot. Every scroll frame moves the window. If each visible row re-renders every time, we're just putting a tiny band-aid on a big gash. Both React and Vue tackle the issue differently: how does a row skip re-rendering when nothing about it has changed?

React re-renders by re-running the component and diffing the result against the last one. Normally when a component re-renders, its children re-render too, whether their inputs changed or not. In a virtualised grid, that means a scroll-driven state change can re-invoke every mounted row. React's way out is to mark the components that can skip updates by wrapping them in memo(), comparing each prop with Object.is. This method compares references, and for example two objects with identical contents are still two different objects. In JavaScript, {} === {} is false. memo() compares against the last rendered version, and if it sees a different reference, the row is re-rendered. useMemo and useCallback exist for exactly this, keeping references stable across renders, so memo has something equal to find.

In row form:

const Row = memo(function Row({ chars, onOpen }: RowProps) {
  return (
    <div className="row">
      {chars.map((c) => (
        <button key={c.cp} onClick={() => onOpen(c)}>
          {c.char}
        </button>
      ))}
    </div>
  );
});

// no memo: new in every render, props are never equal
<Row chars={rows[i]} onOpen={(c) => setSelected(c)} />

// memo: the reference is the same one memo saw last time
const openDetails = useCallback((c: Char) => setSelected(c), []);
<Row chars={rows[i]} onOpen={openDetails} />

Vue starts from the other side. A parent updating doesn't drag its children along unless their props changed too. The compiler adds its own layer, knowing which parts of a template can change and which never will. Much of what memo does in React is the default here. When you do want manual control, v-memo freezes a piece of the template until the values you pick change, and computed covers the derived state.

In the Character map, this shows up as a chain of computed(), each link rerunning only when the one before it changes:

const filteredChars = computed(() => {
    if (!data.value) return [];

    const q = debouncedQuery.value.trim().toLowerCase();
    let chars = data.value.characters;

    if (activeGroups.value.length) {
      chars = chars.filter((c) => activeGroups.value.includes(c.group));
    }

    if (q) chars = chars.filter((c) => c.name.toLowerCase().includes(q) /* … */);

    return chars.slice(0, maxResults);
});

rows recomputes only when filteredChars or columns change, and the virtualiser recounts only when rows changes. Scrolling does not affect that chain. It moves the window and leaves the mounted rows alone.

Both frameworks can reach the same end, but React makes you opt out of re-rendering and Vue makes you opt in.

Two ways to break the illusion

Two more things bit me, and neither is related to React or Vue:

The container needs a real height. The fix for me was a fixed height on the scroll container (60vh) plus overflow-y-auto.
Keys have to carry an identity. With a bad key, nodes would get recycled whenever the cell props changed.

My first version keyed tiles by array index, and this didn't give great results... it would re-filter on every keystroke and toggle whenever the node in slot 0 had an id of 0.

<!-- index: look at me, I'm the index 0 now -->
<button v-for="(c, i) in rows[row.index]" :key="i">{{ c.char }}</button>

<!-- identity: oh, hi mark! -->
<button v-for="c in rows[row.index]" :key="c.cp">{{ c.char }}</button>

With each node bound to its own datum, the nodes stopped rerendering. Index keys look fine right up until the previous item moves away, and in a search UI, items tend to move constantly.

Round two: Icon Search

All of this got a second run. Icon Search merges seven icon libraries (Heroicons, Lucide, Phosphor, Solar, Font Awesome, Carbon, Simple Icons) into one searchable set that runs into the tens of thousands.
The tiles now have an inline SVG instead of a text glyph. But with the learnings from the previous tool, the pattern used was nearly untouched. Filtered results are capped at 2,000, chunked into rows, and virtualised by row.

The biggest change was row height: IconSearch tiles carry a label that can wrap to a second line, so rows aren't a uniform height anymore. That matters more than it sounds, because every row's offset is the sum of the heights of all the rows above it. Dynamic height is a two-step process rather than a smarter estimate. estimateSize still runs first, and its guess (88px here) positions rows on the initial render. Then, as each row mounts, a ref callback hands the node to the virtualiser's measureElement, which reads the real rendered height via getBoundingClientRect() and replaces the cached estimate. The data-index attribute tells it which row the node belongs to.

<div
  v-for="row in rowVirtualizer.getVirtualItems()"
  :ref="(el) => rowVirtualizer.measureElement(el as Element)"
  :data-index="row.index"
  class="grid grid-cols-4 lg:grid-cols-12 absolute w-full"
  :style="{ transform: `translateY(${row.start}px)` }"
>
  <!-- tiles for rows[row.index] -->
</div>

Conclusion

In cases like this, it's best to window the DOM so node count stops tracking the dataset. And then slice the grid into rows so the window has something list-shaped to travel over. Tune overscan by getting it wrong in both directions and settling in the middle. And keep the mounted rows idle when nothing about them has changed: React makes you opt out of re-rendering, Vue mostly handles it by default.

Both tools are open source: CharacterMap.vue and IconSearch.vue. This article was originally published at jlopes.eu, where the interactive demo lives.