Здравствуйте, igor-booch, Вы писали:

IB>Не соглашусь, что это неприемлемо для корпоративных пользователей. Если загрузка WebAssembly приложения и .NET runtime происходит 1 раз, когда сотрудник начинает работать с приложением (при приёме на работу), то ничего плохого не вижу. По идее системный администратор должен выдать железо с уже настроенным ПО. Плохо это как раз для не корпоративных пользователей, например для интернет магазина. Человеку что бы посмотреть товары придётся подождать. Может не хватить терпения и он перейдёт в магазин который покажет товары быстрее. Хотя если .NET runtime уже загружен время ожидания минимально, так как, насколько я знаю, в WebAssembly планируется загрузка по частям (по требованию). Загрузили начальный экран, показали пользователю. Дальше в фоне грузим остальную часть приложения.

Там нет .NET runtime, Там Mono который интерпретирует код. А моно небольшой 60KB
https://github.com/aspnet/Blazor/wiki/FAQ

Не будет ли размер загрузки приложения огромным, если он также включает среду выполнения .NET?

Не обязательно. .NET среды выполнения бывают разных форм в размерах. В ранних прототипах Blazor использовалась компактная среда выполнения .NET (включая сборку, сборку мусора, многопоточность), которая компилировалась всего в 60 КБ WebAssembly. Blazor теперь работает на Mono, который в настоящее время значительно больше, но возможностей для оптимизации размера предостаточно, включая слияние и обрезку исполняемых файлов и двоичных файлов приложений. Другие потенциальные меры по уменьшению размера загрузки включают кэширование и использование CDN.

Здравствуйте, igor-booch, Вы писали:

IB>Не соглашусь, что это неприемлемо для корпоративных пользователей. Если загрузка WebAssembly приложения и .NET runtime происходит 1 раз, когда сотрудник начинает работать с приложением (при приёме на работу), то ничего плохого не вижу. По идее системный администратор должен выдать железо с уже настроенным ПО. Плохо это как раз для не корпоративных пользователей, например для интернет магазина. Человеку что бы посмотреть товары придётся подождать. Может не хватить терпения и он перейдёт в магазин который покажет товары быстрее. Хотя если .NET runtime уже загружен время ожидания минимально, так как, насколько я знаю, в WebAssembly планируется загрузка по частям (по требованию). Загрузили начальный экран, показали пользователю. Дальше в фоне грузим остальную часть приложения.

Там нет .NET runtime, Там Mono который интерпретирует код. А моно небольшой 60KB
https://github.com/aspnet/Blazor/wiki/FAQ

Не будет ли размер загрузки приложения огромным, если он также включает среду выполнения .NET?

Не обязательно. .NET среды выполнения бывают разных форм в размерах. В ранних прототипах Blazor использовалась компактная среда выполнения .NET (включая сборку, сборку мусора, многопоточность), которая компилировалась всего в 60 КБ WebAssembly. Blazor теперь работает на Mono, который в настоящее время значительно больше, но возможностей для оптимизации размера предостаточно, включая слияние и обрезку исполняемых файлов и двоичных файлов приложений. Другие потенциальные меры по уменьшению размера загрузки включают кэширование и использование CDN.

Здесь пишут так
https://docs.microsoft.com/ru-ru/aspnet/core/blazor/?view=aspnetcore-3.0

Когда клиентское приложение Blazor создается и запускается в браузере:
Файлы кода C# и файлы Razor компилируются в сборки .NET.
Сборки и среда выполнения .NET загружаются в браузер.
Blazor на стороне клиента осуществляет начальную загрузку среды выполнения .NET и настраивает ее для загрузки сборок для приложения. Среда выполнения Blazor на стороне клиента использует взаимодействие с JavaScript для обработки операций с моделью DOM и вызовов API браузера.
Размер опубликованного приложения, известный как размер полезных данных, является критически важным фактором производительности для удобства работы с приложением. Крупное приложение скачивается в браузере довольно долго, что ухудшает взаимодействие с пользователем. Blazor на стороне клиента оптимизирует размер полезных данных, чтобы сократить время скачивания:
При публикации неиспользуемый код исключается из приложения компоновщиком промежуточного языка.
HTTP-ответы сжимаются;
среда выполнения и сборки .NET кэшируются в браузере.