Blazor c что это

Введение в Blazor

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

Фреймворк Blazor развивается как opensource-проект, исходный код которого можно найти в репозитории на github: https://github.com/dotnet/aspnetcore/tree/master/src/Components

Blazor предоставляет разработчикам следующие преимущества:

• Написание кода веб-приложений с помощью C# вместо JavaScript
• Использование возможностей экосистемы .NET, в частности, библиотек .NET при создании приложений, безопасности и производительности платформы .NET
• Клиентская и серверная части приложения могут использовать общую логику
• Использование Visual Studio в качестве инструмента для разработки, который имет встроенные шаблоны для упрощения создания приложения

Функционально на текущий момент Blazor подразделяется на несколько подсистем:

• Blazor Server : позволяет создавать серверные приложения и поддерживается ASP.NET
• Blazor WebAssembly : позволяет создавать одностраничные интерактивные приложения клиентской стороны, которые запускаются в браузере пользователя и работают с помощью технологии WebAssembly
• Blazor Hybrid : позволяет создавать десткопные и мобильные приложения поверх технологии .NET MAUI

Первая превью-вервия Blazor вышла в 22 марта 2018 года. В полненоценный релиз Blazor Server вышел в сентябре 2019 года, а Blazor WebAssembly — в мае 2020 года, и обе эти платформы включены в .NET и полноценно могут использоваться для создания серверных приложений и клиентских приложений. То есть фактически Blazor покрывает потребности в веб-приложениях как на стороне сервера, так и на стороне клиента.

Blazor WebAssembly

Долгое время написание клиентских веб-приложений было уделом языка JavaScript. Внедрение поддержки WebAssembly изменио ситуацию. И технология Blazor WebAssembly позволяет создавать интерактивные приложения на языке C#, которые запускаются и отрабатывают в браузере пользователя с помощью технологии WebAssembly. При построении и запуске приложения Blazor WebAssembly файлы с кодом C# и Razor компилируются в сборки .NET. Затем Blazor WebAssembly (а если точнее скрипт blazor.webassembly.js ) загружает среду выполнения .NET, сборки и их зависимости и настраивает среду выполнения .NET для выполнения сборок. Посредством взаимодействия с JavaScript фреймворк Blazor WebAssembly может обращаться к DOM и API браузера.

Такая модель выполнения имеет ряд преимуществ. Так, Blazor WebAssembly не зависит от сервера. Все необходимые файлы среды выполнения .NET и загружаемых сборок могут кэшироваться в браузере и работать без доступа к сети. По большому счету нам может быть достаточно статического сервера, на котором размещены все файлы приложения.

Поскольку приложение работает полностью на стороне браузера и совершенно не зависит от сервера, то снижается нагрузка на сервер.

В то же время Blazor WebAssembly имеет ряд ограничений. Например, браузер должен поддерживать технологию WebAssembly — на данный момент последние версии распространенных браузеров (Google Chrome, Mozilla Firefox, Opera, Microsoft Edge, Yandex Browser) поддерживают эту технологию. Однако более старые версии, либо Internet Explorer не имеют подобной подобной поддержки. Также браузеру необходимо загрузить файлы большого размера, так как приложение полностью отрабатывает на стороне клиента, что увеличиваает нагрузку на сеть и время загрузки. Также, поскольку все файлы приложения доступны пользователю, то нивелируется возможность скрыть какой-нибудь код, который представляет коммерческую ценность. Ну и кроме того, в этом случае возможности приложения ограничены браузером, в котором запускается приложение.

Blazor Server

В Blazor Server приложение отрабатывает на стороне сервера. Обновление элементов пользовательского интерфейса, обработка событий, вызовы JavaScript на клиентской стороне осуществляются посредством взаимодействия сервера и клиента через SignalR.

То есть когда пользователь взаимодействует с приложением в браузере, вызывает события пользовательского интерфейса (например, нажимает на кнопку), то клиентская сторона посылает на сервер информацию о событии, сервер обрабатывает полученную информацию и посылает клиенту в ответ инструкции, как необходимо обновить элементы интерфейса. В какой-то степени это похоже на подход, применявшийся в ASP.NET WebForms.

Поскольку большая часть логики приложения сосредоточена на стороне сервера, то все загружаемые клиентом файлы имею гораздо меньший размер по сравнению с Blazor WebAssembly. Приложение не ограничено браузером и может воспользоваться возможностями серверной обработки. Кроме того, приложение может работать с устаревшими браузерами, которые не поддерживают WebAssembly.

В то же время для работы приложения необходима постоянная поддержка сетевого подключения. Если количество пользователей велико, что увеличивается нагрузка на сервер. Также задержки в сети могут оказать негативное воздействие. В частности, при задержках в более чем 200 миллисекунд интерфейс становится гораздо менее отзывчивым, начинает тормозить.

Blazor Hybrid

С выходом .NET 6 вышел также Blazor Hybrid , который работает поверх фрейворка .NET Multi-platform App UI (MAUI) подобно технологии Electron. Содержимое приложения Blazor запускается через специальный элемент — BlazorWebView . Blazor Hybrid позволяет запускать те же компоненты, что используются в Blazor WebAssembly или Blazor Server практически без изменений. Таким образом, Blazor покрыл и серверный веб, и клиентский веб, и десктоп и мобайл. Но в данном руководстве мы сделам акцент на создание именно веб-приложений с помощью Blazor.

Компоненты

Ключевым элементом приложения Blazor являются компоненты. Кто работал с фреймворками клиентской стороны, такими как Angular, React, VueJS, то сталкивался с компонентами, которые по сути структурируют приложение. В Blazor применяется похожая концепция. Здесь компонент представляет элемент интерфейса, например, какое-то определенное содержание, меню, диалоговое окно, форма ввода данных или даже целая страница. Все есть компонент.

Компоненты определяют логику рендеринга элементов интерфейса, а также логику обработки пользовательского ввода. Компоненты могут быть вложенными в другие компоненты. Компоненты можно повторно использовать в других проектах и переносить в виде библиотеки классов Razor. Обычно класс компонента располагается в файле с расширением .razor , а для их определения применяется синтаксис Razor, который позволяет объединить разметку HTML с кодом на C#.

Благодаря компонентам уменьшается количество повторяющегося кода и упрощается поддержки и обновление приложения.

Преимущества использования Blazor

• Blazor прост и легок в обучении
• Наличие инструментария, в частности, среды Visual Studio, которые облегчают разработку с Blazor.
• Развитая экосистема разработчиков, благодаря чему в сети проще найти ответ на интересующий вопрос. Наличие большого количества различных компонентов и библиотек от других разработчиков, которые можно использовать в своих приложениях.
• Использование Blazor не навязывает использование определенных стандартов для архитектуры приложения. Кому-то нравится MVVM (model-view-viewmodel), кому нравится другой паттерн — выбор всецело ложится на разработчика.
• Мы можем использовать для построения приложений сервера и клиента один и тот же язык — C#, для создания клиентского браузерного приложения использовать и знать JavaScritpt необязательно. Кроме того, можно определять некоторую бизнес-логику на C# и использовать ее в как в приложениях Blazor, так и в приложениях, построенных с помощью других технологий — WinForms, WPF, MAUI, ASP.NET и т.д.
• Если говорить о клиентских приложениях на Blazor WebAssembly, то для них даже не нужен установленных .NET на компьютере клиента, так как приложение разворачивается в браузере. Даже не нужен сервер на .NET.

Что такое веб-платформа Blazor от Microsoft и стоит ли ее использовать? – CloudSavvy ИТ

Blazor – это новый веб-фреймворк от Microsoft, предназначенный для конкуренции с ведущими в отрасли платформами, такими как React. За исключением того, что вместо использования JavaScript он работает в среде выполнения .NET и позволяет разработчикам создавать интерактивные веб-приложения с использованием C # и HTML.

Что такое даже ASP.NET?

Если вы пришли из мира фреймворков JavaScript, вас могут смутить отношения Blazor с ASP.NET. Обе они являются «веб-фреймворками», но Blazor – лишь одна часть экосистемы ASP.NET.

Программы для Windows, мобильные приложения, игры — ВСЁ БЕСПЛАТНО, в нашем закрытом телеграмм канале — Подписывайтесь:)

В то время как Платформа ASP.NET на данный момент ему почти 20 лет, это не фреймворк динозавра – он постоянно совершенствуется вместе с C # и .NET в целом, поскольку Microsoft использует его для внутренних целей. Он полностью кроссплатформенный и такой же производительный, как никогда.

Вначале был только ASP.NET, который можно было использовать для создания всевозможных веб-приложений. Был ASP.NET MVC (Model-View-Controller), который создает веб-страницы, управляемые данными, и ASP.NET WebAPI, который специализируется на внутренних API. Недавно они были объединены в единый пакет с модернизированным ASP.NET Core.

Пять лет назад, Razor Pages (который отличается от Blazor и имеет странное название) был выпущен для упрощения выразительного синтаксиса MVC, который требует большого количества шаблонов и, как таковой, не очень хорошо сочетается с ориентированным на компоненты дизайном современных приложений. MVC требует, чтобы вы создавали представление и модель для каждой страницы в отдельных файлах:

Между тем, с помощью Razor вы можете создавать более оптимизированные страницы или компоненты с интегрированным кодом на самой странице. Это работает лучше, когда страницы проще, но обе доступны в качестве вариантов для использования.

Все эти функции являются частью экосистемы «ASP.NET». Самое замечательное в этом – пакеты и поддержка. Как и NPM для JavaScript, C # также имеет здоровую среду пакетов с диспетчером пакетов NuGet.

Так что же такое Blazor?

Blazor ничего не меняет в синтаксисе этих страниц. Вы по-прежнему будете использовать страницы Razor и / или MVC. На самом деле это даже не плохо, потому что уже существует множество библиотек пользовательского интерфейса и компонентов для страниц Razor, поддерживаемых C #.

Blazor добавляет интерактивность. Традиционные страницы MVC / Razor, использующие ASP.NET, всегда были неуклюжими и изо всех сил пытались не отставать от веб-приложений реального времени, таких как React. Веб-приложения в реальном времени настолько быстры, что они начинают занимать и рабочий стол, с такими фреймворками, как Electron, запускающими приложения в контейнере Chromium, при этом пользователи не вникают.

Итак, Blazor был создан для удовлетворения этого спроса. Он работает так же, как React, где действия изменяют состояние и свойства и запускают обновления приложения. Платформа будет выполнять обновление DOM за вас в зависимости от того, какие компоненты нуждаются в обновлении. Это позволяет приложениям, работающим в реальном времени, обновлять страницу или даже полностью перерисовывать ее без фактического обновления браузера.

Преимущество Blazor над устоявшейся структурой, такой как React, – это язык. Он позволяет создавать веб-приложения на C #, и одно это делает его привлекательным для многих разработчиков. Какого бы мнения вы ни придерживались по поводу споров о динамической и статической типизации, «настольные» языки, такие как C #, определенно имеют преимущества, а в Интернете серьезно не хватает альтернатив JavaScript.

Если у вас есть серверная часть, требующая высокой производительности, C # также будет работать намного быстрее, чем JavaScript. Несмотря на то, что JS ни в коем случае не является медленным и значительно улучшился за эти годы, он все равно будет менее производительным, чем C #, который на самом деле работает довольно близко к производительности собственного C ++.

Blazor обеспечивает лучшую совместимость. Многие приложения также уже используют C # на сервере. Например, у вас может быть API ASP.NET, который взаимодействует с вашим интерфейсом React. Вам понадобятся отдельные модели для сервера и клиента, а также отдельный код для взаимодействия с ними. Если они на одном языке, это позволяет легко обмениваться кодом и библиотеками между клиентом и сервером. Это единственная причина, по которой NodeJS существует на стороне сервера – хотя JavaScript не является идеальным языком рабочего стола, создание приложений на одном языке сокращает время разработки.

Будущее Blazor

На самом деле существует несколько различных типов Blazor, поскольку в последнее время Microsoft предприняла большие усилия для модернизации экосистемы ASP.NET. В настоящее время выпущены две версии:

• Blazor Server, который работает как React Server Side Rendering и выполняет большую часть обработки на сервере.
• Blazor WebAssembly, который использует магию WebAssembly для запуска реального кода .NET в реальном клиентском веб-браузере.

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

• Blazor PWA, который разработан для публикации сайта как устанавливаемого прогрессивного веб-приложения (PWA).
• Blazor Desktop / Hybrid, который позволяет упаковывать приложения Blazor в настольные приложения и в основном похож на Electron, но с более высокой производительностью.
• Blazor Native, который заменяет веб-интерфейс на собственный интерфейс платформы. Неясно, насколько это полезно помимо взаимодействия с существующими инструментами Blazor, и эта версия все еще находится на этапах планирования.

В своем объявлении о Blazor Desktop Microsoft заявила, что «Blazor – это модель программирования приложений. Он очень легко адаптируется и может выполняться разными способами (в зависимости от потребности) ».

Похоже, что Microsoft считает Blazor своим следующим стандартом создания внешних интерфейсов приложений. Их работа тоже того стоит, потому что по мере того, как приложения становятся все более и более зависимыми от Интернета, становится все труднее обосновать создание отдельных интерфейсов для Интернета и рабочего стола. У Blazor светлое будущее, и у веб-приложений, созданных сегодня на Blazor Server и WebAssembly, будет много возможностей для роста.

Blazor Server против Blazor WebAssembly

Blazor Server использует Подключение SignalR для связи между клиентом и сервером. Это просто причудливый слой поверх соединения WebSocket, который может при необходимости вернуться к другим соединениям. Это сохраняет всю обработку на сервере и оставляет клиенту простое представление с базовым способом управления DOM.

Blazor WebAssembly – это то, где это действительно круто. WebAssembly (WASM) на самом деле не язык, на котором вы пишете, а цель компилятора. На самом деле он работает почти так же, как Microsoft Intermediary Language (MSIL), в который компилируются все C #, F # и VB.NET. За исключением того, что вместо того, чтобы работать со средой выполнения .NET, он работает с использованием среды выполнения WebAssembly в браузере.

Самое интересное в WebAssembly заключается в том, что это относительно легкая цель компилятора. Подобно тому, как C # может компилироваться в MSIL, C # также может компилироваться в WebAssembly. Ну, технически это компиляция MSIL в WebAssembly (как это проще), но суть та же.

Любой язык может компилироваться в WASM, даже полностью родные настольные языки, такие как C ++. Это не теоретически – это действительно работает на практике. AutoDesk смог портировать AutoCAD, кодовую базу C ++ 30-летней давности, перейти к веб-приложению на основе WebAssembly, за несколько месяцев с относительной легкостью. Кто-то даже портирован Дум 3.

Blazor WebAssembly в основном берет весь сервер, а также среду выполнения .NET и запускает ее поверх WASM. Затем вместо того, чтобы разговаривать с сервером через SignalR, он напрямую обращается к DOM. Это исключает обработку на стороне сервера, что может быть идеальным для некоторых приложений.

Это дает ему уникальные возможности для конкуренции с такими фреймворками, как React, поскольку это, по сути, первый настоящий конкурент JavaScript для клиентских веб-приложений. Хотя вам нужно добавить несколько тегов сценария для загрузки среды выполнения и, возможно, придется погрузиться в код JavaScript для нескольких вещей, вы, по большей части, должны иметь возможность создать целое производственное веб-приложение, не написав ни одной строки JavaScript.

Независимо от того, используете ли вы Blazor Server или Blazor WebAssembly, решать вам. У обоих есть свои преимущества. Blazor Server запускает весь код обработки в доверенной среде и не требует наличия общедоступного API. Blazor WASM отзывчивый и быстрый, и его можно даже развернуть как статический сайт, обслуживаемый только NGINX.

Как Blazor работает с JavaScript?

В любом случае у вас действительно есть полная совместимость с JavaScript. Blazor может вызывать JS-функции из управляемого кода:

частная асинхронная задача ConvertArray ()

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

Технически вы можете использовать все пакеты NPM с Blazor, хотя его настройка и взаимодействие с ним со стороны .NET может быть немного головной болью, поэтому в большинстве случаев вы должны предпочесть пакет NuGet.

Можете ли вы использовать Blazor на рабочем столе (Electron)?

Удивительно, но ответ на это положительный. Хотя Microsoft планирует выпустить Blazor Desktop / Hybrid, который делает то же самое, тем временем вы можете просто использовать обычный Electron. Это потому, что Electron действительно не заботится о том, какую веб-страницу он обслуживает, и может просто обслуживать приложение Blazor.

Вы могли подумать, что в нем будет использоваться приложение Blazor WebAssembly, но на самом деле проще просто добавить Electron на существующий сервер ASP.NET Core. WASM имеет некоторые накладные расходы, поэтому этот метод работает быстрее. Это то что Электрон.НЕТ делает, и работает на удивление хорошо. Все, что вам нужно сделать, это установить его и добавить Electron в качестве службы ASP.NET. Вы также можете вызывать собственные функции Electron из C #.

Однако у Microsoft большие планы на Blazor Desktop. Они планируют полностью избавиться от зависимости от браузера и JavaScript и просто запустить собственный контейнер с веб-представлением, которое полностью соответствует .NET.

«Рабочий стол Blazor будет структурирован аналогично тому, как работает Electron. Будет элемент управления WebView, который отображает контент со встроенного веб-сервера Blazor, который может обслуживать как Blazor, так и другой веб-контент (JavaScript, CSS и т. Д.) ».

Это веб-представление будет использовать Safari, WebKitGTK или WebView2, в зависимости от ОС. WebView2 использует Chromium под капотом, поэтому он будет работать так же, как Electron, за исключением того, что он более производительный и использует меньше памяти.

Какой бы ни была реализация, приятно видеть, что другая платформа конкурирует с JavaScript и Electron за создание кроссплатформенных веб-приложений и настольных приложений. Blazor Desktop должен быть выпущен в ноябре 2021 года с первой предварительной версией .NET 6..

Программы для Windows, мобильные приложения, игры — ВСЁ БЕСПЛАТНО, в нашем закрытом телеграмм канале — Подписывайтесь:)

Blazor: Техническое введение

Сегодня команда ASP.NET анонсировала, что проект Blazor был перемещён в репозиторий организации ASP.NET. Мы начинаем стадию эксперимента, чтобы понять сможем ли мы развить Blazor в поддерживаемый продукт. Это большой шаг вперёд!

Что такое Blazor? Это фреймворк для браузерных приложений, написанный на .NET и запускающийся с помощью WebAssembly. Он даёт вам все преимущества богатых современных одностраничных приложений (SPA), позволяя при этом использовать .NET от начала и до конца, вплоть до общего кода на сервере и клиенте. В посте с анонсом подробно описаны основные случаи применения, сроки и так далее.

В этом посте я хочу поглубже поговорить о технических деталях для тех, кому интересно как же это работает.

Запуск .NET в браузере

Первый шаг для построения SPA-фреймворка на .NET это каким-то образом получить возможность запускать .NET код в браузере. Наконец-то, это может быть сделано с использованием открытых стандартов и работать в любом браузере (без всяких плагинов), благодаря WebAssembly.

На данный момент WebAssembly поддерживается всеми основными браузерами, в том числе и мобильными. Это компактный байткод-формат, оптимизированный для уменьшения объема скачиваемых данных и ускорения исполнения. Несмотря на то, что многие разработчики могли бы так подумать, WebAssembly не привносит никаких новых проблем безопасности, так как это не обычные бинарные файлы (вроде x86/x64) — это новый формат, содержащий байткод, который может делать только то же самое, что и JavaScript.

Так как же он позволяет нам запускать .NET? Всё благодаря тому, что команда Mono добавила поддержку WebAssembly в свой проект. Если вы пропустили новости, то проект Mono стал частью Microsoft в 2016 году. Mono это официальный .NET рантайм для клиентских платформ (таких как нативные мобильные приложения и игры). WebAssembly это просто ещё одна клиентская платформа, поэтому вполне разумно, что Mono должно на ней работать.

Моно может запускаться на WebAssembly в двух режимах: режиме интерпретации и AOT.

Интерпретация

В режиме интерпретации рантайм Mono компилируется в WebAssembly, но ваши .NET сборки — нет. Браузер загружает и запускает рантайм, который в свою очередь может загружать и исполнять стандартные .NET сборки (обычные .NET .dll файлы), собранные обычным .NET тулчейном.

Это похоже на то, как для обычной CLR основное ядро распространяется скомпилированным в нативный код, который затем загружает и исполняет .NET сборки. Единственное ключевое различие в том, что десктопная CLR активно использует JIT-компиляцию для ускорения исполнения, в то время как Mono на WebAssembly работает ближе к классической модели интерпретации.

Ahead-of-time (AOT) компиляция

В AOT режиме ваше .NET приложение превращается в чистые WebAssembly бинарники сразу при сборке. В рантайме не происходит никакой интерпретации — ваш код выполняется как обычный WebAssembly-код. Этот режим всё ещё требует загрузки некоторой части рантайма Mono (таких низкоуровневых .NET сервисов как, например, сборка мусора), но позволяет отказаться от таких компонентов как парсер .NET файлов.

Это похоже на то, как с незапамятных времён утилита ngen позволяет AOT-компиляцию .NET сборок в нативный машинный код, или на недавно появившийся полноценный нативный AOT .NET рантайм — CoreRT.

Режим интерпретации против AOT

Какой режим лучше? Мы пока что не знаем.

Однако мы знаем, что режим интерпретации даёт гораздо более быстрый процесс разработки, чем AOT. После изменения кода вы можете пересобрать его обычным .NET-компилятором и получить обновлённое приложение в браузере в считанные секунды. AOT-компиляция, в свою очередь, может занимать минуты.

Очевидная мысль — режим интерпретации будет основным для разработки, а AOT — для продакшена.

Но всё это может оказаться совсем не так, потому что режим интерпретации, к удивлению, гораздо быстрее, чем вы могли бы подумать. И мы слышали от ребят из Xamarin, которые используют .NET для нативных мобильных приложений, что обычные (не AOT) .NET сборки очень маленькие и хорошо поддаются компрессии, в отличие от AOT-сборок. Мы будем рассматривать оба варианта пока у нас не появится возможность объективно оценить разницу.

Blazor, SPA фреймворк

Возможность запустить .NET в браузере это хорошее начало, но этого недостаточно. Чтобы быть продуктивным разработчиком приложений вам нужен последовательный набор стандартных решений для стандартных проблем — таких как создание/переиспользование UI, управление состоянием, роутинг, юнит-тестирование, оптимизация сборки и так далее. Всё это должно быть спроектировано вокруг сильных сторон .NET и языка C#, позволяя извлечь максимум из существующей экосистемы .NET и поставляться вместе с первоклассной поддержкой инструментов, как этого ожидает .NET разработчик.

Blazor это всё вышеперечисленное. Он вдохновлён сегодняшними лучшими SPA фреймворками, такими как React, Vue и Angular, а также некоторыми UI стэками от Microsoft вроде Razor Pages. Наша цель — дать веб-разработчикам то, что максимально хорошо сочетается с .NET.

Компоненты

Во всех современных SPA фреймворках приложения построены из компонентов. Компонент обычно представляет из себя какой-то UI элемент: страницу, диалог, набор вкладок или форму. Компоненты могут вкладываться друг в друга, переиспользоваться и разделяться между проектами.

В Blazor компонент это .NET класс, который вы можете написать напрямую (то есть как C# класс) или, что более принято, в виде страницы разметки Razor (.cshtml файл).

Появившийся примерно в 2010 году Razor это синтаксис для комбинирования разметки с C# кодом. Он создан специально для продуктивности разработчика, позволяя вам переключаться между разметкой и C# безо всяких церемоний, с полной поддержкой intellisense. В примере ниже показан простой компонент диалога, описанный в Razor файле MyDialog.cshtml:

 
@Title
 @RenderContent(Body) OK 
 @functions < public string Title < get; set; >public Content Body < get; set; >public Action OnOK < get; set; >>

Когда вы будете использовать этот компонент, инструментарий знает что вам подсказать:

Многие шаблоны проектирования могут быть построены на этом простом фундаменте, включая популярные паттерны из SPA фреймворков вроде компонентов с состоянием (stateful components), функциональных компонентов без состояния (stateless components) и компонентов более высокого порядка (higher-order components). Вы можете вкладывать компоненты друг в друга, процедурно генерировать их, разделять между библиотеками, запускать юнит-тесты без необходимости наличия браузера и, в целом, жить хорошей жизнью.

Инфраструктура

При создании нового проекта Blazor предложит основные сервисы, необходимые большинству приложений:

• Шаблоны
• Роутинг
• Внедрение зависимостей
• Ленивую загрузку (то есть загрузку частей приложения по мере необходимости)
• Юнит-тестирование

Другой важный момент — только несколько самых низкоуровневых частей находятся в ядре фреймворка. К примеру, роутинг и система шаблонов не такие — они реализованы в «юзер-спейсе», то есть этот код может быть написан разработчиком приложения без использования каких либо внутренних API. Поэтому если вам не нравятся наш роутинг или система шаблонов — вы можете заменить их своими. Наш текущий прототип системы шаблонов представляет из себя около 30 строк кода на C#, так что вы легко сможете разобраться и переписать его если захочется.

Развёртывание

Очевидно, что значительная часть целевой аудитории Blazor это ASP.NET разработчики. Для них мы выпустим middleware для прозрачного хостинга UI на Blazor с такими дополнительными возможностями как пререндеринг на сервере.

Не менее важны для нас и разработчики пока совсем не использующие .NET. Чтобы Blazor был жизнеспособен для разработчиков, предпочитающих Node.js, Rails, PHP или любую другую серверную технологию, а то и вовсе пишущих serverless-приложения — мы абсолютно точно не будем требовать наличия .NET на сервере. Результат сборки Blazor-приложения — папка dist, в которой лежат только статические файлы. Мы можете раздавать их со страниц Github, из облачных хранилищ, через Node.js сервера и вообще через что угодно.

Общий код и netstandard

.NET standard это способ описать уровень возможностей, предоставляемых .NET рантаймом или требуемых .NET сборкой. Если ваш .NET рантайм поддерживает netstandard2.0 и ниже, и у вас есть сборка нацеленная на netstandard2.0 и выше, то вы сможете запустить эту сборку на этом рантайме.

Mono на WebAssembly будет поддерживать netstandard2.0 или более высокую версию (в зависимости от сроков выхода). Это означает, что вы сможете использовать свои .NET библиотеки и на бэкенде, и в браузерных приложениях. К примеру, у вас может быть проект с классами моделей бизнес логики — его можно будет использовать и на сервере, и на клиенте. И, конечно же, вы сможете скачивать пакеты из NuGet.

Однако не все .NET API имеют смысл в браузере. К примеру, вы не сможете слушать произвольный TCP сокет, так что System.Net.Sockets.TcpListener не будет делать ничего полезного. Также вы практически наверняка не должны использовать System.Data.SqlClient в браузерном приложении. И это не проблема, так как, во-первых, браузеры всё-таки поддерживают API, которые действительно нужны людям для создания веб-приложений, и во-вторых, у .NET standard есть механизм обработки для таких случаев. При вызове не применимых для конкретной платформы API базовая система классов (BCL) будет выбрасывать исключение PlatformNotSupported. В начале это может приводить к проблемам, однако со временем авторы NuGet-пакетов внесут изменения в свои библиотеки для поддержки разных платформ. Если .NET хочет двигаться в сторону самой бурно развивающейся платформы приложений в мире — это ступень, на которую придётся подняться.

Совместимость с JavaScript/TypeScript

Даже если вы пишете браузерное приложение на C#/F# — иногда бывает нужно подключить чужую JavaScript библиотеку или свой собственный код на JavaScript/TypeScript для вызова какого-нибудь нового браузерного API.

Это должно быть очень просто, так как стандарт WebAssembly спроектирован чтобы взаимодействовать с JavaScript (и это неудивительно) и мы можем легко использовать это в .NET коде.

Чтобы работать с чужими JavaScript библиотеками мы исследуем возможность использования определений типов TypeScript в C# коде с полным intellisense. Это сделает около 1000 самых популярных JS-библиотек очень простыми для интеграции.

Текущий подход для вызова чужих библиотек или вашего JS/TS кода из .NET это регистрация именованной функции в JS/TS файле. Например:

// Это JavaScript Blazor.registerFunction('doPrompt', message => < return prompt(message); >);

… и затем создаём обёртку для вызова из .NET:

// Это C# public static bool DoPrompt(string message) < return RegisteredFunction.Invoke("doPrompt", message); >

Подход с registerFunction имеет приятный бонус в виде хорошей работы с JavaScript-сборщиками вроде Webpack.

И, чтобы поберечь ваше время и нервы, команда Mono работает над библиотекой, которая пробросит стандартные браузерные API в .NET.

Оптимизация

Исторически .NET фокусировался на платформах, где размер приложения не такая уж большая проблема. Не имеет большой разницы весит ли ваше ASP.NET приложение 1МБ или 50МБ. Это средней степени проблема для десктопных или мобильных приложений. Но для браузеров размер загрузки очень критичен.

В защиту можно сказать, что .NET на WebAssembly скорее всего будет загружаться всего один раз. Ведь можно использовать стандартное HTTP кэширование (или даже модные штуки вроде service worker) чтобы гарантировать, что пользователь загрузит ядро рантайма только единожды. А если использовать CDN, то пользователь и вовсе может использовать результаты одной загрузки сразу в нескольких приложениях.

Всё это хорошо, однако я не думаю, что этого достаточно. Если рантайм будет весить 20МБ, то это всё равно слишком много, даже для единоразовой загрузки. Это же не браузерный плагин в конце концов — это обычное построенное по стандартам веб-приложение. Даже самая первая загрузка должна быть быстрой.

Поэтому мы прикладываем много усилий для уменьшения размера загрузки. Мы видим следующие 3 фазы оптимизаций:

1. Уменьшение рантайма Mono

Рантайм Mono содержит много специфичных для десктопа возможностей. Мы надеемся, что Blazor будет содержать урезанную версию Mono, которая существенно меньше, чем полный дистрибутив. При ручной попытке оптимизации я смог удалить около 70% из .wasm файла рантайма без нарушения работы базового приложения.

2. Уменьшение IL кода при публикации

Компоновщик (linker) .NET IL (основанный на компоновщике Mono) выполняет статический анализ, определяя какие части .NET-библиотек могут быть вызваны из вашего приложения, и удаляет всё остальное.

Это похоже на tree shaking в JavaScript, за разницей в том, что IL-компоновщик гораздо более точен и работает на уровне отдельных методов. Это позволяет убрать весь неиспользуемый код системной библиотеки, что даёт огромную разницу в большинстве случаев, часто уменьшая размер приложения ещё на 70+%.

3. Компрессия

Ну и наконец, самое очевидное — мы ожидаем что ваш сервер поддерживает HTTP-сжатие. Это обычно срезает ещё 75% объёма.

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

Так и зачем это всё нужно?

Нравится это вам или нет, но веб-разработка сильно изменится в ближайшие несколько лет. WebAssembly позволит веб-разработчикам выбирать из гораздо большего списка языков и платформ, чем когда либо. И это хорошо — наш мир наконец-то взрослеет. Разработчики серверного ПО и нативных приложений всегда могли выбирать язык и парадигмы, которые лучше всего подходят для решения их проблем, соответствуют культуре команды и подкреплены имеющимися знаниями. Мечтаете писать функциональщину на Haskell или Lisp для вашего финансового приложения? Хотите немного низкоуровневого C? Вы Apple-разработчик и хотите продолжить использовать свои знания Swift? Всё это придёт в веб.

Не пугайтесь. Это не значит, что вам нужно будет знать все эти языки. Это значит, что все мы станем обычными разработчиками ПО. Ваши текущие знания программирования для браузеров по прежнему актуальны и ценны, но у вас появятся новые пути выразить свои идеи и больше точек соприкосновения с другими сообществами разработчиков.

И наша инициатива состоит в том, чтобы поставить .NET в авангард этого движения, а не тащиться позади, отставая на годы.

Текущий статус

Чувствуете желание попробовать? Притормозите — мы всё ещё на очень ранних стадиях проекта. Пока ещё ничего не готово для скачивания и многое из вышеописанного в процессе разработки. Большинство из вас должны просто расслабиться и подождать, первые пре-альфа билды появится примерно через месяц.

Помните, на данный момент Blazor — эксперимент для команды ASP.NET. Нам потребуется несколько месяцев чтобы понять сможем ли мы сделать из него полноценный, поддерживаемый продукт. Мы ещё ничего не обещаем, поэтому не надо строить свои бизнес-планы вокруг Blazor!

Если же вы сильно заинтересовались, то посмотрите в репозиторий, попробуйте собрать его, позапускать тесты и приходите пообщаться с нами. Можете даже поискать // TODO комментарии и прислать Pull Request, или поделиться идеей о клёвой фиче.

От переводчика

В заключение приведу несколько интересных ссылок:

• Рабочая демка Blazor (загляните в developers tools!)
• Показ самого первого прототипа Blazor на NDC Oslo
• ASP.NET Community Standup со Стивом приуроченный к анонсу Blazor

Технологические аспекты проектирования веб-приложений c использованием фреймворка Blazor

Булыгин, Ю. В. Технологические аспекты проектирования веб-приложений c использованием фреймворка Blazor / Ю. В. Булыгин. — Текст : непосредственный // Молодой ученый. — 2023. — № 17 (464). — С. 11-13. — URL: https://moluch.ru/archive/464/102015/ (дата обращения: 30.10.2023).

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

Ключевые слова : Blazor, Razor, NET, Blazor Server, WebAssembly.

Blazor — фреймворк для создания веб-приложений на платформе.NET. Он позволяет разработчикам создавать одностраничные (Single Page Applications) и многостраничные (Multi Page Applications) приложения с использованием средств этой среды. Данный инструмент предоставляет способ использования языка C# и возможностей платформы.NET для создания веб-приложений, что может быть особенно полезно для разработчиков, которые уже знакомы с этими технологиями.

Для создания пользовательского интерфейса в Blazor используется синтаксис языка разметки Razor, являющийся на данный момент частью платформы ASP NET Core, который поддерживает язык С# и использует символ @ для перехода с языка разметки HTML на директивы языка Razor, а также вычисления выражений С# кода и отображения их как выходных данных HTML. Таким образом Razor позволяет разработчику использовать одновременно HTML-разметку и вставки кода на языке С#, которые определяют логику работы динамических элементов. Стоит отметить, что Blazor во многом является наследником более раннего продукта Microsoft Razor Pages и использует большинство идей этой технологии. Но в отличие от предыдущих.NET инструментов веб-разработки Blazor приобрел некоторые дополнения и избавился от существенных недостатков, получив возможность обработки и рендеринга приложения на стороне клиента, и необходимости писать логику клиента приложения на языке JavaScript, став полностью обслуживаемым на C#.

Из HTML-разметки и С# кода формируются компоненты — автономные части сочетающие описание пользовательского интерфейса и логики обработки динамического поведения данного интерфейса. Приложения на основе фреймворка Blazor создаются посредством сочетания данных компонентов, которые называются Razor компоненты (Razor Components). Компоненты являются классами и реализуются в виде файлов с расширением.razor, что позволяет использовать их многократно как элементы при построении в других Blazor, Razor Pages или MVC приложениях. Данные компоненты можно добавлять в HTML разметку страницы как тег, таким образом добавляя готовые элементы и собирая из них веб-страницы. Это позволяет не переписывать и не дублировать при необходимости уже имеющийся код. Поведение компонентов управляется атрибутами, которые дописываются в тег с названием компонента с необходимыми значениями. Добавление компоненту атрибутов осуществляется путем добавления в класс компонента нового свойства с ключевой аннотацией [Parameter]. Параметры могут передаваться не только между компонентами, но и из страниц и мастер страниц верхнего уровня для вложенных компонентов. Такой подход управления компонентами даёт возможность более гибкого и удобного повторного их использования. Компоненты могут быть связаны с URL-адресом посредством директивы @page и указания пути к его.razor файлу, тем самым наделяя их свойствами самостоятельной веб-страницы. Компоненты поддерживают обработку событий, которая производится посредством атрибута @on и связывает определяемое событие с исполнением метода компонента. Также как и в предыдущих.NET Blazor содержит концепцию мастер-страниц (layouts), которые служат шаблоном для создания унифицированного вида сайта. Посредством ключевого слова @bind может осуществляться связывание HTML-элементов с каким-либо методами, свойствами и значениями других элементов, а также событиями посредством атрибута @bind-event. Также для получения данных от сторонних сервисов расположенных за пределами приложения существует функция внедрения зависимостей (dependency injection), подключаемая директивой @inject.

Кроме того, Blazor имеет множество уже готовых инструментов и библиотек, которые могут помочь ускорить разработку и сделать ее более продуктивной. Например, Blazor предоставляет множество готовых компонентов пользовательского интерфейса, таких как кнопки, формы и таблицы, что может значительно упростить создание интерфейса приложения. Также присутствует поддержка всех более ранних функций из стека технологий.NET для веб-разработки, такие как маршрутизация, валидация, взаимодействие с библиотеками JavaScript и другие.

Данный фреймворк имеет две технологии реализации — WebAssembly, для одностраничных интерактивных сайтов, которая позволяет запускать код написанный на C# и.NET в браузере, и Blazor Server, где обработка операций, связанных с приложением, происходит за счет ресурсов сервера. Каждая из технологий имеет свои преимущества и недостатки. К преимуществам серверного приложения можно отнести: небольшой размер загружаемых данных и соответственно более быструю загрузку приложения, использование приложением возможностей сервера, повышение безопасности, так как база кода не предоставляется клиентам. К недостаткам Blazor Server приложения можно отнести более высокую задержку, так как каждое активное взаимодействие с пользователем ведёт к обращению на сервер, полную зависимость приложения от соединения с сервером, а также значительные требования к ресурсам сервера для ресурсоёмких и приложений с большим количеством пользователей. Клиентские приложения на технологии WebAssembly решают проблемы, связанные с зависимостью от соединения с сервером и нехваткой его вычислительных ресурсов, но имеют и существенный недостаток — загрузка приложений занимает значительно больше времени. Такое разделение технологий реализации также создаёт больше возможностей для оптимизации работы приложения. Так если для приложения более важным являются обновления в реальном времени или доступ к возможностям сервера (базы данных, шифрование) то оптимальным будет выбор с обработкой на стороне сервера. В случае же когда приложение должно иметь возможность работы в оффлайн-режиме или предполагает высокую вычислительную нагрузку (графические VR/AR приложения,3D-приложения, кодировщики аудио и видео, игры) то более оптимальным будет выбор технологии WebAssembly.

В целом, Blazor — это современный инструмент для создания веб-приложений, который имеет свои особенности и свою целевую аудиторию. Направление веб-разработки на платформе.NET имеет достаточно перспектив и активно развивается. На данный момент уже выпущена более новая технология.NET MAUI. В заключении можно отметить, что если вы уже знакомы с.NET и хотите использовать его для создания веб приложений, то данная платформа предоставляет достаточно технологий и инструментов для их реализации.

1. ASP.NET Core Blazor. — Текст: электронный // Microsoft Learn: [сайт]. — URL: https://learn.microsoft.com/en-us/aspnet/core/blazor/?view=aspnetcore-7.0 (дата обращения: 06.03.2023).
2. Справочник по синтаксису Razor для ASP.NET Core. — Текст: электронный // Microsoft Learn: [сайт]. — URL: https://learn.microsoft.com/ruru/aspnet/core/mvc/views/razor?view=aspnetcore-7.0 (дата обращения: 06.03.2023).
3. Руководство по фреймворку Blazor. — Текст: электронный // METANIT.COM — Сайт о программировании: [сайт]. — URL: https://metanit.com/sharp/blazor/ (дата обращения: 08.03.2023).
4. Blazor for Beginners: [серия видео-уроков] / Jeff Fritz // URL: https://www.youtube.com/playlist?list=PLdo4fOcmZ0oUJCA3DCzKT79Oe3kdKEceX (дата обращения: 08.03.2023). — Изображение (движущееся; двухмерное): видео.
5. Сравнение архитектуры ASP.NET Web Forms и Blazor. — Текст: электронный // Microsoft Learn: [сайт]. — URL: https://learn.microsoft.com/ru-ru/dotnet/architecture/blazor-for-web-forms-developers/architecture-comparison (дата обращения: 06.03.2023).
6. Defining routes. — Текст: электронный // Blazor University: [сайт]. — URL: https://blazor-university.com/routing/defining-routes/ (дата обращения: 06.03.2023).
7. JavaScript Interloop. — Текст: электронный // Blazor University: [сайт]. — URL: https://blazor-university.com/routing/defining-routes/ (дата обращения: 06.03.2023).
8. Blazor Server vs. Blazor WebAssembly: Four Ways In Which They Differ. — Текст: электронный // Round The Code -.NET blog and ASP.NET Core tutorials: [сайт]. — URL: https://www.roundthecode.com/dotnet/blazor/blazor-server-vs-blazor-webassembly-four-ways-in-which-they-differ (дата обращения: 06.03.2023).
9. Основы Razor. — Текст: электронный // Платформа.NET и C# от А до Я: [сайт]. — URL: https://csharp.webdelphi.ru/osnovy-razor/ (дата обращения: 08.03.2023).
10. Мостовой, Р. Доклад Blazor 9.11.2021. — Текст: электронный // URL: https://prog.msk.ru/downloads/blazor.pdf (дата обращения: 06.03.2023).

Основные термины (генерируются автоматически): HTML, NET, компонент, приложение, пользовательский интерфейс, создание веб-приложений, ASP, MAUI, MVC, возможность сервера.