I'm also excited to see where this leads.

From the release notes:

> Go programs currently compile to one WebAssembly module that includes the Go runtime for goroutine scheduling, garbage collection, maps, etc. As a result, the resulting size is at minimum around 2 MB, or 500 KB compressed.

The minimum size is a bit unfortunate, but after all it is still just experimental.

I imagine it would be possible to do some dead code elimination in the future to get the size down. Still, 500KB is roughly the size of a lot of the real world apps[0]. I'd imagine an equivalent app, written in Go would be around double, given this baseline number. Double isn't soo bad, but it would be nice to get this number down.

[0] https://github.com/gothinkster/realworld

The Go linker does dead code elimination already.

Dead code elimination can happen in many places. In Go, for instance, an obvious one would be to eliminate most type info for types which will never be queried for introspection.

No linker will ever do that.

> 500 KB compressed.

WASM has significantly less parse penalty than javascript. A larger bundle size than your accustomed to with pure js is not necessarily a problem.

https://blog.figma.com/webassembly-cut-figmas-load-time-by-3...

https://hacks.mozilla.org/2018/01/making-webassembly-even-fa...

The minimum is large, but if you compare it to mainstream js frameworks, it doesn't look that large. (Source: https://gist.github.com/Restuta/cda69e50a853aa64912d). There are several frameworks with size over 100K compressed.

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>

Would it be possible to make use of the built in JavaScript garbage collector (I'm assuming not) and/or separate to the Go runtime into some kind of shared linked lib so that at least you only pay the download cost once?

(Of course that would open up all the sorts of issues that static compiles get rid of.)

The JS garbage collector would be unlikely to work for Go since Go allows pointers into the middle of an object and JS doesn't.

“Make use of the JS GC” is a feature planned for, but not yet accepted or implemented in webassembly.

yes but Go doesn't plan to do that, they feel their GC is better.

You can also use C or Rust and avoid GC altogether. Rust produces very small WASMs

Yeah it does seem an unlikely fit for go.

I imagine that go to wasm would likely be used for situations where size won't matter too much and will be an acceptable trade off for familiarity or code reuse.