Docker images are MB; a full game engine compiles to 35MB WASM

I've been playing with Golang and WASM lately; hands-on WASM was new to me.

I found that many dependencies in the ecosystem (especially older ones) do not support GOARCH=wasm nor GOOS=js / GOOS=wasip1. I've had to fork and add support and then do go.mod replace directives. It can get messy.

Golang build tags make it awesome to have different implementations for different systems.

In the browser, it's all single threaded, so goroutines starve each other. I had to put in "breaths" for interactivity.

There's no local filesystem, so you have to figure out other solutions. Some dependencies use the filesystem as an implementation detail or try to shell out. The program will build, but will error at runtime.

That said, it is pretty sweet when it works. You can make WASM games with ebitengine [1] and it emits instructions for a WebGPU renderer; very efficient and many interactivity concerns are handled for you. The NTCharts demo page [2] combines Zig (Ghostty), WASM+Typescript+GLSL (Ghostty Web), and Golang (booba/ntcharts). The WASM size for the demos there is ~5MB each.

My goal is to make tools for terminal remoting and simplify bringing TUIs to the browser. [1] https://ebitengine.org

[2] https://nimblemarkets.github.io/ntcharts/demos/heatpicture-p... press 't' for kitty graphics

Shameless plug but if you like small file size overheads, our browser based game engine Construct[1] exports an empty web project with about 300 KB overhead for a fully-featured engine. We achieve this by going all-in on the web platform so we don't have to ship a heavyweight runtime with it, and using a modular approach where only the components you use get exported.

[1] https://www.construct.net

> Same as ARM nodes a few years ago: cheaper, denser, widely available – still not the default choice.

Because ARM nodes save you a bit of money (they're cheaper but a bit slower, maybe you end up saving 20-30%) but the move isn't trivial for many tech stacks. When you try it you find you have some Python dependency with a C bit that doesn't have an arm wheel, or your browser automation can't run Chrome on those nodes (there isn't a linux/arm64 build of it). If you're using Go you can cross-compile, although it will likely fail without explicitly disabling cgo, and do you know what the consequences of that are?

Basically it very often ended up being more trouble than it was worth.

So the engine is 35MB, but what does it run in? By itself it's a binary blob that doesn't do anything.

Chrome seems to be ~404MB installed on here; that is conspicuously missing from the comparisons here to Docker containers which do account for more or less the complete runtime.

Unity compiles down to 3MB wasm. Though they don't need to ship the dotnet runtime, they use IL2CPP, a proprietary thing that translates dotnet code into C++. Then they run Emscripten on it.

Also I think Godot's WASM outputs used to be 2-3x smaller in Godot 3 (though the C# one was bigger).

You can ship a JS game in kilobytes, although atop 30 million lines of Chromium that's cheating of course :) still good fun.

https://js13kgames.com/

Notch also made a bunch of 4kb Java (not JS) games back in the day, which is probably what got me into this stuff.

https://web.archive.org/web/20090108001738/http://www.mojang...

Docker can be small too. In this example I was able to compile a full server (rust binary) and package it in a docker (scratch image base) and the total was < 5MB.

https://github.com/srv1n/kurpod/pkgs/container/kurpod-server

wasm version compiles to under a MB though!

Quod is only 64K https://daivuk.itch.io/quod and looks more impressive

That is a strange title / comparison. Docker images (even slimmed down) have an OS (most likely a Linux distribution), some libs and the runtime needed for a programming language. On it's own a "game engine + WASM binary" is not comparable.

10MB for the Google Homepage! 44MB for Facebook Homepage! I have not been paying attention to website bloat. Wow, and people were annoyed when a site had to download a whole JQuery library for a single function.

Sure but in WASM, the browser's environment is taking responsibility for many OS concerns (graphics, IO, 3D, hardware). In a Docker image, all that logic needs to be bundled in libraries as you'll only get to "reuse" the hosts' kernel.

A 'fairer' comparison would be a optimized and compiled binary that dynamically links to the OS versus a WASM product (would be kilobytes-megabytes).

Or having the WASM app in a Chromium browser in Docker (would be gigabytes).

Amazing that the point of this article is that 35MB is small and everything else is bloated

WASM sounds great in theory but it's so much pain in practice. Once as a presentation demo I made it run on ESP32 but in the process of digging deep into runtimes and WASM spec, I wanted to disclose pros vs cons and it killed my presentation.

I realize wasm wasn't designed for embedded but it made me open my eyes to it's intricacies like minimum memory allocation, why not native 1 byte variables?

Is it fair to compare WASM app to a base install?

The thing runs in a browser that has most of the stuff implemented to integrate with whatever system it runs on, and just needs to present.

It’s payload versus payload + runtime.

I believe you can create this demo using webgl in less than 4kb.

Back in the Atari 2600 days, we had full AAA games that sold millions fitting in 4KB...

kkrieger enters the chat