DEV Community: Andy Yk

How I Rendered 10 Million Banknotes Without Killing the Browser

Andy Yk — Thu, 03 Sep 2026 09:22:31 +0000

I wanted to build a small thing. One page. It answers a question a child could ask: how big is a billion dollars, physically, if you printed it all in $100 bills and put it somewhere.

I thought it would take a weekend. It did not.

The question is simple. The answer is simple too, actually. One billion dollars is 10 million $100 bills. They weigh 10 tonnes and cover about 103,000 square metres laid flat. Two divisions and two multiplications. Done.

But "here is a number" is boring. I wanted people to feel the size. And the moment you try to make a number feel physical, you stop building a calculator and start building four different things at once. This is the story of those four things.

Problem one: the whole money model is four numbers

Before any code, I needed the ground truth. How big is a $100 bill, really?

I reduced the model to four physical inputs, based on measurements and estimates published by the Bureau of Engraving and Printing:

about 156 by 66.3 millimetres (the face)
about 0.1094 millimetres thick
about 1 gram per note

Every money measurement on the page starts with these four inputs. Area laid flat, height of a stack, weight on a scale, length end to end. All of it is those numbers multiplied by "how many notes do you have." The city, landmark and vehicle comparisons use separate reference data, but the money itself is just these.

This was the first lesson. When your core numbers rest on a few physical constants, those constants need to live in exactly one place in the code. Not copied into the road renderer, and again into the scale table, and again into the FAQ text. One source of truth, imported everywhere. Because the day you refine the thickness value, you want to change it once, not hunt it across the codebase.

Sounds obvious. I still got it wrong the first time. Two parts of the code used slightly different thickness values, so two stack-height readings on the same page disagreed by a few percent. I could not figure out why for an hour.

Problem two: a road made of money you can actually drive on

Here is where the weekend died.

A static number does not land. "10 million notes" means nothing. So I built a road. Every tile on the road is one $100 bill. You pick a vehicle, a sports car, a tractor, an F-35 jet, and you drive along the money using the arrow keys. The distance you cover is real: put the notes end to end and one metre of road is worth $641.

The naive version is easy and immediately dies. You cannot render 10 million DOM elements. You cannot even render 100,000. The browser falls over long before you reach interesting amounts of money.

So the road runs on WebGL, through Three.js. The trick that makes it work is that you never build the whole road at all. You render one fixed stretch of it. Its texture scrolls beneath the vehicle through a UV offset, so the ground appears to move. A reusable pool of trees, posts and roadside signs is wrapped back ahead of the camera once they fall behind you. Nothing is created and destroyed on every frame. The money is "infinite" the way a treadmill is infinite. The belt moves, you stay roughly in place, and the same handful of objects keep getting recycled to the front.

The vehicles were their own rabbit hole. Each one has a distinct configured top speed, so the tractor genuinely crawls while the F-35 moves far faster than the cars. These are game-style limits, not spec sheets. A sports car is capped at 200 km/h here even though a real one goes faster. The jet does not drive on the road, it hovers above it with a procedurally generated model, because a fighter jet rolling down a paper highway looked stupid and a flying one looked right. Small detail. Took an evening.

The thing I underestimated was keyboard driving. Holding the up arrow to accelerate, down to brake, feels trivial until you handle the edges: the road losing focus, multiple keys held at once, or the player restarting while accelerate is still pressed. Restart has to reset distance, speed, the wheel animation, the held inputs, and the milestone popups, all together, or you get ghosts. A car that keeps rolling after you reset it. I found most of these by feel, driving the road at 2 a.m. and noticing something was slightly off.

Problem three: keep the numbers canonical, convert only to display

The driving section can switch between metric and imperial units. You flip a switch and kilometres become miles, the speed and distance and the travel-time table all update together.

The obvious way to build this is the wrong way. If you store the displayed value and write it back, you drift. Store "1.56 km," convert to 0.97 miles for display, then let the user flip back and you convert that rounded 0.97 into km again. Every round trip that writes back a rounded number loses a little precision. Flip enough times and the value visibly wanders.

The fix is a rule I now apply to everything with units. Keep one canonical value and convert only at the last moment, when you format it for the screen. The road simulation integrates distance in metres and speed in metres per second. The kilometre and the mile are both just views of that stored number. Switching units never writes back to the underlying value, so it cannot drift. You can flip the toggle a thousand times and the numbers match the first flip exactly.

It is a boring rule and it saves you from a whole category of "why are the numbers slightly wrong now" bugs that are almost impossible to reproduce on purpose.

Problem four: a crawler cannot drive a car

Here is the tension in the whole project. The interesting part of the page is interactive and lives in WebGL. A search crawler may execute JavaScript, but it cannot reliably extract meaning from a WebGL canvas or press the arrow keys the way a person would. To a crawler, a beautiful interactive scene can look like a blank rectangle.

So the page is built in two layers. The real answer, all of it, exists as plain server-rendered HTML. The measurements, the comparison table, the "here is a billion versus a million" section, the questions and answers at the bottom. Every number a person or a crawler could want is in the HTML before a single line of WebGL runs.

Then the interactive road and the drag-to-scale widget layer on top, for humans with a browser and a GPU. If the JavaScript never loads, you still get a complete, readable, correct page. If it does load, you also get to drive a jet along a road of money.

This is the part I would tell anyone building visual, interactive content. The fancy layer is a progressive enhancement, not the foundation. Build the boring, complete, server-rendered version first. Then make it fun on top. Not the other way around, because the other way around is invisible to a big part of the internet.

What it actually is, underneath

Strip away the driving and the sliders and the money model is almost embarrassingly simple. A few physical constants. A pile of multiplication. Some comparisons to things people already have a feel for, a bath towel, a bus, the Burj Khalifa, the area of Paris inside its ring road.

The engineering was never in the math. It was in making the math felt: rendering a road that cannot fit in memory, driving it without jank, keeping units honest, and making sure a machine that cannot see any of it still gets the full answer.

If you want to look at the thing, it is here How big is a billion dollars. Pick the F-35, hold the up arrow, and go find the trillion-dollar sign. In single-row mode it is about 33.7 days away at the jet's top speed. The supercar would need about 162 days, and the 200 km/h sports car about 325. Which is its own kind of answer to the original question.

I am still building the rest of the site around this, more visual ways to look at money and its history. If you spot something broken, or you have built infinite-scrolling WebGL worlds and know a better trick than the one I used, I want to hear it. This is the first project I have put in public, and before this the only audience for my side projects was me and my fish.

The Site That Didn't Want to Be an Inflation Calculator (But Has to Pretend It Is)

Andy Yk — Tue, 07 Jul 2026 13:03:00 +0000

I wanted to build something different. The idea was simple, or it seemed simple to me. Show what money meant across human history. Not just numbers, but what they actually bought, who was rich, who was poor, where you would stand if you somehow appeared in a medieval village or in Manchester of 1850 with your 2026 salary.

A peasant in 14th century England earned about 4 pounds a year. A skilled craftsman maybe 10. A priest 20. The richest landowners had thousands. I wanted someone in 2026 to type their monthly income and see this. To see that they earn more in a month than a peasant family earned in their entire life. Or maybe they would see they would have been the priest, not the rich one. Things like that.

That was the project I wanted to build. Wealth Map. Rich-O-Meter. Tools that let you locate yourself in the long story of human prosperity, and it lives at realworth.io

So obviously the first thing I built was an inflation calculator.

How the calculator ate everything

You build one calculator. It generates 5,520 pages. Each one targets a search like "100 dollars in 1920" or "5000 francs in 1830." Suddenly your site is six country pages, five supporting pages, and 5,520 inflation calculator pages.

Google sees this and says: this is an inflation calculator. And Google is not wrong. Math is math. Numbers do not lie. 5,520 versus 11. The inflation calculator wins.

I tried to fight this. I made the homepage explicitly about purchasing power, about what money really means. I built Wealth Map. Then Rich-O-Meter. They are there, you can find them in the menu. Nobody uses them. Everyone goes to the inflation calculator, because that is what the entire site shouts about, on every page, in every link, in every piece of structured data.

It is like opening a small restaurant. You want to be known for your seasonal vegetable menu. But you also serve cheeseburgers, and somehow you ended up with 5,520 cheeseburgers and 6 vegetable dishes on the menu. You can put "FINE DINING" in the window. The map app says cheeseburgers.

The numbers (this is where I get honest)

5,520 pages in sitemap. 7 indexed by Google.

Seven.

In April I had about 6,500 pages indexed. Then in early May I updated the sitemap twice in one week. Then I clicked "Validate Fix" in Google Search Console before Google had finished re-evaluating, which Google treats as a failed validation. I think this is SEO equivalent of being caught lying in school. You do not get to try again right away.

The site has 200ms server response time. Mobile speed is OK. Schema markup is correct. Each page has 1,100 words of unique content. Everything technical is in order.

Indexed: 7.

What you learn building 5,520 pages

Programmatic SEO works against you if you do not have authority. A new domain with zero backlinks and 5,520 templated-looking pages looks like a doorway scheme to Google. Even if the pages are good. The signals Google needs to trust you come from outside the site. Backlinks, brand mentions, time. Mostly time.

Your pages can be objectively better than competitors and Google will still not index them. Content quality is necessary but not enough.
Sitemap is not a button you can press repeatedly. Each change resets Google's reassessment clock. Patience is not virtue here. It is requirement.

The features I wanted to build do not need 5,520 pages. They need maybe 20. They were never going to drive SEO traffic the way an inflation calculator does. They drive direct traffic, from people sharing them. Which requires audience. Which requires traffic. Which requires being indexed.

What I am doing now

I stopped pretending I am not building an inflation calculator. I am.
But I am still building everything else too.

Last week I shipped a Remittances Flow Map. It is interactive visualization of $700 billion in money that crosses borders every year as remittances. Filipino workers in Saudi Arabia sending wages home. Indian software engineers in California funding their parents' retirement. Mexican farm workers wiring money to villages they grew up in.

And this week I shipped something else. World Cup 2026 is coming, and I built a live prize money tracker. It shows how much every national team has earned so far in the tournament, and how much is still at stake. It also tracks the clubs, because FIFA pays clubs for every player they released to a national team, based on how far that player's team goes. Chelsea, Barcelona, PSG, Real Madrid, they all get money every time one of their players plays a World Cup match. This is not something most people know about. Auto-updates after every round.

Neither of these pages will help indexation. They are wrong shape for SEO. Single pages, interactive, JavaScript-heavy. Google cannot extract much from them. But they are the type of pages I wanted to build in the first place. Maybe someone shares them. Maybe a journalist writing about migration economics mentions the remittances map, or a football blog mentions the prize tracker. Or maybe nobody, and they just exist quietly, doing what I wanted RealWorth to do.

The plan from here is straightforward. Keep building visual tools that help people see global wealth and its history. Rich-O-Meter is on the site but it is basic. Wealth Map needs serious upgrade, right now it is just a small placeholder. There is a "what would your salary be in the Roman Empire" feature I keep sketching but not shipping. I want to add trade routes, historical wages by profession, mortality rates against income. Things that show where humanity actually is, financially, today and across centuries.

The inflation calculator is supposed to pay for SEO traffic. Right now it does not pay for anything, because Google indexed seven pages of it. But the structure is there. When Google decides this site is real, the calculator is what will bring in the visitors. The maps and wealth tools are why I wanted to build the site in the first place. Both can exist.

One more thing

This is the first project I ever released into public. Before this, any project I worked on, only me and my fish saw it. Releasing something publicly is strange feeling. People can see your weird ideas now. Some of them might think the ideas are stupid.

So I want to ask. If you read this and think I am doing something stupid somewhere, please tell me. I am still learning all of this. The site is at realworth.io. There is the calculator obviously. There is Remittances Map. There is small Wealth Map that needs more work. There is methodology page where I tried to be honest about what data I used. Take a look, tell me what is broken or wrong.

And if you have gone through something similar, the programmatic SEO purgatory, the vision-vs-reality conflict, the moment you realize your side project is now a different product than the one you imagined, I would like to hear about it. Tell me how you got out. Or that you did not. Both are useful.