Should we downgrade the asmjs / emscripten target?
It would probably make sense to advertise that we want people using this target to give us feedback, so it might make sense to cross-link this from
users.rust-lang.org and reddit as well.
It would be interesting to know what the plans of
emscripten itself are with respect to this target - is it going to be supported for the reasonable future or are people migrating to
wasm32-unknown-emscripten ?. It might be worth it to query
emscripten maintainers here too.
What’s the advantage of
What’s the advantage of asmjs-unknown-emscripten over wasm32-unknown-emscripten?
An obvious advantage is that it works on browsers not supporting WebAssembly, such as IE, which still has significant market share.
There are WebAssembly polyfills for asm.js browsers.
Is WebAssembly + polyfill better than asm.js? How do they compare?
It’s not better; it’s more a question of how much maintenance effort we’d want to put into a backend solely for one legacy browser (and one for which the company maintaining it says not to use it anymore).
WebAssembly polyfills are impractically slow. There is a translator from WASM to asm.js, wasm2js, but I’m not sure how complete/functional it is.
At about 6 months ago the company I worked at still used asm.js instead of WASM because it works everywhere, as fast as WASM and you don’t have to do an extra async dance to load it. I don’t work there anymore so I can’t comment on the current state.
If wasm2js actually works, they wouldn’t miss the asm.js backend. The asm.js<->js bindings would have to be updated/rewritten, but that’s a one-off operation. However, if wasm2js is not actually reliable, they’d have to stick with an old rustc version just to keep their product working, and older rustc versions are not supported by anyone, even for security updates. That’s a pretty bad place to be in.
Yeah you summarized it perfectly. asmjs-emscripten is the only feasible way to compile for IE11 (and even IE10) right now and those are unfortunately very real use cases still. Therefore I truly do not want this target removed until there is a proper replacement. And last I checked wasm2js emitted a broken / incomplete 500+ MiB JS file out of my 1 MiB wasm file, which wasn’t even minifyable because the enormous size completely broke uglifyjs (stack overflow). And the runtime polyfills that run the actual wasm file are incredibly slow, so they are not realistically feasible either. Fortunately emscripten is now putting in a huge amount of effort into wasm2js in order to be able to switch over to it themselves, so I’m expecting wasm2js to be a feasible option soon.
I will evaluate the current situation more accurately during the next few days and report back.
Are any users utilizing this for IE11 right now tho?
Medical industry does not like to upgrade anything and based on past work experience, old versions of IE are still pervasive and required to work around if you want to work with medical software. Whether the way these industries use these old browsers makes it a valid concern for rust is a different story though.
If we merely stop adding new features or improvements to asmjs, then it’ll be fine. AFAIK this is about a new hashtable implementation. Can we keep the old one for asmjs?
But if we decide to drop asmjs completely, that may not be a good look for Rust from stability/maturity point of view.
Currently, staying on an old version of the Rust compiler is impractical (there’s no official support, and the crates ecosystem moves to newer versions quickly). We say it’s fine, because the compiler is very backwards-compatible, so it’s possible to have a stable, long-lived project while continuously upgrading the compiler. If we drop asm.js, that will no longer be true for projects that built on Rust and asm.js.
So unless there are literally 0 users of asm.js, we need to be careful not to break the “stability without stagnation” promise.
It does not seem very reasonable to have a second implementation of a complex data structure for exactly one obscure target.