Blazor с нуля: Глава 1 — Что такое Blazor?

· 6 мин чтения
Blazor .NET Web Development Series
Available in: Русский · English · Español · Français · Deutsch · Português · 한국어 · 日本語 · 中文 · العربية · हिन्दी · Polski · Türkçe · Bahasa Indonesia · Nederlands

Добро пожаловать в Главу 1 серии Blazor с нуля. Если вы пропустили вводный пост, в котором я объяснил, о чём эта серия и для кого она предназначена, начните с него — он короткий.

В этой главе мы ответим на фундаментальный вопрос: что такое Blazor? Звучит просто, но ответ многослоен — особенно потому, что за эти годы «Blazor» приобрёл несколько разные значения. К концу этого поста вы будете знать, что такое Blazor, как он вписывается в экосистему .NET, какие существуют модели рендеринга и почему вы могли бы выбрать его вместо JavaScript-фреймворка — или нет.

Краткая история

Blazor начался как экспериментальный проект Стива Сандерсона в Microsoft примерно в 2017 году. Идея была провокационной: запустить C# в браузере с помощью WebAssembly, полностью устранив необходимость в JavaScript. Это было доказательство концепции, а имя было намеренным слиянием Blazer и Razor — движка шаблонов, на котором Blazor в итоге и был построен.

Эксперимент вызвал достаточно энтузиазма, чтобы Microsoft отнеслась к нему серьёзно. Blazor вышел в составе ASP.NET Core 3.0 в сентябре 2019 года — сначала как Blazor Server: модель, выполняющая C#-код на сервере и использующая соединение SignalR в реальном времени для отправки обновлений интерфейса в браузер. Blazor WebAssembly последовал в мае 2020 года в рамках ASP.NET Core 3.1, принеся фреймворку настоящее выполнение на стороне клиента.

.NET 6 и 7 улучшили опыт разработчиков. Затем .NET 8, выпущенный в ноябре 2023 года, коренным образом пересмотрел модель рендеринга с тем, что Microsoft назвала full-stack web UI. Статический рендеринг на стороне сервера, потоковый рендеринг, интерактивный сервер, интерактивный WebAssembly и новый режим Auto — всё это теперь живёт под одной крышей в одном проекте. .NET 9 развил эту основу и сгладил шероховатости.

Вот где мы находимся сегодня.

Что такое Blazor на самом деле

В своей основе Blazor — это компонентный UI-фреймворк для .NET. Вы строите интерфейс из компонентов — самодостаточных единиц C# и HTML-разметки, которые могут хранить состояние, реагировать на события и компоноваться в более крупные структуры. Если вы работали с React или Vue, эта ментальная модель покажется знакомой. Ключевое отличие в том, что вместо JavaScript вы пишете C#.

Компоненты Blazor пишутся в файлах .razor. Файл .razor смешивает HTML-разметку с C#-кодом, используя синтаксис Razor, который вы, возможно, уже знаете по представлениям ASP.NET MVC. Вот как выглядит простой компонент:

@page "/counter"

<h1>Счётчик</h1>
<p>Текущее значение: @currentCount</p>
<button @onclick="IncrementCount">Нажмите меня</button>

@code {
    private int currentCount = 0;

    private void IncrementCount()
    {
        currentCount++;
    }
}

JavaScript не виден. Директива @onclick связывает нажатие кнопки с C#-методом. Выражение @currentCount отображает текущее значение. При изменении состояния Blazor определяет, что нужно обновить в DOM.

Вот и весь стержень. Всё остальное — маршрутизация, внедрение зависимостей, формы, HTTP-вызовы — строится поверх этой компонентной модели.

Модели рендеринга

Именно здесь кроется много путаницы, поэтому будем точны. Сегодня «Blazor» обозначает семейство режимов рендеринга, а не единую модель развёртывания. Понимать разницу важно, поскольку это влияет на производительность, требования к инфраструктуре и то, что ваши компоненты могут и не могут делать.

Статический SSR

Простейший режим. Ваши компоненты Razor рендерятся на сервере в HTML, который затем отправляется в браузер. Нет постоянного соединения, нет WebAssembly и по умолчанию нет интерактивности на стороне клиента. По сути это то, что делает Razor Pages, но с использованием компонентной модели.

Используйте для страниц с большим количеством контента, лендингов, всего, что не требует живой интерактивности.

Интерактивный сервер

Код компонента выполняется на сервере. Между браузером и сервером устанавливается WebSocket-соединение SignalR. Когда вы нажимаете кнопку или вводите что-то в поле ввода, событие передаётся по WebSocket на сервер, выполняется C#-код, вычисляется разница и обновления DOM отправляются обратно в браузер.

Преимущества: Полный доступ к ресурсам сервера (базы данных, файловая система, секреты). Быстрая начальная загрузка. Небольшой размер загружаемых данных. Работает в браузерах без поддержки WebAssembly.

Недостатки: Каждое взаимодействие пользователя требует обращения к серверу, что добавляет задержку. Ресурсы сервера масштабируются по количеству активных соединений. Приложение деградирует при обрыве соединения.

Используйте для бизнес-приложений, внутренних инструментов, приложений, где серверный доступ к данным важнее офлайн-возможностей.

Интерактивный WebAssembly

Среда выполнения .NET загружается в браузер, и приложение работает полностью на стороне клиента. После начальной загрузки приложение полностью работает офлайн, а каждое взаимодействие мгновенное — без обращений к серверу для UI-логики.

Преимущества: Настоящее выполнение на стороне клиента. Работает офлайн. Снижение нагрузки на сервер после загрузки приложения.

Недостатки: Больший начальный объём загрузки (среда выполнения .NET + приложение). Более медленная первая загрузка. Для доступа к данным на сервере нужен API.

Используйте для офлайн-приложений, инструментов, требующих мгновенного отклика, сценариев, где серверная обработка не нужна для UI.

Режим Auto

Введён в .NET 8. Приложение стартует в режиме интерактивного сервера (быстрая начальная загрузка, нет ожидания загрузки WebAssembly). Как только файлы WebAssembly скачаются в фоне, последующие посещения автоматически переключаются в режим WebAssembly.

Это даёт вам быструю первую загрузку серверного режима и в конечном счёте полное клиентское выполнение WebAssembly. Это наиболее сложная для понимания модель, но практичный выбор по умолчанию для многих приложений.

Смешивание режимов в одном приложении

В .NET 8 и выше вы не привязаны к единственному режиму рендеринга для всего приложения. Маркетинговый лендинг может быть статическим SSR; авторизованная панель управления — интерактивным сервером; виджет визуализации данных — интерактивным WebAssembly. Фреймворк управляет переходами.

В этой серии мы начнём с интерактивного сервера, поскольку это проще всего запустить и у него наиболее понятная ментальная модель. Другие режимы исследуем по мере продвижения.

Как Blazor соотносится с JavaScript-фреймворками

Если вы разрабатывали на React, Angular или Vue, вероятно, именно это сравнение вас интересует.

Сходства реальны. Компонентная модель Blazor намеренно похожа на React. У вас есть props (Parameters в Blazor), локальное состояние (поля в блоке @code), хуки жизненного цикла и тот же паттерн: данные вниз, события вверх. Если вы знаете React, освоитесь за несколько часов.

Ключевое отличие — язык. В Blazor вы пишете C#. Бизнес-логика, правила валидации и модели данных могут быть общими для вашего Blazor-фронтенда и ASP.NET Core-бэкенда. Больше не нужно дублировать класс User в TypeScript, если он уже есть на C#.

Разрыв экосистем реален, но сокращается. Экосистема npm огромна. Экосистема NuGet для UI-компонентов меньше, хотя существенно выросла. Если нужна специфическая библиотека графиков или виджет drag-and-drop, у JavaScript по-прежнему больше вариантов. Но для большинства бизнес-приложений того, что доступно в мире .NET, более чем достаточно.

JavaScript-взаимодействие есть, когда оно нужно. Blazor позволяет вызывать JavaScript из C# и C# из JavaScript. Для браузерных API без .NET-обёртки или при необходимости использовать существующую JS-библиотеку interop доступен. Он добавляет слой, но не причиняет боли.

Честный ответ: если вся ваша команда — JavaScript-разработчики, создающие публичный продукт, где критичны SEO, производительность и экосистема npm, оставайтесь на JavaScript. Если ваша команда — .NET-разработчики, если вы создаёте внутренние или бизнес-приложения, или если для вас важно совместное использование кода между фронтендом и бэкендом, Blazor — убедительный выбор.

Что нужно для дальнейшего изучения

Для остальной части серии вам понадобится:

  • .NET 9 SDK — загрузить с dot.net
  • IDE — Visual Studio 2022 (Community-редакция бесплатна), VS Code с расширением C# Dev Kit или JetBrains Rider
  • Базовое знание C# — классы, свойства, интерфейсы, async/await

Это всё. Никакого Node, npm или webpack.

Что дальше

В Главе 2 мы создадим ваше первое приложение Blazor, разберём структуру проекта и убедимся, что вы можете запустить его локально. В итоге у вас будет работающее приложение и чёткое понимание того, что делает каждый файл.

До встречи там.