2 ms·
> because WASM does have a tendency to make big code blobs easier to produce, especially if you’re using generics liberally. WASM was designed to be compiled t
by brabel 7y ago
> because WASM does have a tendency to make big code blobs easier to produce, especially if you’re using generics liberally.
WASM was designed to be compiled to very small binaries. The big code blobs you see are produced by the Rust compiler and are not a characteristic of WASM... just check the output of the Rust compiler for a hello world project in WAT format and you'll see it consists almost entirely of the memory allocator that's included in the binary...if you write the same code in WAT directly, or something like AssemblyScript[1], which is designed to use WASM primitives, it's going to be a few bytes for your typical WASM hello world.
[1] https://docs.assemblyscript.org/ https://docs.assemblyscript.org/
- chrismorgan 7y agoI’m not talking about the constant overheads, but how WASM grows as you scale your code base. My experience is that in practice it tends to be grow a little faster than equivalent JavaScript, say 1.2–2× the size depending on what you’re doing. But I should definitely have clarified that I was speaking specifically in the context of Rust—my generics remark certainly only makes sense in that context. It’s not fundamentally terribly much larger, and can definitely be smaller (again, depending on what you’re doing), but using it as a compilation target makes it much easier to produce binaries larger than you anticipated. In JavaScript you distribute what you wrote, so you know if you loaded a lot more code. Well, in theory. Code bundlers and liberal importing of third-party libraries kinda put paid to that.