4 ms·

I’ve not seen much WebAssembly “done right” to date; IME it is most often employed to spew gargantuan legacy C++ applications verbatim into the browser to avoid

I’ve not seen much WebAssembly “done right” to date; IME it is most often employed to spew gargantuan legacy C++ applications verbatim into the browser to avoid having to understand which parts are actually desired, whether and how they can be unpicked from the rest, and whether they are trivial enough to actually just reimplement in Javascript or otherwise as standalone modules. This does not bode well for the utopia of small clean blobs you propose, though I do agree it would be nice if it came to pass. I am perhaps too pessimistic here; wasm is young and has still to develop much of its own culture. I shall watch that space with interest.

Grollicus 9y ago
Don't worry. If we've managed to blow our binaries up to 100s of MB, we can do it with our websites, too! (Seriously. Chromium is 124MB. How does anyone think web dev will go differently?)
- tluyben2 9y ago
  We will never go back ; there is only a tiny niche group (embedded, retro and demoscene) that cares about tiny and efficient. The rest simply wants to deliver features fast. On their (I include myself in that often) island, most reason that computers are fast enough and have enough memory. But that arguments really does not take into account things like: multitasking (if all devs think like that, what happens when you run 20 apps at the same time?) and, in many cases, battery life (that does not have to be the case; bloat does not have to hog cpu but often does).
  - mwcampbell 9y ago
    It's better yet if we can deliver features fast with internationalization, accessibility, security, maintainability, and so on. Whenever I dabble in retro computing, usually via emulation, I appreciate how much progress we've really made. And if a phone needs 2 GB of RAM, and a laptop needs 8, well, the world has much bigger problems.
flohofwoe 9y ago
Check out these samples: https://floooh.github.io/sokol-html5/ https://floooh.github.io/sokol-html5/, the wasm blobs there are between 8 KByte (for the clear sample) and 210 KByte (for the ImGui sample), all compressed size as downloaded by the brower. Most of the samples are done in C, the ImGui sample is C++. You have to pick the right C++ subset ("Modern C++" is pretty much what not to do if you care about binary size, instead use the C++ subset that's common in the embedded world). It's much easier to write slim code in C since this is a much simpler language and it's not so easy to hide a lot of crap under 'abstractions'. Of course if the C++ codebase is already bloated that's impossible to get small for WebAssembly. Common sense is still required (which is unfortunately very rare in the modern programming world).
steveklabnik 9y ago
Historically, Emscripten produces pretty large binaries, but that's because it's also trying to make transitioning from desktop code to the web easy; therefore it includes a bunch of its own runtime. They've been doing a lot of work to cut it down lately. As wasm grows, and this becomes more of a focus, it should get really small. On the other hand, LLVM's new backend means you can skip that runtime and get very tiny binaries; the smallest file I've gotten rustc to produce when compiling to wasm is just over 100 bytes.

Grollicus 9y ago

Don't worry. If we've managed to blow our binaries up to 100s of MB, we can do it with our websites, too! (Seriously. Chromium is 124MB. How does anyone think web dev will go differently?)

tluyben2 9y ago
We will never go back ; there is only a tiny niche group (embedded, retro and demoscene) that cares about tiny and efficient. The rest simply wants to deliver features fast. On their (I include myself in that often) island, most reason that computers are fast enough and have enough memory. But that arguments really does not take into account things like: multitasking (if all devs think like that, what happens when you run 20 apps at the same time?) and, in many cases, battery life (that does not have to be the case; bloat does not have to hog cpu but often does).
- mwcampbell 9y ago
  It's better yet if we can deliver features fast with internationalization, accessibility, security, maintainability, and so on. Whenever I dabble in retro computing, usually via emulation, I appreciate how much progress we've really made. And if a phone needs 2 GB of RAM, and a laptop needs 8, well, the world has much bigger problems.

flohofwoe 9y ago

Check out these samples: https://floooh.github.io/sokol-html5/ https://floooh.github.io/sokol-html5/, the wasm blobs there are between 8 KByte (for the clear sample) and 210 KByte (for the ImGui sample), all compressed size as downloaded by the brower. Most of the samples are done in C, the ImGui sample is C++. You have to pick the right C++ subset ("Modern C++" is pretty much what not to do if you care about binary size, instead use the C++ subset that's common in the embedded world). It's much easier to write slim code in C since this is a much simpler language and it's not so easy to hide a lot of crap under 'abstractions'. Of course if the C++ codebase is already bloated that's impossible to get small for WebAssembly. Common sense is still required (which is unfortunately very rare in the modern programming world).

steveklabnik 9y ago

Historically, Emscripten produces pretty large binaries, but that's because it's also trying to make transitioning from desktop code to the web easy; therefore it includes a bunch of its own runtime. They've been doing a lot of work to cut it down lately. As wasm grows, and this becomes more of a focus, it should get really small. On the other hand, LLVM's new backend means you can skip that runtime and get very tiny binaries; the smallest file I've gotten rustc to produce when compiling to wasm is just over 100 bytes.