DEV Community: Bart de Goede

Running RAG with a (small) language model in the browser

Bart de Goede — Tue, 13 Oct 2026 03:45:00 +0000

A few weeks ago MicroLLM lab was featured in Hacker Newsletter. It shows off how you can run small language models (25 to 360 million parameters) in a browser on the users' own GPU (or CPU)¹. No server, no API key, no account. Pretty nifty, so it got me thinking about the steps after semantic search I added to this blog: that already provides the "R" in RAG² for a question, and it does that entirely in the browser, from a 4 MB lookup table. What if a tiny model, also in the browser, read those passages and answered the question?

So I built that: "ask my blog"³. Search finds the four most relevant passages, and a small language model running in your browser summarises them in two sentences. Nothing you type leaves your machine. And because "a small model summarizes things" is exactly the sort of sentence that hides a lot of made-up nonsense, I measured how often it's actually faithful to what I wrote. Turns out small models have some limitations.

How it works

The page is retrieval-augmented generation (RAG) with every piece running client-side:

Retrieve. Your question goes through the same static-embedding search as the homepage, but instead of rolling results up to posts, it keeps the four best-scoring passages.
Gate. If the best passage scores below a threshold, the model isn't called at all and the page says it couldn't find this on the blog. The idea is to not bother if a user asks something there's no data for. More on why that only half works below.
Prompt. The passages, numbered, plus a system prompt: answer in at most two sentences, use only these passages, say so if they don't answer the question.
Generate. A Web Worker runs the model with transformers.js on WebGPU, or on the CPU via WebAssembly if your browser doesn't have WebGPU, and streams the answer into the page. It stops as soon as it has two complete sentences.

The passages are shown first, as cards, and the summary will sit above them. You can search without loading a model at all; you just get the passages. Loading one is an explicit click, because it means downloading a few hundred megabytes from Hugging Face (once; your browser caches it). There's also a button to clear the cache/

Which model?

I wanted something that would be a reasonable click for a reader: a few hundred megabytes, not gigabytes (what if someone reads this on the bus). The candidates that have browser-ready (ONNX) builds were SmolLM2 (135M and 360M parameters), Gemma 3 270M, LFM2.5-350M, Qwen2.5-0.5B and Qwen3-0.6B. For comparison I added two references that would never ship on the page: Gemma 4 E2B, the smallest of Google's new Gemma 4 models at a 3.1 GB download, and Claude Haiku 5.5 through the API, the "just pay someone" option.

One surprise before anything ran: for several of these models the "4-bit" (q4) build is bigger than the 4-bit-with-16-bit-floats (q4f16) one, because the q4 export keeps the embedding table in full 32-bit precision. SmolLM2-360M is 390 MB as q4 and 275 MB as q4f16, with identical output. Everything below uses q4f16.

The eval

I reused the 30 questions from the eval I did for the semantic search post, rephrased as actual questions ("How did the blog use Lunr to add search?"), and added 15 questions this blog definitely doesn't answer. A few of those are far off ("How do I bake sourdough bread at home?"), but most are near-misses designed to tempt a model into predicting plausible-sounding-but-wrong-tokens: "Which GPU should I buy to run Llama 70B locally?", "How does BM25 ranking improve on TF-IDF?", "How do I fine-tune Kokoro to speak in my own voice?" The blog talks about these, or similar things, but doesn't have and answer for those.

Every model got the same four passages and the same prompt, and Opus 5.5 graded each answer against those passages as faithful (every claim is in the passages), unsupported (at least one claim isn't, even if it happens to be true) or a non-answer. I labelled 20 of those grades myself without seeing the judge's verdict; we agreed on 16 of 20 about whether an answer was faithful⁴. Claude also generated the question set, which I reviewed.

Turns out nothing off the shelf under 350 MB is usable for this. They aren't slightly worse; they're faithful at most three times out of thirty, and they'll happily answer almost any question you throw at them. Asked which GPU to buy for Llama 70B, with four passages about embeddings and a coding agent on a MacBook:

"...the best option to run Llama 70B locally is likely to be a NVIDIA GTX 960 or GTX 970. [...] They also offer high memory bandwidth, making them ideal for handling large amounts of data such as the 6.4 million documents required by Llama 70B." (SmolLM2-360M)

"...a high-performance graphics card (GPU) such as a NVIDIA A100 series (e.g., RTX 3090, RTX 3080, 3070, 3080, 3070M, 3080M)" (Gemma 3 270M)

"...popular options include RTX 3090, RTR 5900, or newer generations like TensorRT 60+ for improved compute efficiency." (LFM2.5-350M)

Gemma 4 E2B, for the record, correctly decided that "The provided passages do not contain information about which GPU you should buy to run Llama 70B locally." Good job Google.

Even on questions the blog does answer, the small models are prone to garble things. Here's LFM2.5 on the most basic question about my Bloom filter post, at 73 tokens per second on my laptop's GPU:

Fast, fluent, and wrong. A Bloom filter isn't a hash table: it's a bit array, and an element counts as "probably in the set" only if every one of its k hash functions lands on a bit that's set. The last clause is actually correct (a missing bit means the element was never added, which is why Bloom filters can't give false negatives), but the rest is made up. To be fair to the model, search didn't hand it the section that explains how Bloom filters work; the four passages it got were about use cases and the interactive demo. A summary can only be as good as the passages it reads. Seems like there's some work to do on the relevance scoring in my little search engine that could.

Qwen3-0.6B is the interesting one. At 579 MB it's pretty thicc, and over the budget I'd set myself. It's faithful half the time, which is basically a coin flip. However, it's the smallest model that's a coin flip rather than a pretty much guaranteed miss, so that's what "ask my blog" loads by default. You can also choose three smaller models so you can see for yourself what a non-finetuned 300 MB model does with your question⁵.

Small models loop

The first time I ran the small models, most of their answers weren't wrong so much as stuck. SmolLM2-135M, asked how to add OpenSearch support to a website:

"1. Custom Search: Search from your URL bar 2. Search from your URL bar 3. Search from your URL bar 4. Search from your URL bar [1] Custom Search: Search from your URL bar..."

Gemma 3 270M answered the GPU question with I'5555555555555555555555... until it ran out of tokens. That's what happens when you always pick the single most likely next token and nothing discourages repeating it: tiny models fall into a groove and can't get out (I saw it happen pretty often when I was playing around with MicroLLMLab too). The easy fix is a repetition penalty (1.15 in this case, which slightly discourages tokens the model has already seen). It doesn't fix the faithfulness or quality; the models just write longer, more varied nonsense instead. All the numbers above are with the penalty set to 1.15.

A relevance gate to catch the obvious ones

A relevance gate seemed like the cheap fix for made-up answers: if search can't find anything relevant, don't ask the model. It works for the far-off questions; "How do I bake sourdough bread?" scores 0.25 against the best passage on the blog, and a threshold of 0.45 stops it (which is good, because Gemma 3's answer was a bread recipe). But the near-misses score 0.54 to 0.63, higher than several questions the blog actually answers, because they land on posts about the same topic. To block those, the threshold would have to reject 13 of the 30 real questions too.

So the gate only catches the obviously off-topic questions, and the rest is on the model. That's the real reason size matters here: Gemma 4 and Haiku say "the passages don't cover this", and the small models never do.

Is it worth renting a GPU, or paying for an API?

Usually, yes. At current pricing (yay competition) it's almost never worth it, unless you have strong reasons not to (ie compliance, privacy, air gapped deployments, etc). As a thought exercise tho: the 3.1 GB Gemma 4 E2B matches Haiku on quality, so what would it cost to run it for readers instead of making them download it? The cheapest sensible cloud GPU for it, an NVIDIA L4 on Google Cloud, is about $0.71 an hour⁶, or $516 a month to keep running. For the amount of readers this blog sees in a month, assuming each and everyone asks a question, that would be over a dollar per question.

Haiku on the other hand answered all 45 eval questions for $0.006. At 500 questions a month (a guy can dream) it would cost about seven cents. In other words, if you have a real use case, start with Haiku⁷.

Shorter is safer

If two sentences from Qwen3 are only right half the time, would letting it say more help? I ran a quick experiment with Qwen3-0.6B and Gemma 4 E2B, allowing for two, four or six sentences.

Both get less faithful with more room, but the smaller model falls off a cliff: Qwen3 goes from 15 to 9 to 5 faithful answers out of 30. Every extra sentence is another chance to hallucinate. At six sentences it stops declining the GPU question altogether and helpfully summarises every passage instead, before concluding that "the answer would depend on whether the user needs a high-performance GPU or a standard one."

Gemma 4 slips too (28, 26, 24), but it barely uses the extra room (about 2.8 sentences when allowed 6) and never makes up an answer to a question the blog doesn't cover. Shoutout to Gemma 4 btw, this model family is pretty awesome. This is a great option for finetuning.

What's next

The next step would be making the small models less bad at this one job. A 300 MB model doesn't need to know everything; it needs to read four passages and either summarise them or say they don't answer the question. That sounds like a fine-tuning problem, and maybe a follow-up post.

The other idea is the homepage search box: if you've already loaded a model on "ask my blog", the homepage could quietly use it to improve search, without ever downloading anything on its own. In the meantime: ask my blog something, and check the passages before you believe the summary.

It was in turn inspired by petitgpt. I didn't reuse any MicroLLM lab code (the repository doesn't say what license it's under); the page here is built on transformers.js directly. ↩
Retrieval-augmented generation. The TLDR is that you use a search tool or engine to find the appropriate context for a LLM to do its inference. It's like how Claude Code greps through your code, or when ChatGPT searches the web. Is this overkill for the couple of posts I have? Absolutely. Fun tho. ↩
Naming things is the hardest thing in computer science amirite. ↩
Most of the remaining disagreement was about which kind of bad an answer was (I'd call rambling nonsense a non-answer; the judge calls it unsupported if it contains a single invented claim). On the faithful-or-not question the judge was stricter than I was twice, and more lenient twice. The gap between the small models and the rest is far bigger than that noise. ↩
Two of them only on WebGPU; see the CPU caveats further down. ↩
A g2-standard-4 instance (one L4) in us-central1, on demand, via computeprices.com on 12 October 2026. ↩
Don't be like Chipotle tho and let just anyone rack up your inference bill; more so, if you have a static site, please, don't put your Anthropic/OpenAI API key in there. ↩

Model2vec is a nifty way to distill embedding models to such a size you could use them for semantic search on a static website :-)

Bart de Goede — Tue, 14 Jul 2026 01:06:48 +0000

Bart de Goede

Jul 14

Client-side semantic search for your static site

#rag #ai

13 min read

Client-side semantic search for your static site

Bart de Goede — Tue, 14 Jul 2026 01:04:15 +0000

Eight years ago I added client-side search to this blog with Lunr.js. It creates an inverted index at build time, ships it as JSON, and matches strings in your browser. No server-side engine required. It has worked fine ever since, in the sense that it finds a post if you type a word that is actually in it.

Earlier this year I wrote a semantic search engine in ±250 lines of Python (the kind that lets you find the "London Beer Flood" when you search for "alcoholic beverage disaster in England," because it understands that beer is alcoholic and a flood is a disaster). That one needs a machine with sentence-transformers installed and a few hundred megabytes of PyTorch; to serve something like that in a production server requires beefy machines with expensive RAM. Not something you run in a browser tab.

So this blog had keyword search that runs anywhere and understands nothing, but no semantic search that understands things but can't run anywhere near a static site. This post is about closing that gap: semantic search that runs entirely in your browser, with no server and no API, where the entire model is essentially a 4 MB lookup table. You can try all three of the models I benchmarked, further down, running live on your own hardware (I can't afford GPU clusters).

Doing this surfaced a couple things, chief among which that the keyword search had a bug for a couple of years. TUrns out that doing proper evals is important.

The obvious approach costs 23 megabytes

The models that power the Python post (sentence-transformers like all-MiniLM-L6-v2) can, in fact, run in a browser. Transformers.js will download an ONNX build of one and run it on WebAssembly. I benchmarked it, and on my laptop, the quantized model plus its runtime is 23.45 MB over the wire, takes about two seconds to load and become available, and then embeds a query in ±18 ms.

Twenty-three megabytes is a bit rich to embed a search box query, for a blog that has 14 posts. That is roughly a dozen high-resolution photos worth of bytes to download so we can have fancy search. It works, and for some applications it is completely worth it, but it is not something I want to inflict on someone who clicked through to read about bloom filters, especially not on a mobile connection.

The thing is, you do not need a transformer to embed a search query. You need a vector that's good enough, and there is a much cheaper way to get one.

A static embedding model is a lookup table

The trick is a family of models called model2vec (the specific ones are named "potion"). They are distilled from a real sentence-transformer, but the result is not a neural network. It is a table.

Here is the model's entire forward pass. Not a simplification — the whole thing, from the library's source:

ids = tokenize(text)          # split into subword token ids
rows = embedding[ids]         # look up one vector per token
vector = rows.mean(axis=0)    # average them
vector = vector / norm(vector)  # normalise to unit length

That is it. Tokenize, look up a row per token, average, normalize. There is no attention, no layers, no inference. "Running the model" is a handful of array lookups and an average. For potion-base-8M, the table is 29,528 tokens by 256 dimensions of float32 (about 30 MB) and it reaches 81% of MiniLM's retrieval quality while being, definitionally, a dictionary lookup.

Thirty megabytes is still too much, but a table is a much friendlier thing to shrink than a transformer.

Building the index: chunking, and a cache that never earns its keep

Embeddings are generated at build time. On my laptop, whenever I run hugo, a Python script walks through the posts, strips out the front matter and the code blocks, splits each post into overlapping 600-character-ish chunks, embeds every chunk, and writes the vectors to a file the browser downloads when a user clicks the search input box.

The chunking matters more than I expected, because of that averaging step. A static embedding is the mean of its token vectors, and if you average an entire 15,000-character post into one vector, you get something that points at "generic English prose about software" and not much else. The rare, distinctive words (terms like pydub or mmh3) get drowned out by the hundreds of ordinary words around them. Chopping the post into smaller chunks helps keep those signals sharp. I'll come back to this, because it turns out to be the key to why some models beat others.

I also built an embedding cache, keyed on a hash of each chunk's text, so that re-embedding only touches chunks that changed. This turned out to be a waste of time and tokens. Embedding every chunk of this blog is a few hundred lookups and an average; it takes about ten milliseconds. I built a cache to speed up an operation that is already pretty instantaneous (turns out 14 blog posts is not a lot of data). It would matter more for the MiniLM model, where embedding is a real neural network forward pass, but I'm not shipping that one. So the cache sits there, correct and pointless, and I've left it in as a reminder that overengineering is easy.

Shrinking the table: the model's stopword list is hiding in plain sight

The table is 30 MB because it is float32. Quantizing it to int8 makes it a quarter of the size. The catch is that you cannot just clip everything to the same scale, and understanding why was one of my favorite things I learned building this.

Look at what the row magnitudes actually are. If you sort every token in potion-base-8M by the length of its vector, the shortest vectors (i.e. the ones closest to zero) are:

a  .  ,  -  )  the  to  and  of  in

And the longest are:

turkmenistan  seychelles  guantanamo  hemingway  vanuatu

This is not a coincidence and it isn't noise either. The model's stopword list is its row magnitudes. When you average token vectors together, a word with a tiny vector barely moves the result, and a word with a big vector dominates it. The model has learned, with no stopword list and no special-casing, that a word like "the" should contribute almost nothing and a word like "guantanamo" should contribute a lot. It's kinda beautiful, and it's sitting right there in the geometry.

Which is why quantization needs a per row scale: each token gets its own float32 multiplier, so that the relative magnitudes survive being crushed into int8. However, turns out that it didn't matter much anyway.

I measured it; I quantized the real table with a single global scale and checked how much it actually degraded the query vectors. The answer was: almost nothing. Aggregate cosine similarity against the original stayed at 0.9998. A global scale zeroes out exactly two rows in the entire 29,528-token vocabulary (. and a) which are precisely the two tokens the model had already decided contribute pretty much nothing. The mechanism is real; it just doesn't matter for this particular model.

I kept the per-row scales anyway, because they cost 118 KB out of 4 MB and they're correct, but more like "cheap insurance" than "load-bearing". The whole int8 table, per-row scales and all, reproduces the original float32 model to a cosine of 0.999958. Good enough to ship a lookup table in the browser rather than a model.

WordPiece in eighty lines, and its three gotchas

The browser has the token table, but it still has to turn your typed query into token ids the same way we did in Python, so we can look up the right rows. That means reimplementing the BERT WordPiece tokenizer in JavaScript. It's about eighty lines, and it has three gotchas that could each silently poison query vector:

No [CLS]/[SEP]. BERT tokenizers normally wrap your text in special marker tokens. The tokenizer.json config even has a section describing how. model2vec doesn't use it, but calls the tokenizer with add_special_tokens=False instead. Add the markers and you're averaging in two vectors that shouldn't be there.
Unknown tokens are deleted, not embedded. If a word isn't in the vocabulary, model2vec drops it from the sequence entirely rather than substituting an [UNK] vector. So a query made entirely of gibberish produces an empty token list and a zero vector, and you have to handle that instead of dividing by zero. (In practice this is nearly unreachable; with a 29,528-token vocabulary, every single character is in the vocabulary, so the only way to trigger it is a word longer than 100 characters.)
"strip_accents": null means accents are stripped. This one is a little nasty. The config says strip_accents is null, which reads like "off." But in HuggingFace's tokenizer library, a null value inherits from the lowercase setting, which is on. So café becomes cafe. If we'd copy the config literally, every accented query drifts.

Some frustrations and a bunch of Claude generated test strings ( pydub, café naïve, C++ vs C#, 日本語のみ) later, I'm reasonably confident the JS tokenizer matches the BERT WordPiece tokenizer.

Search is a few hundred dot products

With the query embedded, search is almost anticlimactic. There are a few hundred chunk vectors (one per chunk of every post). Computing the cosine similarity against all of them is a few hundred dot products of 128 numbers each, tens of thousands of multiply-adds, which a browser on a reasonably modern machine does in a fraction of a millisecond. Then we group the chunks by post, take each post's best-scoring chunk, and sort. On my machine (M1 MacBook Air) the entire query (tokenize, embed, score every chunk, rank) takes about 0.4 milliseconds.

In a production setting, this is where you reach for approximate-nearest-neighbour indexes (HNSW and friends), and if you have a bazillion documents you should. With a few hundred, an ANN index would be slower than the brute-force loop and much larger on disk. It's worth saying out loud because "vector search" in this case isn't a complex database system,but just a for loop.

There's one wrinkle worth knowing if you build one of these. The document vectors are stored as int8. Cosine similarity is invariant to a positive scale, and the document matrix uses one global scale, so the browser can dot a float32 query straight against the raw int8 bytes and get the right ranking without ever un-quantizing them. But int8 × int8 in JavaScript overflows silently; a dot product whose true value is three million comes back as -64, no error, no warning. So it's better to accumulate into a regular float. I mention it because this was a fun one to debug¹.

Two search engines that are each blind in a different way

Before adding semantic search, I figured I'd do the responsible thing and measured how bad the existing keyword search actually was, so I'd have a baseline to beat. I had Claude create a set of thirty test queries and split them into three kinds:

Exact tokens: pydub, lunr, mmh3, papermod. Words that literally appear in a post.
Paraphrases: "find documents by what they mean instead of which words they contain." Concepts, in different words than the post uses.
Navigational: "how do I add search to a static site." Broad intent.

Keyword search would surely ace the exact tokens and fail the paraphrases. Then I ran it, and it failed pydub.

pydub is a Python library I've used in a previous post. The word is right there in the text-to-speech post. And Fuse.js, the fuzzy-search library this blog uses, returned nothing. It turned out my configuration told Fuse to only score matches near the start of a field; a setting called location, with a distance window of 1000 characters. pydub first appears about 3,700 characters into that post, well outside the window, so as far as my search box was concerned it did not exist. The same was true for mmh3, and for any distinctive word that happened to appear deep in a long post. The words that did work only worked because they were in a title.

My keyword search had been quietly broken for years, and I only found out because I was about to benchmark against it. Derp.

And the two engines turn out to be blind in exactly complementary ways:

	keyword finds it	semantic finds it
`pydub` (exact token, out of vocabulary)	✅	❌
"find documents by what they mean" (paraphrase)	❌	✅

Keyword search is perfect on the exact tokens and returns literally nothing for all ten paraphrases; not bad results, just zero results. Semantic search is the mirror image: it nails the paraphrases and stumbles on the proper nouns, because pydub isn't in its vocabulary and gets shattered into meaningless subword fragments. Neither is better. They fail on disjoint sets.

Reciprocal Rank Fusion, or: how to merge different search result sets

If each engine catches what the other misses, you want both. The problem is combining them. Keyword search returns a fuzzy-match distance; vector search returns a cosine similarity. These live on different scales that mean different things, and averaging them is meaningless; it'd be like adding a temperature to a weight.

The answer here is Reciprocal Rank Fusion. Run queries against both indices, throw away the scores entirely and keep only the ranks. Each document's "fused score" is the sum, over both engines, of 1 / (k + rank), with k conventionally 60. A document ranked first by one engine and unranked by the other scores 1/61. A document ranked third by both scores 1/63 + 1/63, which is larger. The k flattens the top of the curve so that "both engines quite liked this" beats "one engine loved it", which is exactly what you want when one engine is blind to paraphrase and the other to proper nouns. It's about ten lines of code, it has a single parameter with a sensible default, and it never has to compare the two incomparable scores. When you search this blog now, that's what runs: keyword and semantic, fused by rank. This is easily extensible to many sources of ranked lists.

The benchmark: it'll have to run on your hardware

I benchmarked three query encoders: the model2vec lookup table I've been describing, MiniLM q8 through transformers.js, and ternlight, a clever BitNet-style ternary model compiled to WebAssembly that originally sent me down this whole path.

On my website there is an interactive benchmark that'll download different query encoders and run embeddings if applicable on our device. I've included my benchmarks below, and a GIF of it running, but definitely check it out for yourself!

Query encoder	Over the wire	Embed a query*	Retrieval quality†
potion (model2vec lookup) — what I shipped	4.21 MB	~0.3 ms	on par with MiniLM
MiniLM q8 (transformers.js)	23.45 MB	~8 ms	baseline
ternlight base (BitNet-style ternary, WASM)	7.17 MB	between the two	—

*Timings are from my laptop; the live widget measures them on your device. †Recall@1 over 30 labeled queries.

⚡ These three run live in your browser, on your own hardware. I've included the static table above for your reference; you can see a 4 MB lookup table keep pace with a 23 MB transformer on your machine on my website. Run the interactive benchmark →

On my laptop the story is pretty clear: the lookup table is 4.2 MB and embeds a query in a third of a millisecond; MiniLM is 23.5 MB and 18 milliseconds; ternlight sits in between. And in retrieval quality, measured over those thirty labeled queries, the lookup table scores just as well as MiniLM. Just as well. At a fifth of the size and roughly fifty times the speed.

Caveat on that claim, though; thirty queries is a small sample and I nearly fooled myself with it. Twice.

The metric couldn't see anything

Initially, the headline metric was recall@3: did a relevant post make the top three? On a thirteen-post corpus, "top three of thirteen" is not a very high bar (random guessing clears it about a quarter of the time) and it turned out that almost every model cleared it on almost every query. Five different configurations tied at exactly 0.978. Recall@3 could not tell a 4 MB lookup table apart from a 23 MB transformer.

Worse, it produced confident nonsense. Pure semantic search scored a perfect 1.000 on the exact-token queries; it apparently found pydub every time. Except it didn't:

pydub  →  1. Free SSL on GitHub Pages       (wrong)
          2. Let's Encrypt on GitHub Pages   (wrong)
          3. Text-to-Speech with pydub       (correct)

The right post is third, behind two completely unrelated ones, and recall@3 scored that as a hit. The metric was rewarding the model for landing the right answer in a bucket wide enough that landing it there meant almost nothing. Switching to recall@1 ("is the first result correct?") separated the models more cleanly and told a different story. Lesson learned: a metric is worthless if the metric can't see the thing you care about. I only caught it because the results looked too good.

What shipped, and how to steal it

The search box on the homepage now runs keyword, semantic, and hybrid search, with a toggle so you can compare and watch them disagree. Type pydub and flip to semantic mode to see it get the answer wrong; flip to hybrid to see it get it right again. The whole thing is a 4 MB lookup table, a tiny document index, and about 300 lines of dependency-free JavaScript, lazy-loaded only when you focus the search box so the page itself pays nothing.

The build pipeline (the chunking, the quantization, the eval harness, all of it) is a Python package you can point at your own site:

pip install static-site-search-eval
sss-eval build --corpus content/post --outdir static/search \
  --model minishlab/potion-base-8M --dims 128 --chunk-size 600

The code is on GitHub, the thirty eval queries are in there too so you can try it out for yourself. If you run the benchmark above on a phone over cellular, you'll likely feel the 23 MB, and understand why the lookup table was worth the trouble.

All time classic https://www.destroyallsoftware.com/talks/wat ↩