4 ms·

A big thing overlooked with speed is binary size. WebAssembly is incredibly inefficient at storage space. For people still on DSL they will have to wait seconds

A big thing overlooked with speed is binary size. WebAssembly is incredibly inefficient at storage space. For people still on DSL they will have to wait seconds (or minutes in the case of Godot) for the blob to download before execution can start. Meanwhile javascript will be much faster to download since it is smaller and javascript can execute while it is downloading.

IshKebab 10mo ago
It's more that JavaScript comes with a large standard library already available. You don't need to ship code to print integers or parse JSON or Unicode tables etc.
CryZe 10mo ago
It depends. If you are compiling a high level GC language to WasmGC then there's really close to no reason why it would be larger than JS.
- gf000 10mo ago
  That is, if the source language's GC model is compatible with Wasm's.
  - WorldMaker 10mo ago
    WASM's current GC model is mostly about sharing large byte buffers. It's on about the order of OS-level memory page management. Mostly it is getting used to share memory surfaces to JSON serialization/deserialization without copying that memory across the WASM to JS boundary anymore. It will be a while before WASM GC will look close to any language's GC.
s-macke 10mo ago
WebAssembly itself is not that inefficient in storage. It is mostly the usual bloat that comes with binaries. For example, Go binaries have to provide a full runtime, including garbage collection. If size is your top priority, you can produce very small binaries, for example with C. Project [0] emulates an x86 architecture, including hardware, BIOS, and DOS compatibility, and ends up with a WebAssembly size of 78 kB uncompressed and a 24 kB transfer size. [0] https://github.com/s-macke/FSHistory https://github.com/s-macke/FSHistory
- charcircuit 10mo ago
  >you can produce very small binaries, for example with C Not many people are going to want to be rolling their own libc like that author. Most people just compile their app and ship megabytes of webassembly at the expense of their users. To me webassembly is just a shortcut to ship faster because you don't have to port existing code.
  - valadaptive 10mo ago
    > Not many people are going to want to be rolling their own libc like that author. Emscripten provides a libc implementation based on musl, and so does wasi-libc (https://github.com/WebAssembly/wasi-libc https://github.com/WebAssembly/wasi-libc). If you explicitly list which functions you want to export from your WebAssembly module, the linker will remove all the unused code, in the same way that "tree-shaking" works for JS bundlers. In my experience, a WebAssembly module (even with all symbols exported) is smaller than the equivalent native library. The bytecode is denser. WebAssembly modules tend to be larger than JavaScript because AOT-compiled languages don't care as much about code size--they assume you only download the program/library once. In particular, LLVM (which I believe is the only mainstream WebAssembly-emitting backend) loves inlining everything. Judicious use of `-Oz`, stripping debug info, and other standard code size techniques really help here. The app developer does have to care about code size, of course.
chrismorgan 10mo ago
This is badly wrong. • WebAssembly is not huge. Fundamentally it’s generally smaller than JavaScript, but JavaScript comes with more of a standard library and more of a runtime, which unbalances comparisons. If you use something like Rust, it’s not difficult to get the basic overhead down to something like 10 kB, or for a larger project still well under 100 kB, until you touch things that need Unicode or CLDR tables; and it will generally scale similarly to JavaScript, once you take transport compression into account. If you use something like Go or .NET, sure, then there’s a heavier runtime, maybe a megabyte, maybe two, also depends on whether Unicode/CLDR tables are needed, and then JS will probably win handily on bundle size and startup time. • JavaScript can’t execute while it’s downloading. In theory speculative parsing and even limited speculative execution is possible, but I don’t think any engine has tried that seriously. As for WebAssembly, it can be compiled and instantiated while streaming, generally at a faster rate than you can download it. The end result is that in an apples-to-apples comparison WebAssembly is significantly faster to start than JavaScript.
- charcircuit 10mo ago
  >WebAssembly is not huge I always feel like I'm downloading megabytes of it whenever someone uses it. In practice it is. Even a basic hello world in rust will set you back a few megabytes compared to a the tens of bytes it takes in javascript. >JavaScript comes with more of a standard library and more of a runtime, which unbalances comparisons. Being able to make programs in a few bytes is a legitimate strength. You can't discount it because it's an effective way javascript saves size.
  - chrismorgan 10mo ago
    > Even a basic hello world in rust will set you back a few megabytes Lies. It’s 35 kB: $ cargo new x … $ cd x $ cat src/main.rs fn main() { println!("Hello, world!"); } $ cargo build --release --target=wasm32-unknown-unknown … $ ls -l target/wasm32-unknown-unknown/release/x.wasm … 34597 … And that’s with the default allocator and all the std formatting and panic machinery. Without too much effort, you can get it to under 1 kB, if I remember correctly. For the rest: I mention comparisons being unbalanced because people often assume it will scale at the rate they’ve seen—twice as much code, twice as much size. Runtimes and heavy tables make for non-scaling overhead. That 35 kB you’ve paid for once, and now can use as much as you like without further growth.
tannhaeuser 10mo ago
This, plus after the Godot runtime, game assets itself have to be downloaded, often making use of ZIP-like archive formats that may have made sense with DLCs or physical media, but require huge downloads (like GBs) to access a single sprite when the browser DOM rendering itself is pretty much about priorizing resources as they're viewed. Plus, WASM game runtimes need to bundle redundant 2D or 3D stacks, audio, fonts, harfbuzz, etc. yet don't expose eg. text rendering capabilities on par with those that browsers already have natively. The whole thing is priorizing developer over user experience.
michalsustr 10mo ago
It’s not an issue. When we run LTO optimizations, strip all symbols, we get 2MB compressed for decently complex GPU-accelerated rendering (minfx.ai)
qouteall 10mo ago
WebAssembly standard design has considered binary size optimization. The format itself is quite compact. But porting native code to Wasm often brings many large existing libraries which contain a lot of code which makes the binary large. The native ecosystem never payed attention to binary size optimization, but the JS ecosystem payed attention to code size in the very beginning.
- pjmlp 10mo ago
  Yes, because compilers and linkers have optimize for size switches since the 1980's for fun.
- 0x457 10mo ago
  It's the fact that WASM in a browser provide very little. Anything you have there required to bring a bunch of things that JavaScript just has access out of the box. That include both, things like Fetch API and things like Garbage Collector. > The native ecosystem never payed attention to binary size optimization, but the JS ecosystem payed attention to code size in the very beginning. That's not true at all. Native ecosystem stopped paying attention to it outside of embed once storage/memory got relatively cheap (i.e. we went from kilo and megabytes to gigabytes). Native also gets to use shared libraries...sometimes. JavaScript ecosystem is like pendulum, sometimes they care, sometimes they don't. I have high hopes for components, both for reducing size and for avoiding JavaScript.

IshKebab 10mo ago

It's more that JavaScript comes with a large standard library already available. You don't need to ship code to print integers or parse JSON or Unicode tables etc.

CryZe 10mo ago

It depends. If you are compiling a high level GC language to WasmGC then there's really close to no reason why it would be larger than JS.

gf000 10mo ago
That is, if the source language's GC model is compatible with Wasm's.
- WorldMaker 10mo ago
  WASM's current GC model is mostly about sharing large byte buffers. It's on about the order of OS-level memory page management. Mostly it is getting used to share memory surfaces to JSON serialization/deserialization without copying that memory across the WASM to JS boundary anymore. It will be a while before WASM GC will look close to any language's GC.

s-macke 10mo ago

WebAssembly itself is not that inefficient in storage. It is mostly the usual bloat that comes with binaries. For example, Go binaries have to provide a full runtime, including garbage collection. If size is your top priority, you can produce very small binaries, for example with C. Project [0] emulates an x86 architecture, including hardware, BIOS, and DOS compatibility, and ends up with a WebAssembly size of 78 kB uncompressed and a 24 kB transfer size. [0] https://github.com/s-macke/FSHistory https://github.com/s-macke/FSHistory

charcircuit 10mo ago
>you can produce very small binaries, for example with C Not many people are going to want to be rolling their own libc like that author. Most people just compile their app and ship megabytes of webassembly at the expense of their users. To me webassembly is just a shortcut to ship faster because you don't have to port existing code.
- valadaptive 10mo ago
  > Not many people are going to want to be rolling their own libc like that author. Emscripten provides a libc implementation based on musl, and so does wasi-libc (https://github.com/WebAssembly/wasi-libc https://github.com/WebAssembly/wasi-libc). If you explicitly list which functions you want to export from your WebAssembly module, the linker will remove all the unused code, in the same way that "tree-shaking" works for JS bundlers. In my experience, a WebAssembly module (even with all symbols exported) is smaller than the equivalent native library. The bytecode is denser. WebAssembly modules tend to be larger than JavaScript because AOT-compiled languages don't care as much about code size--they assume you only download the program/library once. In particular, LLVM (which I believe is the only mainstream WebAssembly-emitting backend) loves inlining everything. Judicious use of `-Oz`, stripping debug info, and other standard code size techniques really help here. The app developer does have to care about code size, of course.

chrismorgan 10mo ago

This is badly wrong. • WebAssembly is not huge. Fundamentally it’s generally smaller than JavaScript, but JavaScript comes with more of a standard library and more of a runtime, which unbalances comparisons. If you use something like Rust, it’s not difficult to get the basic overhead down to something like 10 kB, or for a larger project still well under 100 kB, until you touch things that need Unicode or CLDR tables; and it will generally scale similarly to JavaScript, once you take transport compression into account. If you use something like Go or .NET, sure, then there’s a heavier runtime, maybe a megabyte, maybe two, also depends on whether Unicode/CLDR tables are needed, and then JS will probably win handily on bundle size and startup time. • JavaScript can’t execute while it’s downloading. In theory speculative parsing and even limited speculative execution is possible, but I don’t think any engine has tried that seriously. As for WebAssembly, it can be compiled and instantiated while streaming, generally at a faster rate than you can download it. The end result is that in an apples-to-apples comparison WebAssembly is significantly faster to start than JavaScript.

charcircuit 10mo ago
>WebAssembly is not huge I always feel like I'm downloading megabytes of it whenever someone uses it. In practice it is. Even a basic hello world in rust will set you back a few megabytes compared to a the tens of bytes it takes in javascript. >JavaScript comes with more of a standard library and more of a runtime, which unbalances comparisons. Being able to make programs in a few bytes is a legitimate strength. You can't discount it because it's an effective way javascript saves size.
- chrismorgan 10mo ago
  > Even a basic hello world in rust will set you back a few megabytes Lies. It’s 35 kB: $ cargo new x … $ cd x $ cat src/main.rs fn main() { println!("Hello, world!"); } $ cargo build --release --target=wasm32-unknown-unknown … $ ls -l target/wasm32-unknown-unknown/release/x.wasm … 34597 … And that’s with the default allocator and all the std formatting and panic machinery. Without too much effort, you can get it to under 1 kB, if I remember correctly. For the rest: I mention comparisons being unbalanced because people often assume it will scale at the rate they’ve seen—twice as much code, twice as much size. Runtimes and heavy tables make for non-scaling overhead. That 35 kB you’ve paid for once, and now can use as much as you like without further growth.

tannhaeuser 10mo ago

This, plus after the Godot runtime, game assets itself have to be downloaded, often making use of ZIP-like archive formats that may have made sense with DLCs or physical media, but require huge downloads (like GBs) to access a single sprite when the browser DOM rendering itself is pretty much about priorizing resources as they're viewed. Plus, WASM game runtimes need to bundle redundant 2D or 3D stacks, audio, fonts, harfbuzz, etc. yet don't expose eg. text rendering capabilities on par with those that browsers already have natively. The whole thing is priorizing developer over user experience.

michalsustr 10mo ago

It’s not an issue. When we run LTO optimizations, strip all symbols, we get 2MB compressed for decently complex GPU-accelerated rendering (minfx.ai)

qouteall 10mo ago

WebAssembly standard design has considered binary size optimization. The format itself is quite compact. But porting native code to Wasm often brings many large existing libraries which contain a lot of code which makes the binary large. The native ecosystem never payed attention to binary size optimization, but the JS ecosystem payed attention to code size in the very beginning.

pjmlp 10mo ago
Yes, because compilers and linkers have optimize for size switches since the 1980's for fun.
0x457 10mo ago
It's the fact that WASM in a browser provide very little. Anything you have there required to bring a bunch of things that JavaScript just has access out of the box. That include both, things like Fetch API and things like Garbage Collector. > The native ecosystem never payed attention to binary size optimization, but the JS ecosystem payed attention to code size in the very beginning. That's not true at all. Native ecosystem stopped paying attention to it outside of embed once storage/memory got relatively cheap (i.e. we went from kilo and megabytes to gigabytes). Native also gets to use shared libraries...sometimes. JavaScript ecosystem is like pendulum, sometimes they care, sometimes they don't. I have high hopes for components, both for reducing size and for avoiding JavaScript.