Введение в 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#.
ASP.NET Core Blazor
Платформа Blazor предназначена для создания интерактивного веб-интерфейса на стороне клиента с использованием Blazor и предоставляет следующие возможности:
- создание многофункциональных интерактивных пользовательских интерфейсов на C# вместо JavaScript;
- совместное использование серверной и клиентской логик приложений, написанных с помощью .NET;
- отображение пользовательского интерфейса в виде HTML-страницы с CSS для широкой поддержки браузеров, в том числе для мобильных устройств.
- интеграция с современными платформами размещения, такими как Docker.
- создание гибридных классических и мобильных приложений с помощью .NET и Blazor;
- создание многофункциональных интерактивных пользовательских интерфейсов на C# вместо JavaScript;
- совместное использование серверной и клиентской логик приложений, написанных с помощью .NET;
- отображение пользовательского интерфейса в виде HTML-страницы с CSS для широкой поддержки браузеров, в том числе для мобильных устройств.
- интеграция с современными платформами размещения, такими как Docker.
Использование .NET для разработки веб-приложений на стороне клиента предоставляет следующие преимущества:
- создавайте код на C#, а не на JavaScript.
- возможность использовать существующую экосистему .NET с библиотеками .NET;
- сохранение единой логики приложений для сервера и клиента;
- высокая производительность, надежность и безопасность платформы .NET;
- Сохраняйте продуктивность в Windows, Linux или macOS с помощью среды разработки, такой как Visual Studio или Visual Studio Code.
- создавайте приложения на основе распространенных языков, платформ и инструментов, которые отличаются стабильностью, широким набором функций и простотой в использовании.
Краткое руководство по Blazor см. в статье Blazor.
Компоненты
Приложения Blazor основаны на Blazor. Компонентом Blazor называется любой элемент пользовательского интерфейса, например страница, диалоговое окно или форма ввода данных.
Компоненты являются классами C# .NET, встроенными в сборки .NET, которые:
- определяют гибкую логику визуализации пользовательского интерфейса;
- обрабатывают действия пользователя;
- можно вкладывать друг в друга и использовать повторно;
- можно совместно использовать и распространять в виде библиотек классов или пакетов NuGet.
Класс компонента обычно записывается в виде страницы разметки Razor с расширением файла .razor . Компоненты в Blazor обычно называются Blazor (или Razor). Синтаксис Razor сочетает разметку HTML с кодом C#, позволяя повысить производительность разработчиков. Razor позволяет переключаться между разметкой HTML и кодом C# в одном файле благодаря программной поддержке Razor в Visual Studio. Синтаксис Razor применяется также для Razor Pages и MVC. В отличие от Razor Pages и MVC, которые построены по модели «запрос-ответ», компоненты используются специально для логики пользовательского интерфейса на стороне клиента и для компоновки.
Blazor использует естественные теги HTML для компоновки пользовательского интерфейса. В следующем примере разметки Razor демонстрируется использование компонента ( Dialog.razor ), который отображает диалоговое окно и обрабатывает событие, когда пользователь нажимает кнопку:
В предыдущем примере метод C# OnYes инициируется событием кнопки onclick . Текст ( ChildContent ) и заголовок ( Title ) диалогового окна предоставляются описанным ниже компонентом, который использует этот компонент в пользовательском интерфейсе.
Компонент Dialog вложен в другой компонент с помощью HTML-тега. В следующем примере компонент Index ( Pages/Index.razor ) использует предыдущий компонент Dialog . Атрибут Title тега передает значение заголовка в свойство Title компонента Dialog . Текст компонента Dialog ( ChildContent ) определяется содержимым элемента <Dialog> . Если компонент Dialog добавлен в компонент Index , Dialog позволяет ускорить разработку за счет дополнения элементов синтаксиса и параметров.
Когда к компоненту Index осуществляется доступ в браузере, отображается диалоговое окно. Когда пользователь нажимает кнопку, в консоли средств разработчика браузера отображается сообщение, созданное методом OnYes :
Компоненты преобразуются в хранящееся в памяти представление модели DOM для браузера, которое называется деревом отображения, позволяя гибко и эффективно обновлять пользовательский интерфейс.
Blazor Server
Blazor Server предоставляет поддержку размещения компонентов Razor на сервере в приложении ASP.NET Core. Обновления пользовательского интерфейса передаются через подключение SignalR.
Среда выполнения остается на сервере и обрабатывает:
- выполнение кода C# приложения.
- отправка событий пользовательского интерфейса из браузера на сервер;
- применение полученных с сервера обновлений пользовательского интерфейса к отображаемому компоненту.
Подключение, используемое Blazor Server для обмена данными с браузером, также применяется для обработки вызовов взаимодействия JavaScript.
Приложения Blazor Server отрисовывают содержимое по-другому, чем традиционные модели для отрисовки пользовательского интерфейса в приложениях ASP.NET Core с помощью представлений Razor или Razor Pages. В обеих моделях используется язык для описания отрисовываемого содержимого HTML, но они значительно отличаются по способу отрисовки разметки.
При отрисовке страницы или представления Razor каждая строка кода Razor выдает HTML в виде текста. После отрисовки сервер удаляет экземпляр страницы или представления, включая все созданные состояния. При поступлении другого запроса страницы вся страница снова перерисовывается в HTML и отправляется клиенту.
Blazor Server создает граф компонентов, которые отображаются аналогично HTML-или XML-модели DOM. Граф компонента включает в себя состояние, содержащееся в свойствах и полях. Blazor оценивает граф компонентов для создания двоичного представления разметки, отправляемого в клиент для отрисовки. После соединения между клиентом и сервером статические предварительно отрисованные элементы компонента заменяются интерактивными элементами. Предварительная отрисовка содержимого на сервере позволяет приложению более быстро реагировать в клиенте.
Когда компоненты становятся интерактивными в клиенте, обновления пользовательского интерфейса запускаются за счет взаимодействия с пользователем и событий приложения. При обновлении граф компонентов перерисовывается, и в пользовательском интерфейсе вычисляется разница (различия). Эта разница является наименьшим набором изменений DOM, необходимых для обновления пользовательского интерфейса на клиенте. Разница отправляется клиенту в двоичном формате и применяется в браузере.
Компонент уничтожается после того, как пользователь выходит из него.
Blazor WebAssembly
Blazor WebAssembly — это Blazor WebAssembly для создания интерактивных клиентских веб-приложений с использованием .NET. Blazor WebAssembly использует открытые веб-стандарты без подключаемых модулей или перекомпиляции кода на другие языки. Blazor WebAssembly работает во всех современных веб-браузерах, включая браузеры мобильных устройств.
Выполнение кода .NET в веб-браузерах становится возможным благодаря технологии WebAssembly (сокращенно ). WebAssembly — это компактный формат байт-кода, оптимизированный для быстрой загрузки и максимального быстродействия. WebAssembly — это открытый веб-стандарт, который поддерживается в веб-браузерах без подключаемых модулей.
Код WebAssembly может обращаться к любым функциям браузера через JavaScript благодаря поддержке взаимодействия с JavaScript (сокращенно JavaScript interop или JS interop). Код .NET, который обрабатывается через WebAssembly в браузере, выполняется в песочнице для JavaScript этого браузера, которая включает средства защиты от вредоносных действий на клиентском компьютере.
Когда приложение Blazor WebAssembly создано и запущено в браузере:
- Файлы кода C# и файлы Razor компилируются в сборки .NET.
- Сборки и среда выполнения .NET загружаются в браузер.
- Blazor WebAssembly осуществляет начальную загрузку среды выполнения .NET и настраивает ее для загрузки сборок для приложения. Среда выполнения Blazor WebAssembly использует взаимодействие с JavaScript для обработки операций с моделью DOM и вызовов API браузера.
Размер опубликованного приложения, также называемый размером полезных данных, является критически важным фактором для удобства работы с приложением, влияющим на производительность. Крупное приложение скачивается в браузере довольно долго, что ухудшает взаимодействие с пользователем. Blazor WebAssembly оптимизирует размер полезных данных, чтобы сократить время скачивания:
- При публикации неиспользуемый код исключается из приложения средством обрезки для промежуточного языка.
- HTTP-ответы сжимаются;
- среда выполнения и сборки .NET кэшируются в браузере.
Blazor Hybrid
Гибридные приложения используют смесь нативных и веб-технологий. Приложение Blazor Hybrid использует Blazor в нативном клиентском приложении. Компоненты Razor выполняются изначально в процессе .NET и отрисовывают веб-интерфейс во встроенном элементе управления Web View с помощью локального канала взаимодействия. WebAssembly не используется в гибридных приложениях. Гибридные приложения используют следующие технологии:
-
: кросс-платформенная платформа для создания собственных мобильных и классических приложений с помощью C# и XAML. —это платформа пользовательского интерфейса, которая не зависит от разрешения и использует векторный механизм визуализации, способный использовать все преимущества современного графического оборудования. — это платформа пользовательского интерфейса для создания многофункциональных клиентских классических приложений для Windows. Платформа разработки Windows Forms поддерживает широкий набор функций для разработки приложений, включая элементы управления, графику, привязку данных и ввод пользователя.
Дополнительные сведения о создании приложений Blazor Hybrid с помощью предыдущих платформ см. в следующих статьях:
Взаимодействие с JavaScript
Для приложений, которым требуются сторонние библиотеки JavaScript и доступ к API браузера, компоненты взаимодействуют с JavaScript. Компоненты могут использовать любую библиотеку или API, которые может использовать JavaScript. Код C# может вызывать код JavaScript, а код JavaScript — код C#.
Совместное использование кода и .NET Standard
Blazor реализует Blazor, что позволяет проектам Blazor ссылаться на библиотеки, которые соответствуют спецификациям .NET Standard. .NET Standard — это формальная спецификация API-интерфейсов .NET, которые доступны во всех реализациях .NET. Библиотеки классов .NET Standard можно использовать на разных платформах .NET, таких как Blazor, .NET Framework, .NET Core, Xamarin, Mono и Unity.
API, которые не используются в веб-браузере (например, для доступа к файловой системе, открытия сокетов и работы с потоками), создают исключение PlatformNotSupportedException.
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, или поделиться идеей о клёвой фиче.