I would say being 20x larger than the largest JS framework is pretty significant. There's a lot of use-cases that are simply not plausible if you need to wait for 2mb to download.

Maybe they can use some DCE to get it smaller, idk. Go binaries have never been that small so I have my doubts, but hopefully!

EDIT: I see the release notes now that says 500k compressed. That's much better. I didn't realize webassembly could be compressed, is this just gzip?

The difference between 123k and 500k is ~4x, not ~20x, no?

Yeah, not sure if you caught this before my edit, but I didn't see the release notes that said 500k at first. I didn't realize that webassembly could be gzipped and get that much savings.

But that's the minimum, i.e. a Hello World. A Go framework that actually has the same level of functionality would surely be much larger. And besides, JS libraries of that size are a bad thing - JS developers have spent a long time working on things like code splitting to get page load times as low as possible. It'll be a huge shame if we throw all that out with WebAssembly.

I mean, this is a limitation of Go. With JS, the "runtime" is in your browser, you've got a beautiful JS engine already. With Go, it would need that runtime bundled. Similar to shipping the JVM with your JAR.

This isn't a limitation we'd see with something like Rust.

> Similar to shipping the JVM with your JAR.

The size of the Java Runtime Environment is around 80 MB (compressed). Even with Jigsaw and just the "java.base" module its still 13 MB (compressed).

You'd add size when you include whatever DOM abstraction you wind up going with, but at the same time you wouldn't need to add much else because the Go stdlib is pretty complete. On the other hand JS developers are adding Lodash and other utility things that Go already comes with.

Well these days people are using tree-shaking and ES6 imports to only include the lodash functions they actually need.

My point isn't that Go should be banned from WASM or something, but that "5x increase in library size for zero functionality sounds fine" is a disappointing view to see given how hard the JS community has worked on bundle sizes.

You are comparing some MVC frameworks that brings a lot of functionalities with basically a runtime that does nothing on its own. Compare functionalities AND weight instead, otherwise it makes little sense.

You could argue that you should add the JS / browser runtime to those libraries too, then.

> You could argue that you should add the JS / browser runtime to those libraries too, then.

No, since they are already in the browser at first place. That's the point. I don't need any extra runtime to run JS in the browser.

I don’t understand why you would in this comparison, as it’s the same for both WebAssembly and <js framework here>