5 ms·

One problem with golang's wasm target is that the generated binary is huge. For instance, I checked app.wasm of this documentation site and the four examples li

by oefrha 5y ago

One problem with golang's wasm target is that the generated binary is huge. For instance, I checked app.wasm of this documentation site and the four examples listed at https://go-app.dev/built-with https://go-app.dev/built-with: 0. This site: 14.9MB, 3.4MB gzipped; 1. 13.5MB, 3.2MB gzipped; 2. 15.4MB, 3.2MB gzipped; 3. 4.7MB, 1.2MB gzipped (this is an extremely bare bones demo); 4. 25.0MB, 5.4MB gzipped. You can save a bit more with brotli, but not much more. I built an app with golang wasm last year, but ended up rewriting everything in good old TS since I couldn't justify the ~15MB raw, ~2.7MB brotli'ed payload. I guess you can make some huge savings if tinygo has enough capabilities to cover all your needs. Not sure if it's possible with this library, but if it is, they certainly haven't explored it, hence the 3.4MB gzipped wasm for a documentation site.

donatj 5y ago
The “good” news in my experience is that they don’t seem to usually get much larger than 15mb, I’m guessing it’s the wall you hit once most of the standard library is already included. It’s certainly not enviable, but I have absolutely seen sites with an equal volume of JS, so it’s not unheard of.
chrismorgan 5y ago
One thing for old-school performance comparers to remember here is that WASM is very significantly cheaper than JavaScript to parse and compile. On an arbitrary fairly weak phone, 15MB of WASM might take two seconds to compile, but it can do that while downloading, so that in practice your network link will probably be the limiting factor. So the transfer size is typically the figure to care about and the uncompressed size actually doesn’t matter all that much. 15MB of JavaScript on that same device might take ten seconds or even more to compile, and it largely can’t even start until it’s finished downloading it. Consequently, you need to care about both the transfer size and the uncompressed size, in different ways. (My figures are super dodgy as I can’t find any recent concrete figures, but they should be in vaguely the right ballpark.) This is all about comparing just the cost to the CPU; data transfer costs money too and takes time, and several megabytes transferred is inconvenient to many for reasons of cost or time, and decidedly wasteful. Multiple megabytes even of WASM is still madness and folly for simple stuff like this, severely restricting its potential usefulness. Thank you for deciding not to ship something like that yourself.
- mumphster 5y ago
  That applies if youre shipping a giant 15 meg blob of js (not saying some sites dont do this), a lot of the size also comes from css and other assets which still apply with shipping a wasm blob. I'm gonna guess that v8 can parse a 1-2 meg js file just as fast if not faster than the time it takes to download a 15 meg wasm blob or a 4 meg blob + decompress + parse outputted from golang. Like your last line says, shipping 15 megs of any kind of code makes no sense to me
  - chrismorgan 5y ago
    When considering performance, some people presume that WASM is much the same as JavaScript; I’m just reminding them that this is not the case: WASM has better loading characteristics than JavaScript so that its cost per byte is much more like that of images than of JavaScript.
- oefrha 5y ago
  As mumphster pointed out in a sibling, 15MB of wasm vs 15MB of javascript is an unfair comparison. For instance, my aforementioned app is a few hundred KB of uncompressed js when rewritten, not 15MB. Also, in my experience, a 15MB wasm blob has shit caching characteristics; it gets evicted all the time. An immutable few hundred KB js blob, on the other hand, can remain cached for much longer. Sure, you can use a service worker and its Cache API to make caching large blobs more predictable, but then shipping new code / cache invalidation becomes more annoying.
andreygrehov 5y ago
Genuine question. What's the underlying issue behind this concern? When I'm reading your numbers, my first reaction is that 5-15MB these days is peanuts. What use cases am I missing?
- travisd 5y ago
  In web contexts, we usually shoot for sub 1MB (ideally ~250kb for static sites). The main reason is usually just optimizing for mobile experiences. People expect to wait a while to download a 200MB app, but if you have to wait 5s for a webpage you’re very likely to click away. Of course it’s partially a function of your target audience. Notion and Retool (for example) are able to ship massive multi megabyte bundles because they’re productivity apps targeted mostly towards people with desktops and high speed internet connections. If HN were to ship a 15MB bundle it’d be virtually unusable on mobile for a lot of people (myself included, and I live in Seattle!).
  - andreygrehov 5y ago
    I agree. I'm all for static, low-size websites and that is something I always strive for. But, the internet speed keeps improving. 5MB app won't take 5s to load these days. 1 megabit-per-second connection needs 8 seconds to load 1MB. Most internet providers offer 300Mbit/s minimum ($39/month). But even with 50Mbit/s channel, it'll only take 0.8s to load 5MB.
    - mattnewton 5y ago
      It very well might depending on the audience and the percentile you target. 90th percentile times show that those larger speeds are not consistent, often showing a bifurcated distribution where the tail is experiencing loss / latency that compounds the more request and the larger they are. Of course if the development benefits for your team outweigh it, it makes sense to do it. Just mean to say advertised cellphone connection speeds are not a reliable benchmark to hit.
    - hbn 5y ago
      Not everyone has access to all options from internet providers. There's people on slow, satellite internet. Hell, there's still a non-negligible amount of people still using dial-up in the US. https://www.statista.com/statistics/185532/us-household-dial-up-internet-connection-usage-by-state-2009/ https://www.statista.com/statistics/185532/us-household-dial... (URL says 2009, but it was updated with statistics for 2019)
da39a3ee 5y ago
Does anyone know how wasm binary sizes produced from other language toolchains compares? (For example Rust)
- justinclift 5y ago
  Depends on the language, and tool chain used to generate the wasm. Most LLVM generated binaries, including Rust by default from memory, turn out pretty small. Really wish Go had some kind of parameter that let it take extra time compiling "production" builds, such that it would significantly optimise their resulting size.
void_mint 5y ago
> but ended up rewriting everything in good old TS since I couldn't justify the ~15MB raw, ~2.7MB brotli'ed payload. What were the size improvements?
nikki93 5y ago
When I've tried it out for wasm game development, the biggest issue I had was frequent GC pauses (was a few every second) causing frame drops. TinyGo gets at this issue. I've used C++ since then, focusing on a small subset that keeps things flexible and compiling fast. Been hacking on a Go -> C++ compiler lately that produces that subset.
brundolf 5y ago
The focus on PWAs probably helps a little bit since there's the expectation of more local cache hits

by oefrha 5y ago

donatj 5y ago

The “good” news in my experience is that they don’t seem to usually get much larger than 15mb, I’m guessing it’s the wall you hit once most of the standard library is already included. It’s certainly not enviable, but I have absolutely seen sites with an equal volume of JS, so it’s not unheard of.

chrismorgan 5y ago

One thing for old-school performance comparers to remember here is that WASM is very significantly cheaper than JavaScript to parse and compile. On an arbitrary fairly weak phone, 15MB of WASM might take two seconds to compile, but it can do that while downloading, so that in practice your network link will probably be the limiting factor. So the transfer size is typically the figure to care about and the uncompressed size actually doesn’t matter all that much. 15MB of JavaScript on that same device might take ten seconds or even more to compile, and it largely can’t even start until it’s finished downloading it. Consequently, you need to care about both the transfer size and the uncompressed size, in different ways. (My figures are super dodgy as I can’t find any recent concrete figures, but they should be in vaguely the right ballpark.) This is all about comparing just the cost to the CPU; data transfer costs money too and takes time, and several megabytes transferred is inconvenient to many for reasons of cost or time, and decidedly wasteful. Multiple megabytes even of WASM is still madness and folly for simple stuff like this, severely restricting its potential usefulness. Thank you for deciding not to ship something like that yourself.

mumphster 5y ago
That applies if youre shipping a giant 15 meg blob of js (not saying some sites dont do this), a lot of the size also comes from css and other assets which still apply with shipping a wasm blob. I'm gonna guess that v8 can parse a 1-2 meg js file just as fast if not faster than the time it takes to download a 15 meg wasm blob or a 4 meg blob + decompress + parse outputted from golang. Like your last line says, shipping 15 megs of any kind of code makes no sense to me
- chrismorgan 5y ago
  When considering performance, some people presume that WASM is much the same as JavaScript; I’m just reminding them that this is not the case: WASM has better loading characteristics than JavaScript so that its cost per byte is much more like that of images than of JavaScript.
oefrha 5y ago
As mumphster pointed out in a sibling, 15MB of wasm vs 15MB of javascript is an unfair comparison. For instance, my aforementioned app is a few hundred KB of uncompressed js when rewritten, not 15MB. Also, in my experience, a 15MB wasm blob has shit caching characteristics; it gets evicted all the time. An immutable few hundred KB js blob, on the other hand, can remain cached for much longer. Sure, you can use a service worker and its Cache API to make caching large blobs more predictable, but then shipping new code / cache invalidation becomes more annoying.

andreygrehov 5y ago

Genuine question. What's the underlying issue behind this concern? When I'm reading your numbers, my first reaction is that 5-15MB these days is peanuts. What use cases am I missing?

travisd 5y ago
In web contexts, we usually shoot for sub 1MB (ideally ~250kb for static sites). The main reason is usually just optimizing for mobile experiences. People expect to wait a while to download a 200MB app, but if you have to wait 5s for a webpage you’re very likely to click away. Of course it’s partially a function of your target audience. Notion and Retool (for example) are able to ship massive multi megabyte bundles because they’re productivity apps targeted mostly towards people with desktops and high speed internet connections. If HN were to ship a 15MB bundle it’d be virtually unusable on mobile for a lot of people (myself included, and I live in Seattle!).
- andreygrehov 5y ago
  I agree. I'm all for static, low-size websites and that is something I always strive for. But, the internet speed keeps improving. 5MB app won't take 5s to load these days. 1 megabit-per-second connection needs 8 seconds to load 1MB. Most internet providers offer 300Mbit/s minimum ($39/month). But even with 50Mbit/s channel, it'll only take 0.8s to load 5MB.
  - mattnewton 5y ago
    It very well might depending on the audience and the percentile you target. 90th percentile times show that those larger speeds are not consistent, often showing a bifurcated distribution where the tail is experiencing loss / latency that compounds the more request and the larger they are. Of course if the development benefits for your team outweigh it, it makes sense to do it. Just mean to say advertised cellphone connection speeds are not a reliable benchmark to hit.
  - hbn 5y ago
    Not everyone has access to all options from internet providers. There's people on slow, satellite internet. Hell, there's still a non-negligible amount of people still using dial-up in the US. https://www.statista.com/statistics/185532/us-household-dial-up-internet-connection-usage-by-state-2009/ https://www.statista.com/statistics/185532/us-household-dial... (URL says 2009, but it was updated with statistics for 2019)

da39a3ee 5y ago

Does anyone know how wasm binary sizes produced from other language toolchains compares? (For example Rust)

justinclift 5y ago
Depends on the language, and tool chain used to generate the wasm. Most LLVM generated binaries, including Rust by default from memory, turn out pretty small. Really wish Go had some kind of parameter that let it take extra time compiling "production" builds, such that it would significantly optimise their resulting size.

void_mint 5y ago

> but ended up rewriting everything in good old TS since I couldn't justify the ~15MB raw, ~2.7MB brotli'ed payload. What were the size improvements?

nikki93 5y ago

When I've tried it out for wasm game development, the biggest issue I had was frequent GC pauses (was a few every second) causing frame drops. TinyGo gets at this issue. I've used C++ since then, focusing on a small subset that keeps things flexible and compiling fast. Been hacking on a Go -> C++ compiler lately that produces that subset.

brundolf 5y ago

The focus on PWAs probably helps a little bit since there's the expectation of more local cache hits