Sparked by:
cc @gnzlbg
Should we downgrade the asmjs / emscripten target?
2 Likes
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 asm.js-unknown-emscripten over wasm32-unknown-emscripten?
1 Like
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.
5 Likes
There are WebAssembly polyfills for asm.js browsers.
1 Like
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).
13 Likes
On Reddit: https://www.reddit.com/r/rust/comments/bejkm0/should_we_downgrade_drop_the_asmjs_target/
On users.r-l.o: https://users.rust-lang.org/t/should-we-downgrade-drop-the-asmjs-target/27379
1 Like
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.
7 Likes
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.
8 Likes
Are any users utilizing this for IE11 right now tho?
1 Like
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.
5 Likes
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.
6 Likes
It does not seem very reasonable to have a second implementation of a complex data structure for exactly one obscure target.
13 Likes
I just spoke with someone involved in wasm2js, and apparently it was just finished in the last few weeks. They mentioned that it should now give results sufficiently good to avoid needing to generate JavaScript directly. Could someone give it another try with the latest version?
2 Likes
I fixed the libc crate for asm.js a couple of weeks ago, this buys more time to make a decision here.
The question isn’t whether asm.js can potentially be useful or not. The libc crate was broken for this target for ca. 6 months, and nobody complained. If nobody is using the target, expending effort maintaining it feels like wasted effort.
4 Likes
@CryZe Could you retest wasm2js please, and see if it’s sufficiently good at this point to make the asmjs-emscripten target unnecessary?
3 Likes
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.