Я хотел бы начать использовать блейзер, несмотря на то, что он все еще находится на альфа-уровне. Насколько я понимаю, blazor использует WebAssembly для компиляции С# на стороне клиента. И у меня есть вопрос: эта система быстрее работает, чем, например, React/Vue, скомпилированная в JavaScript? Правда ли, что браузеру необходимо будет загружать библиотеку Webassembly каждый раз, когда загружается страница? В Интернете нет сопоставлений производительности популярных JS-фреймворков, поэтому я хотел бы узнать теоретические характеристики новой структуры Microsoft. заранее спасибо
Эффект Blazor
Ответ 1
Правда ли, что браузер должен будет загрузить веб-сборку? библиотека каждый раз, когда страница загружается?
Нет, браузеры могут кэшировать файлы. Общий CDN для приложений Blazor сделает свое дело.
Работает ли эта система быстрее, чем, например, React/Vue, скомпилированная в JavaScript?
Blazor использует веб-сборку. На бумаге веб-сборка должна выполняться быстрее, чем любая библиотека js, однако не во всех браузерах есть зрелый анализатор веб-сборок. Таким образом, вы можете обнаружить, что браузеры не будут запускать веб-сборку с оптимальной скоростью на данный момент.
Вы можете создать небольшое приложение Blazor и запустить его в Firefox, Chrome или Edge. В большинстве случаев Firefox запускает блестящие приложения намного быстрее, чем Chrome или Edge, что означает, что создателям браузеров все еще нужно улучшать, даже Firefox может улучшиться.
Если вашему приложению требуется частый доступ к DOM, то определенно веб-сборка /Blazor будет работать медленнее по сравнению с любыми библиотеками JS, поскольку веб-сборка не может напрямую обращаться к DOM без использования Invokes (что сейчас медленно), см. мой тест блейзера ниже).
В Firefox 10 000 RegisteredFunction.InvokeUnmarshalle вызовы пустых методов занимают 250 мс, в то время как хром и ребро требуют более 2400 мс на моем ПК. В чистом JS для этого же сценария требуется менее 10 миллидондов.
https://webassemblycode.com/webassembly-cant-access-dom/
Кроме того, текущая реализация Blazor имеет собственный механизм MSIL поверх механизма веб-сборки браузеров, что означает, что для запуска проекта Blazor работают два интерпретатора, подобно двум переводчикам, интерпретирующим диалог вместо одного. В настоящее время Microsoft работает над компилятором AOT, который еще не выпущен. После его выпуска Blazor будет намного быстрее, чем текущая реализация.
http://www.mono-project.com/news/2018/01/16/mono-static-webassembly-compilation/
Мы можем с уверенностью предположить, что веб-сборка - это будущее веб-разработки, но в настоящий момент мы ничего не можем сказать о будущем Blazors. На бумаге Blazor может быть быстрее любой другой среды, однако нам нужны обязательства со стороны разработчиков веб-сборок, разработчиков браузеров, Microsoft и сообществ, чтобы сделать теории практичными.
Обновление 10 июля 2018 года
В репозитории WebAssembly появились новые предложения.
- Разрешение WebAssembly обрабатывает DOM напрямую. https://github.com/WebAssembly/host-bindings/blob/master/proposals/host-bindings/Overview.md
- Типы ссылок для WebAssembly с GC. https://github.com/WebAssembly/reference-types/blob/master/proposals/reference-types/Overview.md
Выше два предложения проложат путь к гораздо более быстрому взаимодействию между DOM и веб-сборкой в будущем. IOW Blazor будет намного быстрее в будущем.
Обновление 17 октября 2018 года
Команда Firefox смогла достичь вызова JS → WASM так же быстро, как вызовы JS → JS. На данный момент FireFox намного опережает любые другие браузеры, когда речь заходит о поддержке WebAssembly.