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 Core

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

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

Но это будет еще не скоро и это очень отдаленная перспектива.

Blazor WebAssembly

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

Посредством взаимодействия с JavaScript фреймворк Blazor WebAssembly может обращаться к DOM и API браузера.

Одним из преимуществ Blazor WebAssembly является то, что он может оптимизировать загружаемые сборки. В частности, при публикации приложения неиспользуемый код убирается линкером (компоновщиком) IL (Intermediate Language). Кроме того, все необходимые файлы среды выполнения .NET и загружаемых сборок кэшируются в браузере.

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

В то же время 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. В то же время для работы приложения необходима постоянная поддержка сетевого подключения.

Компоненты

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

Blazor

Недавно Microsoft представила .NET Core 3, а вместе с ним и Blazor — новый famework для написания Web-приложений. Прежде всего Blazor рассчитан на Fullstack-программистов, которые работали с ASP.NET MVC или/и ASP.NET Pages, но в отличие от данных Framework’ов в Blazor вся логика изменения UI реализована на всеми любимом C#. Теперь для “оживления” Web-сайта можно минимизировать использование js.

Как удалось реализовать это Microsoft?

Microsoft давно уже хотела “запихнуть” C# в Frontend. Ещё в далеком 2002 года Microsoft представила миру первую реализацию ASP.NET Web Forms. ASP.NET Web Forms была хороша, как и Win Forms, для своего времени. Но ASP.NET Web Forms не прошел проверку временем. Microsoft решила абстрагировать разработчиков Web Forms от самих Web-технологий. Таких как: HTTP, HTML, CS и т.д. В надежде, что миллионы разработчиков дескторных приложений для Windows перейдут на Web-приложения. Но с развитием Web’a ASP.NET Web Forms умер. И основные причины этому:

• Тяжеловесное состояние страница — современные Web-приложения требовали динамического контента, и в ASP.NET Web Forms решили эту проблему путем передачи гигантских данных между клиентом и сервером при любом изменение страницы;
• Отсутсвие четкого шаблона проектирования — за счет этого тестировать и отлаживать enterprise-приложения становилось тяжело, а иногда и просто не реально;
• Ограниченный контроль на HTML версткой — создание пользовательских элементов управления было не из легких задач.

Понимая это Microsoft переосмыслила framework для написания Web-приложений. Первым делом убрали абстракцию, теперь разработчик четко понимал что он разрабатывает Web-приложения, а не десктопное приложения в браузере. Как только убрали абстракцию то появился полный контроль над HTML,CSS и js. И это всё было подано с MVC паттерном. Так появился ASP.NET MVC.

Отличная Web-технология, которая позволяет писать хорошие приложения. ASP.NET MVC включает в себя Razor — движок представлений. Язык разметки Razor позволяет генерировать HTML страницы со вставками C# кода. Но для того, чтобы создать динамически изменяемый контент нужно использовать js.

И совсем недавно Microsoft представила новый framework Blazor. Blazor основан на технологии WebAssembly , которая позволяет запускать код, написанный на любом языке, в браузере. Это происходит за счет интерпретации кода в байт-кода.

Microsoft разрабытвает несколько видов приложений на Blazor:

• Blazor Client — это платформа для SPA-приложений, которая позволяет создавать интерактивные клиентские веб-приложения с помощью .NET. Это происходит благодаря загрузке .NET Framework’a и .NET Runtime на клиент (в настоящее время доступна только предварительная версия);
• Blazor Server — предоставляет поддержку размещения компонентов Razor на сервере в приложении ASP.NET Core, а обновления пользовательского интерфейса передаются через подключение SignalR

Для того, чтобы пощупать Blazor я создам приложение для ведение дел ToDos. Для начало выберу новый шаблон проекта, который доступен в Visual Studio:

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

А вот первое, что бросается в глаза это способ изменение настройки маршрутизации для приложения на Blazor в сравнение с настройка маршрутизации для приложения ASP.NET MVC. Для наглядности ниже я размещу код Configure :

Как видно из кода выше в Configure отсутствует настройка route, а вместо неё есть настройка endpoints. Данный подход взять из ASP.NET Pages. А за routing отвечает специальный компонент Router, который находится в App.razor:

Blazor как и Angular основан на компонентах, что упрощает повторное использование одно функционала в разных местах. Для меня, как для человека, который пришел в мир Web’a, из мира разработки десктопных и мобильных приложений на Windows, компонент — это UserControl из WPF или UWP. И с этой ассоциацией мне было легче понять, что такое компонент.

Основной компонент Route располагает (хостится) на обычной razor-странице. Ниже показан код _Host.cshtml:

Единственное, что меня смутило так это, что рендер компонента происходит через HTML-хэлпер. Скорей, всего в дальнейшем Microsoft откажется от такого подхода в сторону tag-хэлперов, и вместо строчки :

UPD: На сайту Microsoft можно увидеть текущею реализацию (https://docs.microsoft.com/en-us/aspnet/core/blazor/components?view=aspnetcore-3.1)

JS скрипт _framework/blazor.server.js используется для создания связи между сервером и клиентом через SignalR.

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

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

Для того, чтобы избавиться от зависимости реализации буду использовать принцип инверсии зависимостей. Для этого реализую интерфейс IToDoList:

Унаследую данный интерфейс классом ToDoList. И для того, чтобы система понимала экземпляр какого класса использовать при использование интерфейса IToDoList буду использовать встроенный контейнер внедрения зависимостей:

Теперь создадим новый компонент для нашего списка дел.

Любой Blazor-компонент состоит из двух блоков:

• HTML-разметка — отвечает за внешний вид компонента;
• Блок @code<> — отвечает за логику компонента.

Для начало я отображу текущий список дел. Для этого изменю ToDo.razor как показано ниже:

При инициализации данного компонента , метод OnInitializedAsync, происходит загрузка задач с помощью нашего сервиса ToDoList, при этом сервис я указал как абстракцию,а реализацию находит сама платформа:

Но отображать списка дел можно и с помощью обычных razor-страниц, для этого Blazor не нужен. Для того, чтобы воспользоваться всеми прелестями нового framework’a реализую возможность добавления новых задач. Для этого в компонент помещу input и при нажатие на Enter будет создаваться новая задача.

Создам новое приватное поле в блоке @code title, и укажу его в качестве text для только что созданного элемента input.

Теперь нужно подписаться на событие нажатие кнопки на Enter. И здесь началось самое интересное потому, я не сразу понял как это сделать.

Изначально мой вариант выглядел так:

Это казалось мне логичными потому, что любые вставки C# кода в HTML происходят с помощью директивы @. Но это не сработало.

При просмотре документации я обнаружил, что чтобы подписаться на событие нужно использовать следующий синтаксис:

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

Здесь меня ждал сюрприз. Текст, который вводит пользователь, не сохранялся.

Дело в том, что атрибут text=”@title” задавал значение свойству text элементу input при рендере страницы, но не обеспечивал связь между свойством элемента и полем блока @code.

Нужен был некий механизм привязки…

И да, данный механизм есть в Balzor. После не большего изменение, элемент input выглядит следующим образом:

Однако, после тестирование я выяснил, что значение поле title изменяется после потери фокуса на элементе input. Меня такой вариант не устраивал и после не большего пояска я нашел решение. После небольших исправлений код элемента input выглядит следующим образом:

Выглядит не плохо, с учетом того, что вся логика добавление новых задач реализована на C#.

Теперь во мне взыграл интерес: а что ещё я смогу сделать?

Я выделил для себя несколько функций, которые можно добавить к приложению:

• Не отображать завершенные задачи;
• Показывать общие число отображаемых задач;
• Возможность выбора отображения: показывать все задачи или показывать не завершенные задачи.

На мой взгляд внимание заслуживает последний пункт, а реализацию остальных возможностей можно посмотреть на GitHub’e.

Для начало добавлю возможность переключения списка задач, которые будут отображаться. Ниже показан добавленный код:

Свойства showNotDone будет отвечать за генерацию необходимого фильтра. Сам фильтр будет реализован с помощью метода:

.NET & Blazor. Создание веб-приложения на основе браузера

1179

В рамках сегодняшней статьи я рад представить новый экспериментальный проект от команды ASP.NET под названием Blazor. Что такое Blazor? Blazor – это экспериментальный веб UI – фреймворк на базе C#, Razor и HTML, который работает непосредственно в браузере посредством WebAssembly. Цель эксперимента – в значительной мере упростить задачу построения простых и качественных одностраничных приложений, которые могут быть запущены в рамках любого браузера. Достигается это за счет написания .NET веб-приложений, которые при помощи открытых веб-стандартов могут запускаться на стороне клиента.

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

Зачем использовать .NET для браузерных приложений?

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

Тема связана со специальностями:

• Стабильность и целостность: инструменты стандарта .NET на протяжении многих лет зарекомендовали себя в качестве надежных помощников при разработке приложений.
• Современные инновационные языки: с использованием C# и F# процесс создания программ, по сути, становится чем-то вроде развлечения, настолько широким спектром возможностей эти языки обладают.
• Популярная среда разработки: стек IDE Visual Studio обеспечивает максимальное удобство работы с Windows, Linux и macOS.
• Быстрота вычислений: .NET обладает длинной историей по улучшению производительности, надежности и защиты веб-приложений для серверов. Соответственно, при разработке full-stack .NET приложений все указанные преимущества также ощущаются.

Browser + Razor = Blazor!

Blazor базируется на существующих веб-технологиях, таких как HTML и CSS, но в этом случае для создания UI-элементов вы используете C# и Razor – синтаксис вместо JavaScript. Однако отметьте, что это не то же самое, что и деплой существующего проекта UWP или Xamarin в браузер.

• Компонентную модель для построения комплексных UI
• Маршрутизацию
• Слои
• Формы и валидацию
• Внедрение зависимостей
• Поддержку JavaScript
• Перезагрузку в браузере во время разработки «вживую»
• Рендеринг на стороне сервера
• Полноценную поддержку .NET – отладки (как в браузере, так и в IDE)
• IntelliSense и прочие различные инструменты
• Возможность запускать более старые (не WebAssembly) браузеры через asm.js
• Публикацию и мониторинг размера приложения

Видео курсы по схожей тематике:

C# Базовый (ООП) 2021

Выполнение домашнего задания по курсу C# Базовый

Изменения WebAssembly

Запуск .NET – приложений в браузере стал возможен благодаря WebAssembly, новому веб-стандарту для «портативных, умеренных в размерах и быстрых» веб-приложений. Таким образом, WebAssembly вводит фундаментально новый способ построения веб-приложений, так как код, скомпилированный под WebAssembly, не уступает скорости нативных .NET-приложений. Никаких прочих сторонних зависимостей нам не нужно: вы можете запустить обычные .NET-сборки в браузере с использованием WebAssembly.

В августе прошлого года наши друзья из команды Xamarin Microsoft анонсировали планы по созданию Mono .NET специально для браузеров с использованием все той же WebAssembly. По сути, Blazor частично базируется на результатах их работы.

Новый эксперимент

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

Я хочу попробовать!

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

Пожалуйста, отметьте, что технология находится в статусе раннего доступа. Здесь еще нет никаких инсталляторов или шаблонов проектов, кроме того, многое из заявленного еще не реализовано. Даже то, что уже сделано, не оптимизировано. Если вам интересно, вы можете загрузить репозиторий, построить его и протестировать, но пытаться на его базе разработать рабочий проект – задумка явно не удачная. Что же касательно предложений и поддержки, вы можете использовать issue tracker репозитория. Через месяц мы планируем выпустить первые черновые версии заготовок веб-проектов и инструментов, сделав технологию более доступной для широкой аудитории.

Бесплатные вебинары по схожей тематике:

Практический опыт миграции с Web API на микросервисную архитектуру (продолжение)

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:

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

Многие шаблоны проектирования могут быть построены на этом простом фундаменте, включая популярные паттерны из 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 файле. Например:

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

Подход с 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, или поделиться идеей о клёвой фиче.