zlacker

>>ryanvo+(OP)
I am more shocked about the origin story compared to the acquisition.

> Almost five years ago, I was building a Minecraft-y voxel game in the browser. The codebase got kind of large, and the iteration cycle time took 45 seconds to test if changes worked. Most of that time was spent waiting for the Next.js dev server to hot reload.

Why in the hell would anyone be using Next.js to make a 3D game... Jarred has always seemed pretty smart, but this makes no sense. He could've saved so much time and avoided building a whole new runtime by simply not using the completely wrong tool for the job.

>>notnul+cr1
He may have been serving a game in a canvas hosted in a Next.js app, but have done all the actual game (rendering, simulation, etc.) in something else. That’s a decent approach - Next can handle the header of the webpage and the marketing blog or whatever just fine.

>>johnco+Qt1
But like... so can an index.html with a script tag? Am I missing something, where did you read that there was a lot of work involving the header or an attached marketing blog?

>>komali+9v1
My point isn’t that you absolutely need that, just that the negative effect on your game development are pretty minimal if you’re not leaning on the SPA framework for anything related to the game. If your game is going to be embedded into an otherwise normal-ish website, this isn’t a terrible way to go (I’ve done it personally with a game mostly written in Rust and compiled to WASM). You can get gains by splitting your game and web site bundles and loading the former from the latter explicitly, but they’re not massive if your bundler was already reasonably incremental (or was already esbuild).

Thanks for assuming I “read” about bundlers somewhere, though. I’ve been using (and configuring) them since they existed.

>>johnco+ly1
I meant specifically was there something I was missing about the Bun developer's game that required a complicated header and thus next.js.