optimize wasm size

[hardfist]

esbuild is a preferct tools as a online browser bundler, but it seems that the wasm size is too large(11M), which makes it harder to put into production environment, is it possible to generate an small size wasm likes esbuild.min.wasm for production use?

[evanw]

What would be your ideal size? I doubt it can be reduced down enough to be satisfactory, so sorry in advance. WebAssembly modules tend to be large in general unfortunately.

I tried running wasm-opt on the output but that only reduced the size by 5% and took quite a while, so I don't think it makes sense to run this optimizer.

One thing I can do is to remove the local server code for the WebAssembly binary. It looks like it doesn't even work anyway so it can just be unconditionally removed. That brings the size down to 8mb. I'm not sure what to do to reduce it further though.

[hardfist]

my ideal size could be 2M-, after some search, it seems that tinygo may could reduce wasm size, but I couldn't build esbuild using tinygo successfully.

[evanw]

Here is one reason (from the TinyGo docs):

The recover builtin is not yet supported. Instead, a panic will always terminate a program and recover simply returns nil.

There are a few different places where esbuild relies on recover so TinyGo is not an option.

I'm going to close this since the size was optimized and I don't think this issue is further actionable. Even if it was possible to get TinyGo to work, I don't expect it to result in a 4x size reduction. It also looks like TinyGo potentially has some pretty severe performance issues:

map keys ... have not been optimized for performance and will cause linear lookup times in some cases

Edit: Feel free to post additional size reduction ideas if you have them.

[evanw]

Had some more random thoughts. I don't think this is actionable but theoretically removing symbol names from the WebAssembly would shrink the size a bit. Also Go's pclntab table (sort of like source maps for Go) is a well-known space issue for Go programs. There isn't a way to disable this but perhaps it could be compressed and/or removed with a custom build of Go or something. Maybe that would work as long as Go never needs to print a stack trace?

Edit: Apparently pclntab can't be removed because it's used for garbage collection according to this.

[hardfist]

remove some debug、trace、print、os specific code may help reduce size？or split the wasm to multi chunks to support concurrent download，or lazy load some part of wasm which is unlikely to be used eagely？

[hardfist]

is it possible to split the wasm to multi wasm chunk, then we can concurrently download multi wasm chunks, something like emscripten-core/emscripten#11753