DEV Community: J Lopes

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.