Технология, лежащая в основе Blazor, впечатляет. Но достаточно ли этого?

Когда я впервые встретил Blazor, меня поразила смелость идеи. Вместо того, чтобы пытаться включить что-то еще в перегруженную экосистему JavaScript, Microsoft собиралась начать с нуля. Еще раз. (Тем из вас, кто помнит свое обреченное приключение в Silverlight, не нужно еще одно напоминание.)

Сегодня трудно переоценить важность JavaScript. Это не просто доминирующая экосистема для браузерных веб-приложений. Для них это единственная экосистема. И хотя Blazor не полностью свободен от JavaScript (кому-то еще нужно взаимодействовать с HTML DOM, будь то ваш код или компонент, который вы используете), Blazor нагло понижает JavaScript до незначительных деталей реализации. Цель состоит в том, чтобы написать всю вашу бизнес-логику и все важное на чистом C #.

Технологические основы Blazor прочны. Он построен на WebAssembly, кроссплатформенном стандарте, который пользуется значительной поддержкой поставщиков, универсальной поддержкой браузеров и лучшей производительностью, чем даже современные оптимизированные движки JavaScript. WebAssembly также предлагает несколько потрясающих демонстраций концепции, таких как 3D-игры и эмуляторы, запускаемые непосредственно в браузере. Написание непосредственно в WebAssembly не вариант, потому что это сильно сжатый промежуточный язык. Но компиляция в WebAssembly или использование чужого движка приложений на основе WebAssembly имеет смысл. Так почему бы нам не использовать WebAssembly для создания совершенно нового фреймворка, не обремененного причудами и историей JavaScript? (Краткий ответ: потому что это очень сложно сделать правильно.)

Я впервые взглянул на Blazor почти ровно два года назад. Ранний приговор разделили. Blazor был интересным экспериментом - на пороге величия, но не практическим решением текущих проблем.

А как насчет сейчас?

Пределы Blazor сегодня

В техническом сообществе сложилось мнение о Blazor. Независимо от того, являетесь ли вы поклонником Blazor или критиком (или обоими сразу), существует широкое согласие относительно того, что движет Blazor вперед, а что еще может его сдерживать.

Самая большая проблема Blazor - это небольшое, но не подлежащее обсуждению снижение производительности. Даже в сегодняшнем мире современной интернет-инфраструктуры у Blazor есть налог на запуск и небольшой, но несколько более значительный налог на первый запуск. Это единственная действительно фундаментальная проблема, потому что она не может быть исправлена ​​в будущих версиях Blazor. Все, что мы можем сделать, это дождаться улучшения инфраструктуры Интернета, чтобы решить эту проблему.

Если вы использовали Blazor, вы, вероятно, видели это сообщение, забитое в верхнем углу окна, когда приложение вот-вот появится, и которое выглядит немного смущенным:

Blazor использует этот момент для загрузки встроенной версии среды выполнения .NET (скомпилированной в WebAssembly) вместе с библиотеками DLL для вашего приложения и библиотеками классов .NET, которые она использует (скомпилирована на Common Intermediate Language Microsoft, как и все версии. NET с 2000 года). Размер загрузки не подлежит обсуждению - 2 или 3 МБ. Задержка запуска колеблется от долей секунды до нескольких секунд или, иногда, даже больше.

Каким бы коротким ни был экран загрузки веб-приложения, он имеет явно отрицательный оттенок. Это напоминает устаревшие веб-технологии, такие как Flash и (для действительно старых среди нас) апплеты Java. В некоторых средах задержка Blazor автоматически нарушает условия сделки. Но есть стратегии смягчения, такие как кэширование с помощью CDN, функция предварительной компиляции, которая появится в .NET 6 (запланирована на ноябрь 2021 года), и различные типы оптимизации, такие как встряхивание дерева, которые постоянно улучшаются. Но независимо от того, какие улучшения делает Microsoft, Blazor не достигнет скорости запуска JavaScript.

Если это дисквалифицирует Blazor сейчас для некоторых людей, это не дисквалифицирует его навсегда. В конце концов, WebAssembly - это невероятно быстрая технология. Возможно, Blazor сможет сократить разрыв в производительности в других областях. Представьте себе приложение с интенсивным использованием ЦП, созданное на Blazor (подумайте о науке о данных или секвенирование ДНК), с производительностью, превосходящей версию JavaScript во всем, кроме запуска. Сейчас такая работа часто выполняется с помощью Rust (который также компилируется в WebAssembly) или переносится с C ++ с помощью Emscripten. Но оба подхода являются частью небольшой специализированной ниши веб-разработки. Если бы Blazor мог шире открыть дверь для оптимизированных браузерных приложений, задержка запуска могла бы не иметь большого значения.

Могло ли исчезнуть отставание при запуске? В современном мире пропускная способность продолжает расти в соответствии с уменьшенной версией закона Мура. Это означает, что снижение производительности, существующее сегодня для Blazor, со временем только уменьшится. Не исключено, что штраф никогда не станет незначительным. Но предсказывал ли кто-нибудь десять лет назад, что производительность JavaScript вырастет до такой степени, что мы сможем запускать такие вещи, как Electron, на котором размещается не только отдельный экземпляр движка JavaScript для каждого приложения, но и отдельный веб-сервер Node.js для питание его серверной части? И что производительность будет достаточно хорошей, чтобы мы могли использовать этот подход для создания самого популярного редактора кода в мире?

Еще одна потенциальная проблема с Blazor - это встроенная модель приложения, которая в значительной степени заимствована из серверной веб-инфраструктуры Microsoft, Razor. Этот выбор дизайна имеет определенный смысл, потому что он дает разработчикам Microsoft отправную точку и способ ориентироваться в мире Blazor. И, возможно, слишком ожидать, что Microsoft заново изобретет каждую часть модели приложения, представив новую среду выполнения, работающую на WebAssembly. Но все же атрибуты Razor могут показаться немного произвольными. Нам не нужно быть привязанными к прошлому - в конце концов, в прошлом JavaScript было много уродства. Но справедливо спросить, действительно ли модель Blazor со вкусом бритвы является наилучшей абстракцией.

Будущее: Интернет, отделенный от HTML

С одной стороны, Blazor полностью современен. Он отражает растущую (и часто спорную) тенденцию создания веб-приложений, которые постепенно становятся все более абстрагированными от HTML. Лидеры отрасли, такие как Google, создают приложения, которые рисуют свои интерфейсы с помощью элемента холста, а не моделируют его из отдельных элементов HTML и взаимодействуют через DOM. Фреймворки JavaScript, такие как React, имеют библиотеки компонентов, которые позволяют нам программировать с использованием элементов управления более высокого уровня, а не с HTML-формами и элементами div. Flutter создает кроссплатформенный механизм компоновки, который также полагается на WebAssembly.

Нравится нам эта тенденция или нет - а у нее много недостатков - это движение, которое готово вырасти и в будущем, независимо от того, создаете ли вы с помощью Blazor или JavaScript-фреймворка. И хотя экосистема Blazor началась с нуля всего два года назад, в ней уже есть широкий спектр доработанных библиотек компонентов, многие из которых бесплатны даже для коммерческого использования. Рассмотрим предложения от MudBlazor, MatBlazor, Radzen, Ant Design, Telerik и коллекцию Blazored, и это лишь несколько многообещающих вариантов. Если вам нужны красиво оформленные диаграммы, сетки данных, карусели, панели инструментов и другие элементы магии пользовательского интерфейса, единственная проблема - решить, какая библиотека, вероятно, получит лучшее распространение и поддержку в будущем.

Сегодняшний вердикт

Blazor сложно продать нынешнему веб-разработчику, потому что он означает отказ от многих библиотек и технологий, которые были созданы более чем за десятилетие современной разработки на JavaScript. Это не плавный переход, и нет возможности перенести приложение JavaScript в проект Blazor. Переход на Blazor по-прежнему означает переход от бурных морей JavaScript к бассейну гораздо меньшего размера. Большинство разработчиков собираются это проверить, но пока не готовы покинуть океан.

Для опытных разработчиков C # это другое дело. Если у вас есть команда, которая знает .NET, и они создают внутреннее бизнес-приложение, Blazor позволяет им работать более продуктивно и создавать интерфейсную и внутреннюю части с помощью одного стека. Если вы рассматривали классическое приложение Windows (построенное на чем-то вроде WPF), Blazor - это более перспективный выбор. Но если вы создаете современные общедоступные веб-приложения, вряд ли вы порекомендуете клиенту начать работу с Blazor сегодня.

Суть? Blazor - это мощная ниша, которая лучше всего подходит для разработчиков Microsoft, которые любят .NET и C #. Но не позволяйте настоящему ослеплять вас в отношении будущего. Стеки, основанные на WebAssembly, многообещающи, и есть много возможностей для других языков, которые могут откусить края JavaScript. А в постоянно меняющемся мире веб-разработки нам назрела еще одна революция.

Чтобы получать больше новостей о Blazor и WebAssembly, подпишитесь на Информационный бюллетень Young Coder.