wtf.
Is there a cleanup tutorial somewhere?
If size and memory usage matters (large amount of small workloads) then it might make sense to optimize for size. Can also easily be done with docker (distroless or alpine base image)
Meanwhile: Error - The following features required to run Godot projects on the Web are missing: WebGL2 - Check web browser configuration and hardware support
This is on Chrome 148.0.7778.96 (Official Build) (64-bit) on Fedora 44, 14900K, 4090 RTX, 128GB RAM
35MB WASM which relies on browser, which relies on drivers and OS, AND it doesn't work as advertised. I get the point, but point was mistaken.
It is true, but besides the point because we have no choice. It is not the 1980s anymore and we can't access the hardware directly on personal computers, vendors don't let us. Not that we would want to, for portability reasons. So we depend on abstraction layers, which are not particularly lightweight, and here, it is a working browser supporting WebGL2 and WASM. You simply can't have a game engine running on modern hardware without a software platform. For the sake of argument, we could imagine a lightweight (tens of MB or less) WASM bare metal platform with simple pixel pushing hardware.
Only Safari was late to the party (2021).
No offense, but the problem is clearly with your setup.
https://github.com/srv1n/kurpod/pkgs/container/kurpod-server
wasm version compiles to under a MB though!
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.
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...
There's other wasm runtimes that don't require a browser, but presumably you can't run the same Unity wasm binary in those runtimes and expect a scene to render.
https://floooh.github.io/pacman.c/pacman.html
...can probably be made quite a bit smaller when 'as-small-as-possible' is the main goal.
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.
> "Docker images (even slimmed down) have an OS (most likely a Linux distribution)"
The O/S is provided by the container-host (which is usually a linux VM).
This doc describes building an image from "scratch": https://docs.docker.com/build/building/base-images/#create-a...
This site used to have interesting technical discussions, but now its all either AI cheerleading, or vibe coder blog posts.
Edit:
I don't even know where you lot get these numbers from nowadays, smh.
Just checked, in Slovakia, google.com is 1MB (compressed) total with cache disabled. 400kib of those is my own extension that I installed which is counted among the 'loaded scripts'. Loads in 400ms, blink of an eye.
Framework rants are completely detached from reality, as always.
I did a cache-cleared load of www.google.com just now and didn't get anything close to that.
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.
But the thing with what OP did is, that it runs in the browser and uses a common game engine.
Looking at the demo, 35MB WASM for that?!?
These are Carrier Command and F-18 Interceptor on 512 KB.
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 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
For game engines the underlying problem is usually that the engine is designed around the idea that "everything is a virtual interface" (e.g. 'jump tables') which can't be dead-code eliminated and all engine features are always included, even when not used by a specific game.
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?
And rightfully so. Not everything can be guaranteed to work on ARM. It would confuse the hell out of less experienced people trying to launch a simple VPS or something.
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).
Whereas docker is quite small, uses very little RAM, and the image only grows because of what is included inside it, the base images are quite small.
It's pretty cool that a whole game engine these days can still be 35MB, just an odd comparison I think.
docker run -it --rm --pid=container:myapp --network=container:myapp --cap-add SYS_PTRACE nicolaka/netshoot
kubectl debug -it pod-name --image=nicolaka/netshoot
If it were me, I’d make that first click into the demo as simple and clean as possible. The site is currently educating people about a product limitation before they see the actual product.
...tbf, this is mostly a problem on Linux nowadays.
E.g. the MSVC runtime library thing had been solved since Win10 via the "Universal C Runtime".
> 10MB for the Google Homepage!