zlacker

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+(OP)
Maybe same for anthropic, they can simply write agent using Rust/Go. Instead they decide to buy and develop a JavaScript runtime.

>>notnul+(OP)
> 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.

True, but where is the fun in that?

>>notnul+(OP)
Most people use what they know. You start out that way, and if it turns out to be good, you can always do a v2

>>notnul+(OP)
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.

>>mock-p+t2
Yes, but there are obvious limits to that. This is like someone who knows how to bake wanting to build a car, so they start making it out of dough.

>>johnco+E2
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+X3
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+j4
Sure, but I'm more confused about the next.js usage than I am about the bundler. The bundler makes sense.

>>komali+X3
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+l5
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.

>>notnul+(OP)
Because he wanted to? Do you also berate the choices of people in the 4K demo scene for using too little memory?

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

>>johnco+97
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+gg
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+th
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.

>>notnul+(OP)
First time I see it being a net positive that someone didn't know about Vite: Bun wouldn't exist otherwise.

>>mayo36+k
If anything this seems to be a huge victory for Zig, since Bun is mostly written in Zig.

>>notnul+(OP)
This take is interesting given we're all here congratulating Jarred for seeing that there was no tool to solve x so made it, and is now enjoying a likely nice payday. Be the change you want to see in the world?

>>mayo36+k
These are completely different. Agents (aside from the model inference) are not CPU bound. You gain much more by having a wider user base than whatever marginal CPU cycles you would gain in Rust/Go.

Video games are of course a different story.

>>notnul+(OP)
I don't think his goal was to get the fastest voxel engine. Most projects just start with "That's stupid... but what if I did it anyway?"

>>nly+IH
That’s just what the Javascript ecosystem has been missing! A runtime built on an unstable pre-1.0 language to go with the npm dependency churn. It’s been way too long since I’ve had to waste a week debugging what turns out to be a compiler/interpreter bug.

(I’m half joking, that’s awesome for Zig!)

>>morito+rN
It kinda reads like a case of survivorship bias. He is the one in a million to reach the good ending, despite starting with the wrong choice; though in this case, the wrong choice brought him on the road to the good ending.

Now the real question is, does the game loads significant better now, or does the performance still suck? In which case it might be more an excessive case of yak-shaving. And if yes, when can we except the release?

>>throwu+951
Rushing things to completion using unfinished code is the JavaScript way!

- a javascript developer

>>Tadpol+P8
That’s kind of the opposite though. I guess if you’re saying that there’s an art to building things using the least efficient means possible just as there’s an art to being maximally efficient (like the 4k demo scene) then your point stands.

>>notnul+(OP)
I’m guessing he was probably a JavaScript developer that wanted to make a game. He began building it using what he knew and then he hit the limitations of it. Rather than switching to something else, he tried to figure out why fast compile times weren’t possible and determined that they were possible and started to build a solution for it.

>>mayo36+k
My thinking is that they’re trying to capture that market for JavaScript before another AI company does. To put it bluntly they want to capture the revenue generated by writing JavaScript code, which is currently being captured by independent JavaScript developers. The reason for a JavaScript is that is the most ubiquitous language, and id guess there are more jobs available for JS/node than any other language. Of course, as a JavaScript developer, this may just be my paranoia. <sweats profusely>

>>Purple+4j1
If the output generated by his attempts at making a better game is a much faster node runtime, then even if the game is still not usable does that matter? The end result is still an improvement over something that existed before. The game was just a catalyst.

Isn’t every success story really an example of survivorship bias?

>>Purple+4j1
Using your comment to address overall sentiment in this comment thread.

Builders build. Sometimes it's not about picking the right tools for the job or starting with the right choices. Sometimes it's just about building.

To use your road analogy - sometimes people just go for a drive. Sometimes those people end up right where they are supposed to be.

>>notnul+l3
That is not a good analogy. Games are built using programming languages. JavaScript is a programming language. Cars are built using metals (usually steel). A better analogy would be like trying to build a car out of iron, a really heavy metal. Since js/node is very resource heavy requiring transpilation/etc…

>>notnul+(OP)
That's super strange since React by its nature assumes that controls are stateless - which games definitely are not. If you render your game inside a canvas then React decides it wants to recreate your control, then your whole game restarts.

>>somegu+Xm1
> Isn’t every success story really an example of survivorship bias?

No, survivorship bias (in this context) means to wrongly see a minor subgroup as the majority. But the successful subgroup is not always a minority, or falsely labelled.

>>timcam+ol
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.

>>somegu+7l1
Yeah, my point was that people do things for fun or as a challenge or to push the limits of a technology.

Nobody made DOOM in Excel because they thought it made a good engine.

>>Aeolun+92
Where is the fun in next.js?

>>somegu+3o1
It's not a perfect analogy, but none of my comments are directed at the use of JS for a game, it's a fine choice. It's the use of Next.js that's the issue, it's a framework for server side rendering of HTML. It serves no benefit if your goal is to make a 3D game, it only adds overhead. If he had not been using it he would have realised there's a few bundlers out there that are far better than what Next.js dev server provided at the time.