zlacker

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+(OP)
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+j1
index.html with script files would still benefit from a bundler. You can have a very minimal react footprint and still want to use react build tools just for bundling.

>>shortr+F1
Sure, but I'm more confused about the next.js usage than I am about the bundler. The bundler makes sense.

>>komali+j1
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.

>>komali+H2
What effect do you imagine Next.js has on a bunch of code manipulating an HTML canvas? For vanilla code directly using browser APIs it’s basically just a bundler configuration, and while it’s not optimally configured for that use case (and annoying for other reasons) it’s probably better than what someone who has never configured webpack before would get doing it themselves.

>>johnco+G4
Well for one, it ships next.js and react.js bundled in with the code manipulating an HTML canvas.

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

>>komali+Cd
Okay, but it’s a web game. Those will make up less than 0.1% of the downloaded bytes required to render the first frame of the game. One image asset will dwarf the entire gzip/brotli Next.js/React framework.

>>johnco+Pe
What is the use case for bundling next.js with the web game? Just the layout of the page surrounding the game canvas? It just seems unnecessary, that's all. Traditionally, software development in general and game development in particular has tried to avoid unnecessary overhead if it doesn't provide enough value to the finished product.

It's obvious why he didn't write the game in x86 assembly. It's also obvious why he didn't burn the game to CD-ROM and ship it to toy stores in big box format. Instead he developed it for the web, saving money and shortening the iteration time. The same question could be asked about next.js and especially about taking the time to develop Bun rather than just scrapping next.js for his game and going about his day. It's excellent for him that he did go this route of course, but in my opinion it was a strange path towards building this product.

>>timcam+Ki
Why would he stress about a theoretical inefficiency that has very little effect on the finished product or development process? Especially one that could be rectified in a weekend if needed? The game industry is usually pretty practical about what it focuses on from a performance perspective with good reason. They don’t build games like they’re demosceners min-maxing numbers for fun, and there’s a reason for that.

I also wonder how many people who sing the praises of an HTML file with a script tag hosted by Nginx or whatever have ever built a significant website that way. There’s a lot of frustrating things about the modern JS landscape, but I promise you the end results were not better nor was it easier back before bundlers and React.