576 Browser Windows Playing Snake (And What I Learned)

#programming #showdev #tooling

Graham the Dev made Snake run across 576 browser windows. I know because I read it, and then I sat in silence for a while, trying to decide if I should build something related or just close my laptop and stare at a wall.

I built something related.

The Core Problem

The idea is wild but the underlying concept isn't new. You're taking a single computation — the state of a Snake game at frame N — and distributing its rendering across N independent browser contexts. Each window is a canvas. Each canvas gets one cell of the grid, or a small slice, depending on how you partition it.

The coordination is the hard part. Who tells window 317 what color to paint? Who decides when frame N is done so frame N+1 can start? And how do you prevent 576 tabs from actually crashing the machine?

Graham solved this with a parent HTML file that opens child windows in a grid, uses postMessage for communication, and renders each frame synchronously. It works. It's also a CPU and memory nightmare, which is kind of the point. The page itself says "this WILL hurt your PC."

That's a lot of trust to put in a single blog post.

What Stuck With Me

I kept thinking about the grid layout problem. Not Snake specifically, but the general case: if you have a set of independent render targets and you want to display them in a coordinated grid — how do you manage that cleanly?

Most dev tools for multi-pane views are either heavyweight (full IDE integrations) or fragile (hardcoded CSS grids that break the moment you resize). I wanted something small. Something I could open in a browser, feed it a set of URLs or frames, and get back a clean grid.

So I built GridView. It's a single HTML file that takes a list of URLs and renders them in a resizable grid. No backend, no signup, no dependencies. You paste URLs, it splits the viewport into tiles, and each tile is an iframe. That's it. That's the whole tool.

It's not Snake rendered in 576 windows. It's closer to Snake rendered in 4 or 8 — enough to be useful for debugging multi-view setups without melting your power supply.

The Architecture (Because It's Simple Enough to Show)

The grid layout is computed client-side. Here's the core function that divides the viewport into rows and columns:

function computeGrid(totalFrames, cols) {
  const rows = Math.ceil(totalFrames / cols);
  const grid = [];
  for (let r = 0; r < rows; r++) {
    for (let c = 0; c < cols; c++) {
      const idx = r * cols + c;
      if (idx < totalFrames) {
        grid.push({
          row: r,
          col: c,
          style: `grid-row: ${r + 1}; grid-column: ${c + 1};`
        });
      }
    }
  }
  return grid;
}

Each frame gets a CSS grid position. The iframes fill their cells, and object-fit: contain keeps the aspect ratio sane. Resize the browser and the grid reflows. No framework, no bundler, no drama.

There's a tradeoff: iframes can't share state with each other, so unlike Graham's postMessage approach, you can't coordinate real-time gameplay across panes. But for static frame previews, debugging UI layouts across viewport sizes, or just showing off a concept in a grid? It works.

The Indie Part

I put this on my site. I charged $5. I did not write a startup pitch deck.

Here's the thing I've learned building solo tools: the most interesting projects are the ones where I read something weird on the internet and my first instinct isn't "I could build that at scale" but "hmm, I want to try a small version of that today."

576 browser windows playing Snake is a spectacle. GridView is a plumbing tool. Neither is going to change the world. But I shipped one, I'm charging $5 for the other, and they both do exactly what they say they do. That's the whole business model.