我是Blazor / WebAssembly的新手，并且热爱这项技术，但不了解某些实现细节背后的原因。
例如，如果用户使用不支持WebAssembly（即IE 11）的浏览器导航到Visual Studio向导创建的客户端Blazor / WebAssembly应用程序，则该网站只会显示
Loading...
永远。
原因很明确，但是Microsoft为什么要以这种方式实现它？尝试检测浏览器是否支持WebAssembly会更好，更有用，如果不是，请-将用户重定向到另一个静态页面以说明原因（例如，“您的浏览器不支持WebAssembly，请使用Chrome v。XX或更高版本，Edge v。XX或更高版本，等等“）？
我不是Microsoft员工，但我认为，出于以下原因，他们之所以这样实施。
a）MS是使开发人员能够使用的工具和技术的提供者。因此，他们不会为开发人员制定决策。他们通常不创建“ opionated”框架。而显示带有“不支持”的消息是他们的明确意见。他们所有的客户都没有该信息。如果有人愿意在IE11上进行该工作并阻止了他们该怎么办？
b）做到这一点需要零的努力。这本身就是好处。如果他们心中有防弹解决方案，那么我可以毫无疑问地实现他们想要的支持。现在，由于不受支持，开发人员有责任为最终用户提供适当的UX。由开发人员决定如何处理IE。在消息中提供不支持IE11的声明，添加https://github.com/Daddoon/Blazor.Polyfill之类的填充以某种程度上支持IE11，或切换到其他技术。如果MS提供显示消息的解决方案，则它要求其他想要使用polyfill的开发人员，或切换到其他技术来主动禁用此类检查，并且它仅针对unsuppported平台，需要实施更多的移动部件。这根本没有道理。
c）对IE11的支持需求正在下降，并且投资支持该市场可能对他们而言并不值得。 WebAssembly的技术还不够成熟，它们只能在2020年上半年交付什么产品，那么到那时IE11将会有多少？而且那只是第一次迭代，其他重要的里程碑甚至推后了，因此IE11可能不值得付出努力。