Я бы хотел начать использовать Blazor, несмотря на то, что он все еще находится на альфа-уровне.
Насколько я понимаю, Blazor использует WebAssembly для компиляции C # на стороне клиента.
И у меня есть такие вопросы:
Работает ли этот подход быстрее, чем, например, React / Vue, скомпилированный на JavaScript?
Верно ли, что браузеру нужно будет загружать библиотеку WebAssembly каждый раз при загрузке страницы?
В Интернете нет сравнений производительности популярных JS-фреймворков. Поэтому я хотел бы узнать теоретические характеристики нового фреймворка от Microsoft. Заранее спасибо.
asp.net
performance
blazor
webassembly
FoxPro
источник
источник
Ответы:
Нет, браузеры могут кэшировать файлы. Обычный CDN для приложений Blazor сделает свое дело.
Blazor использует веб-сборку. На бумаге веб-сборка должна быть быстрее, чем любая библиотека js, однако не все браузеры еще имеют зрелый парсер веб-сборки. Таким образом, вы можете обнаружить, что на данный момент браузеры не будут запускать веб-сборку с оптимальной скоростью.
Вы можете создать небольшое приложение Blazor и запустить его в Firefox, Chrome или Edge. В большинстве случаев Firefox запускает приложения Blazor намного быстрее, чем Chrome или Edge, что означает, что разработчикам браузеров все еще нужно улучшать, даже Firefox может улучшиться.
Если вашему приложению требуется частый доступ к DOM, то определенно веб-сборка / Blazor будет медленнее по сравнению с любыми JS-библиотеками, поскольку веб-сборка не может напрямую обращаться к DOM без использования Invokes (что на данный момент медленно, обратитесь к моему тесту blazer ниже) .
В Firefox 10 000
RegisteredFunction.InvokeUnmarshalleвызовов пустых методов занимают 250 мс, в то время как Chrome и Edge требуют более 2400 мс на моем ПК ». В чистом JS для того же сценария требуется менее 10 миллисекунд.Кроме того, текущая реализация Blazor имеет собственный движок MSIL поверх движка веб-сборки браузеров, что означает, что для запуска проекта Blazor работают два интерпретатора, как два переводчика, интерпретирующие диалог вместо одного. В настоящее время Microsoft работает над компилятором AOT, который еще не выпущен. После выпуска Blazor будет намного быстрее, чем текущая реализация.
http://www.mono-project.com/news/2018/01/16/mono-static-webassembly-compilation/
Мы можем смело предположить, что веб-сборка - это будущее веб-разработки, но на данный момент мы ничего не можем сказать о будущем Blazor. На бумаге Blazor может быть быстрее, чем любой другой фреймворк, однако нам нужна приверженность специалистов по сопровождению веб-сборки, разработчиков браузеров, Microsoft и сообществ, чтобы сделать теории практичными.
Обновление 10 июля 2018 г.
В репозиториях WebAssembly появились новые предложения.
Разрешение WebAssembly напрямую обрабатывать DOM. https://github.com/WebAssembly/proposals/issues/8
Типы ссылок для 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.
https://hacks.mozilla.org/2018/10/calls-between-javascript-and-webassembly-are-finally-fast-%F0%9F%8E%89/
источник
Наполовину правда. Вы можете написать свой код на стороне клиента WebAssembly (WASM) (да, это C # на стороне клиента), но вы также можете выполнить на стороне сервера логики. У обоих есть преимущества. Весь ваш код виден, если вы пойдете по маршруту WASM. Но он может выполнять повторный рендеринг быстрее, чем если бы вся логика была основана на сервере, но если он основан на сервере, ваш код не отображается.
Нет. Я сделал тонну Vue, и Vue работает быстрее. НО я могу писать код НАМНОГО быстрее с помощью Blazor. И Blazor предлагает решение для виртуальной прокрутки, которое может ускорить его отображение. В моем случае доступные компоненты построения были слишком медленными. Я написал компонент Blazor с использованием C # и JavaScript, который работал очень хорошо. В большинстве случаев я не беспокоюсь о том, что код WASM работает слишком медленно ... но построение графика должно было быть намного быстрее ... и Blazor позволил мне съесть свой торт ... Мне просто нужно было немного уровень работы в JavaScript. За последние 6 месяцев выполнение Blazor ускорилось, и команда говорит, что, когда выйдет .Net 6, это еще не все. Но его более чем достаточно для 99% того, что мне когда-либо приходилось делать.
Нет, если они кешированы. И даже при первой загрузке, это не медленно, если у вас есть приличное соединение. Есть порядка 10 мег.
Отличный незаданный вопрос - стоит ли его использовать. Пользуюсь уже около 6 месяцев. Для меня это было здорово. C # - очень хороший язык. Иногда мне не хватает динамического добавления свойства, и часто вам приходится вручную инициировать повторную отрисовку, но с такими функциями, как проверки объектов с нулевым значением, предупреждающими вас, что вы не проверяли, может ли ваш код вызвать проверку нулевой ссылки - это намного лучше, чем JS. Я часто чувствовал, что работать с «цепочкой инструментов» JavaScript было болезненно. Так приятно иметь возможность отказаться от библиотечного трэша JS.
источник