Search code examples
blazorwebassemblyblazor-client-side

Blazor webassembly applications and detecting browser capabilities


I am new to Blazor/WebAssembly and love the technology but do not understand reasons behind certain implementation details.

For example, if user navigates to client-side Blazor/WebAssembly application created by Visual Studio wizard using browser that doesn't support WebAssembly (i.e. IE 11) the website will just display

Loading...

forever.

The reason for that is clear but why did Microsoft implement it this way? Wouldn't it be much better and more informative to try to detect whether browser supports WebAssembly and if it doesn't - redirect user to another static page explaining the reason (i.e. something that says "Your browser does not support WebAssembly, please use Chrome v. XX or above, Edge v. XX or above, etc")?


Solution

  • I'm not Microsoft employee, but in my opinion, they implement it like that for following reasons.

    a) MS is provider of tools and technologies which enable developers. As such they do not make decisions for developers what to do. They usually do not create "opionated" frameworks. And display message with "unsupported" is explicit opinion on their side. It does not make sense for all their customers to have that message. What if somebody willing to make that work on IE11 and they stop them?

    b) Implementing it like that require zero effort. This is benefit on itself. If they have bullet proof solution in their mind, I have zero doubts they implement it if they want to support that. Right now since it is not-supported, it is developers responsibility to provide appropriate UX for end-users. It's up to developer to decide how to handle IE. Provide message with statement that IE11 is not supported, Add poilyfills like https://github.com/Daddoon/Blazor.Polyfill to somewhat support IE11, or switch to different technology. If MS will give solution which will display message, it require other developers who want to have polyfill, or switch to different technology to actively disable such checks, and it require more moving parts to be implemented, just for unsuppported platform. It simply does not make sense.

    c) Requirement for support on IE11 is dropping and investing in supporting this market probably not worth for them to look at. Technology with WebAssembly do not mature enough and they what to ship something only in first half of 2020, how much IE11 will be by then? And that's only first iteration, and other important milestones pushed even later, so likely IE11 does not worth efforts.