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 a common argument when sizecoding is discussed. "You say it is 64k, but I need a multi-gigabyte OS to run it...". 35MB can't hardly be called sizecoding, but that's the same idea.
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.
WebGL2 has been supported in Chrome since 2017.[0] The last holdout, as is tradition, was Safari which gained support in 2021. MDN considers it "Baseline - Widely available."
no offense taken. Of course it's my setup, even though it's vanilla setup on a new driver where driver and gfx do work. That's the thing illustrated here - it's always someone's setup somewhere outside of general case tested and "works on my machine". Then you get into all these setups and see variations and one day you decide for common libs to be shipped with your game (remember those MSVC installs?), then still same issues and then you decide to ship common runtime (like steam has), then you decide to ship hardware.. on more constrained (SLAs and whatnots) side it was the same thing and that's how we ended up with docker images.
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.
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.
In general wasm only requires an interpreter. But in the case of Unity web, there's JavaScript glue code that requires browser APIs that allow it to actually render.
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.
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.
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.
It's not an error, it's just saying the project exceeds the free edition limits, which means you can look around and preview it but not make edits to it.
So it’s a warning, not an error, but it looks like an error to someone who hasn’t learned how the thing works.
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.
Seems like the anti-clickbait title editing removed the “hundreds of”? This confused me because I thought “oh, they’ve stripped down a Docker image to only 1 megabyte, and then a full game engine adds 34MB more” (I missed the WASM on the first read)
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.
> "Docker images (even slimmed down) have an OS (most likely a Linux distribution)"
Not necessarily. Docker images can be based from the "scratch" container, and may contain only a single binary. With static compilation, the libraries can be included in the binary.
The O/S is provided by the container-host (which is usually a linux VM).
FWIW, the base images they're talking about do not contain an entire OS. In fact, they're lacking a colossal amount of the most basic stuff that qualifies as 'an entire OS'. In many cases, your base images are 'a program to install more stuff if you need it', a shell, and coreutils.
Container images don't need an OS. You can always do "FROM scratch" and only copy what's needed to run the binary. If it's completely self contained one executable is enough.
> 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.
I know what the OP, but it is not special in the sligtest. Early emscripten ran Quake, a common engine. There is significant bloat in this setup if 35M is some form of measurement.
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.
I thought it had always been pretty lean - I remember someone telling me that when Google launched, its homepage was borderline broken HTML to save on bytes.
It's more or less an abomination. Dropping the frameworks and js jazz you could have most of the features of either of these sites served in the kb range. It would save millions of dollars in electricity, billions in infrastructure, and be more secure.
Yes, it's absolutely the frameworks. That each weigh <100KB. Definitely frameworks :D
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.
It's the 35MB wasm, plus the browser runtime, the OS graphical session and the kernel runtime. Docker images are MB because they pack the distro overlay, not because it's unreasonably unoptimized as the clickbaity title suggests.
Docker doesn’t even need a whole OS overlay if your project doesn’t call for it. It’s pretty easy to take a Go app for example and just include it in a scratch container.
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
Tbh, 35 MBytes for a game client binary isn't much to brag about, WASM or not.
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 recently ported an old brickout clone I made to Sokol (a C header-based game library). The whole executable is 500kb (macos), surely could be smaller with eg symbols stripped, and it has a whole 3d engine (not that i'm using much more than one custom shader to blit the screen, but it is using 3d engine infrastructure nonetheless). I was impressed that in this day and age such efficiency is still fashionable in some corners. The whole game is about 2mb zipped. Are shameless plugs allowed? If you're curious have a peek! github.com/chrishulbert/brickwarrior
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?
Well my original idea was to show that in a future anyone could code for MCUs in any language. I actually changed my mind in the process. Now we got LLMs and people just prompt anyway.
> Same as ARM nodes a few years ago: cheaper, denser, widely available – still not the default choice.
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.
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).
Docker's layer-based deduplication mechanism is ineffective or actively harmful IMO. In practice, different images aren't going to share layers even for the same software because images are always going to be built against the latest base image. To make matters worse, many Dockerfiles run `apt-get update` or other equivalent commands, overwriting what's in the base layers and creating tons of wasted space. Nix does a much better job at deduplication with the Nix store.
Sigh, rounded corners everywhere, a bit tiring to be honest. UI is still in the 90s. And all those lifeless, soulless icons, bleeeh. Well, the pixel phone is still the contender for the decade's ugliest phone.
It usually doesn't matter how large a docker image is. Network is fast and disks are cheap (server disks are usually big enough, nobody specs a large server with 80gb ssd, 300-500gb is the realistic minimum).
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)
Runs in any browser, zero install.
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 a common argument when sizecoding is discussed. "You say it is 64k, but I need a multi-gigabyte OS to run it...". 35MB can't hardly be called sizecoding, but that's the same idea.
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.
WebGL2 has been supported in Chrome since 2017.[0] The last holdout, as is tradition, was Safari which gained support in 2021. MDN considers it "Baseline - Widely available."
[0] https://caniuse.com/webgl2
This is often due to (privacy) extensions disabling canvas/webgl.
FWIW it was because chrome was running from flatpak (ironically).
Does a docker image not also require drivers, an OS, and the Docker Engine?
WebGL2 support on Chrome and Firefox is now nearly a decade old:
https://caniuse.com/webgl2
Only Safari was late to the party (2021).
No offense, but the problem is clearly with your setup.
no offense taken. Of course it's my setup, even though it's vanilla setup on a new driver where driver and gfx do work. That's the thing illustrated here - it's always someone's setup somewhere outside of general case tested and "works on my machine". Then you get into all these setups and see variations and one day you decide for common libs to be shipped with your game (remember those MSVC installs?), then still same issues and then you decide to ship common runtime (like steam has), then you decide to ship hardware.. on more constrained (SLAs and whatnots) side it was the same thing and that's how we ended up with docker images.
> Then you get into all these setups and see variations
...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".
"works on my machine"
[dead]
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!
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...
WASM requires a browser too, no? (or an equivalent runtime, possibly smaller depending on requirements)
In general wasm only requires an interpreter. But in the case of Unity web, there's JavaScript glue code that requires browser APIs that allow it to actually render.
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.
Yeah, you said what I said.
Tbf, you can also ship WASM games in kilobytes. E.g. here's a Pacman clone written in C99 in "46.8 kB transferred" (107 KBytes uncompressed size):
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.
I guess we could also compare what is possible in Amiga demoscene, and plenty of bloat that goes around nowadays.
Looking at the demo, 35MB WASM for that?!?
These are Carrier Command and F-18 Interceptor on 512 KB.
https://www.youtube.com/watch?v=89cUUbwqPN8
https://www.youtube.com/watch?v=9Whw4E2qpm8
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.
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
FYI “open 3d city” link gives an error about exceeding the free edition size.
It's not an error, it's just saying the project exceeds the free edition limits, which means you can look around and preview it but not make edits to it.
So it’s a warning, not an error, but it looks like an error to someone who hasn’t learned how the thing works.
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.
Seems like the anti-clickbait title editing removed the “hundreds of”? This confused me because I thought “oh, they’ve stripped down a Docker image to only 1 megabyte, and then a full game engine adds 34MB more” (I missed the WASM on the first read)
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.
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...
Seriously, this is a ridiculous comparison. It's apples to oranges.
This site used to have interesting technical discussions, but now its all either AI cheerleading, or vibe coder blog posts.
Maybe it's a good reminder to _not_ bundle an entire OS in a Docker image
FWIW, the base images they're talking about do not contain an entire OS. In fact, they're lacking a colossal amount of the most basic stuff that qualifies as 'an entire OS'. In many cases, your base images are 'a program to install more stuff if you need it', a shell, and coreutils.
For debugging image it's sometimes nice to be able to actually do stuff in the container, but for production image I'd agree.
Some tricks:
docker run -it --rm --pid=container:myapp --network=container:myapp --cap-add SYS_PTRACE nicolaka/netshoot
kubectl debug -it pod-name --image=nicolaka/netshoot
And that's why Docker images are terrible as a packaging format. No sane packaging format should ever prevent software composition.
Container images don't need an OS. You can always do "FROM scratch" and only copy what's needed to run the binary. If it's completely self contained one executable is enough.
> 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.
Quod is only 64K https://daivuk.itch.io/quod and looks more impressive
There is also .kkrieger (2004) which is 96k
But the thing with what OP did is, that it runs in the browser and uses a common game engine.
Oscar Toledo did it in 510 bytes https://github.com/nanochess/cubicDoom
I know what the OP, but it is not special in the sligtest. Early emscripten ran Quake, a common engine. There is significant bloat in this setup if 35M is some form of measurement.
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.
Which Google homepage is 10MB?
I did a cache-cleared load of www.google.com just now and didn't get anything close to that.
I thought it had always been pretty lean - I remember someone telling me that when Google launched, its homepage was borderline broken HTML to save on bytes.
It's more or less an abomination. Dropping the frameworks and js jazz you could have most of the features of either of these sites served in the kb range. It would save millions of dollars in electricity, billions in infrastructure, and be more secure.
Yes, it's absolutely the frameworks. That each weigh <100KB. Definitely frameworks :D
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.
What else would it be? Google is a picture, a text box, and few buttons. Not exactly a lot of HTML
It's replying to this:
> 10MB for the Google Homepage!
Even 1MB is way too big for "a picture, a text box, and few buttons."
I wonder where the 10MB came from, I checked on my browser and it's only loading about 1.5MB with cache disabled.
It's the 35MB wasm, plus the browser runtime, the OS graphical session and the kernel runtime. Docker images are MB because they pack the distro overlay, not because it's unreasonably unoptimized as the clickbaity title suggests.
Docker doesn’t even need a whole OS overlay if your project doesn’t call for it. It’s pretty easy to take a Go app for example and just include it in a scratch container.
Good catch! With statically linked binaries you can ship them in a FROM scratch image.
We do this with some of our published images. RedHat complains because our images aren't 'based on UBI', which would add dozens or hundreds of CVEs.
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'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
Tbh, 35 MBytes for a game client binary isn't much to brag about, WASM or not.
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.
Back in the Atari 2600 days, we had full AAA games that sold millions fitting in 4KB...
"AAA games" didn't even exist until 20 years after the 2600
I recently ported an old brickout clone I made to Sokol (a C header-based game library). The whole executable is 500kb (macos), surely could be smaller with eg symbols stripped, and it has a whole 3d engine (not that i'm using much more than one custom shader to blit the screen, but it is using 3d engine infrastructure nonetheless). I was impressed that in this day and age such efficiency is still fashionable in some corners. The whole game is about 2mb zipped. Are shameless plugs allowed? If you're curious have a peek! github.com/chrishulbert/brickwarrior
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?
If you want bytecode for embedded see stuff like BASIC Stamp or Parallax Propeller.
Well my original idea was to show that in a future anyone could code for MCUs in any language. I actually changed my mind in the process. Now we got LLMs and people just prompt anyway.
wasm requires a browser isn't really a strong argument. Docker ships a whole operating system.... and still needs a whole operating system to run on.
The difference is with this you have an entire browser (~500MB install) using typically 1000MB+ of RAM, to run this 35MB file.
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.
> Same as ARM nodes a few years ago: cheaper, denser, widely available – still not the default choice.
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.
Skill issue. You can make a Docker image 35mb too.
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).
Aren't Docker images deduplicated internally, so you'll only notice their size when you try to ship them?
Docker's layer-based deduplication mechanism is ineffective or actively harmful IMO. In practice, different images aren't going to share layers even for the same software because images are always going to be built against the latest base image. To make matters worse, many Dockerfiles run `apt-get update` or other equivalent commands, overwriting what's in the base layers and creating tons of wasted space. Nix does a much better job at deduplication with the Nix store.
This is fixable, but needs a custom pull client+registry. (Agree that Nix does a better job, if you're inclined to use it!)
Amazing that the point of this article is that 35MB is small and everything else is bloated
I feel like that ChatGPT suggested that comparison in the title
I believe you can create this demo using webgl in less than 4kb.
Sigh, rounded corners everywhere, a bit tiring to be honest. UI is still in the 90s. And all those lifeless, soulless icons, bleeeh. Well, the pixel phone is still the contender for the decade's ugliest phone.
> Even a careful minimal build with uv lands at 282MB.
wtf.
Is there a cleanup tutorial somewhere?
kkrieger enters the chat
[flagged]
It usually doesn't matter how large a docker image is. Network is fast and disks are cheap (server disks are usually big enough, nobody specs a large server with 80gb ssd, 300-500gb is the realistic minimum).
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)