I am trying to run blazor application in Internet Explorer. On blazor page is written there is a fallback into asm.js for browsers without webassembly support. But when I load page in IE (with blazor.pollyfil.js script linked), I just get error "Browser does'n support WebAssembly".
I am able to run application in server mode (SignalR connection to rendering server), but it is solution for all browsers and the main benefit (WebAssembly) disappears.
Is there really way how to correctly fall back to asm.js mode in (only) Internet Explorer?
Support for asm.js was intentionally removed from Blazor in this commit: https://github.com/aspnet/Blazor/commit/4006cd543900fcc1cf76cd75a1b24007e60c8a67 . If I understand correctly, getting asm.js support back from stock blazor would require the mono project to start including an asm.js build in its binary distribution and for the Blazor project to add that back to its build/deploy tooling.
I haven’t tried it, but it might be possible to build mono for asm.js yourself and inject it into your built Blazor application as part of your own deploy process.
If I understand correctly, Blazor still runs using mono’s interpreted mode, so supplementing the wasm build of mono with an asm.js one might still be sufficient. If Blazor switches to actually compiling assemblies to wasm directly in the future, things will become more complicated.
Blazor supports server-side hosting mode. You already mentioned this in your question, but I am discussing this here in case others skipped over that. In server hosting mode, the client only needs to be able to run “traditional” JavaScript (though it may need polyfills). This can be made to work in IE11 and other clients lacking wasm support. Of course, this takes more resources on the server, prevents the client from supporting offline scenarios, and is basically like a glorified telnet session. But this may be sufficient for LOB applications.