Hacker News Reader

Comment by yumaikas | Hacker News Reader

Eh, there isn't any reason that it couldn't at some point in the future. That won't be happening any time soon, but I'd love to see that day, personally.

View on HN

Lack of GC in WASM would make that difficult right now.

But yes, that's the future I'd like to see. Browsers only have a WASM engine, and provide a JS->WASM compiler client-side for backwards compatibility.

GC is just something you implement on the language runtime.

Then you're shipping the entire (or at least large pieces of) language runtime to the client since presumably, you'd need to compile that to WASM as well.

You can probably fit the runtime in a 10th of the size of JQuery.

You'll need most of a runtime anyway, since it provides much more than GC.

Something that never really worked was cached versions of jquery (and similar) from cdn. One reason is that browsers didn't give them any particular precedence. The other was that jquery was moving quite fast compared to devs using it so as an end user i nearly never benefited from the caching. I wonder if this might work better for language run times. Maybe browsers could be provided with some manifest saying 'this site needs python 3+' or 'this site needs python 3-3.5' so that end users end up with less runtimes cached.

Given that runtimes like Lua are comparable in size to a single image, and/or could be cached in web browsers, I don't think that will much of a problem. And the more that WebAssembly adds, the smaller that will get.

Obviously if we're trying to run a full JVM or CLR in WebAssembly, that will cause problems, but C# and F# both have compile-to-js targets that would likely just get faster.

Reply on news.ycombinator.com