Мы живем в эпоху веб-разработки, когда каждый месяц выпускается новый фреймворк или новый язык, который переносится в JavaScript. Поэтому, как правило, когда вы слышите о выпуске другого фреймворка, естественно избегать его. Если бы это был просто другой фреймворк, я бы сделал то же самое, но не для этого исключительного случая. Возможно, вам было интересно, Браузер + Razor = Blazor. В этой статье мы попытаемся немного рассказать об этой экспериментальной технологии Microsoft и возможностях, которые она предлагает.
Текущее состояние веб-приложений
Прежде чем мы углубимся в Blazor, нам нужно знать текущие ограничения веб-разработки или, более конкретно, веб-приложений (включая те, которые работают в веб-просмотре). Это дало бы нам четкое представление о том, зачем нам нужна Web Assembly.
Все работает на JavaScript, медленно.
Интернет теперь работает на JavaScript, основном клиентском языке, который был переведен на серверную часть благодаря Node и Google V8. JavaScript великолепен, он отлично работает, имеет миллионы фреймворков и библиотек, которые можно использовать для разработки. У нас есть много языков, на которых мы можем генерировать код JavaScript, выполнять проверку типов, запускать тестовые примеры и многое другое. Так в чем проблема?
это медленно. Весь JavaScript в вашем приложении должен быть проанализирован и преобразован в байт-код перед началом выполнения*. и текущие движки JS недостаточно быстры. Кроме того, многопоточность невозможна в JS**, что может быть проблемой, если вашему приложению необходимо обрабатывать много данных на стороне клиента.
На приведенном выше рисунке (любезно предоставленном arewefastyet.com) показана скорость работы различных браузеров в Mac OS X. Если вы посмотрите на приведенные выше данные, то можно сказать, что с прошлого года особых улучшений в скорости работы движка не произошло. Кроме того, невозможно быстро запустить JavaScript из-за нескольких слоев между кодом и байт-кодом.
Но у нас есть решение для этого. Если браузеры могут получать данные в двоичном формате более низкого уровня, выполнение может быть быстрее. Решение — WebAssembly.
Используя Web Assembly (или Wasm), мы можем запускать приложение почти на исходной скорости. Кроме того, мы можем обмениваться данными между JavaScript и Wasm с помощью JavaScript API.
Wasm предоставляет цель компиляции для C/C++ и генерирует низкоуровневый текстовый формат для легкой отладки в инструментах разработчика браузера. Это позволяет нам писать приложения на любом языке, который можно скомпилировать в Wasm.
Мы любим статику!
И тому есть причина. Говорят, что использование языка со статической типизацией может уменьшить количество ошибок до 15%. Несмотря на то, что этот момент широко обсуждается, есть и другие преимущества, которые стоят усилий. Статическая типизация помогает IDE предоставлять лучшие функции, такие как переход к определению и информацию о функции, что сложно сделать в динамической типизации.
Разработчику легче ознакомиться с приложением, написанным на языках со статической типизацией, чем с языком с динамической типизацией.
Приложение с динамической типизацией становится кошмаром, если в нем нет комментариев (или, что еще хуже, если комментарии лгут). Это не относится к статической типизации.
Нам нужно приложение для Android/iOS!
Что ж, если у вас есть веб-приложение, вашей очевидной следующей целью будет создание приложения для Android/iOS. Э-э, теперь это немного сложно, должен ли я использовать веб-просмотры и предоставлять пользователям посредственный опыт? или я должен создать собственное приложение, которое съедает большую часть часов разработки, особенно когда вы пытаетесь разрабатывать для многих платформ? Microsoft предлагает одно решение для этого сценария — Xamarin.
Теперь вам не нужно писать отдельное приложение для Android, iOS и UWP. Но вам все равно нужно написать код, который вы написали на JavaScript. Это не что иное, как написание одного и того же кода на другом языке.
Переписывание логики приложения может быть радикально сведено к минимуму, если логика приложения находится в отдельном проекте, к которому имеют доступ все, особенно когда мы включаем веб-приложение!
Это, в свою очередь, позволяет очень быстро исправить ошибку, минимизируя кодовую базу.
Тестирование — это головная боль (всегда)
Если у вас есть веб-приложение, приложение для iOS, приложение для Android, приложение UWP, тестирование — это кошмар. Вам нужно поддерживать отдельные наборы тестов для каждого. Даже после использования Xamarin вам нужно писать отдельно для веб-приложения. Но с Blazor, работающим на .NET, ваши тестовые примеры для Xamarin подходят и для веб-приложений. На самом деле вам нужно запустить тесты только один раз, чтобы проверить логику приложения. Это уменьшает количество тест-кейсов, которые вам нужно поддерживать, теоретически сводит к нулю количество переписываемых тест-кейсов и уменьшает число платформ, на которых вы эффективно пишете тест-кейсы, до 1.
Итак, JavaScript умрет?
Нет. JavaScript — это универсальный язык браузера, который перешел от простого чтения страницы к «приложению». Wasm предназначен для работы вместе с JavaScript, а не для его замены. Blazor — одна из многих платформ, которые будут использовать эту технологию для создания чего-то действительно великолепного. Это не означает, что JavaScript будет отодвинут на второй план. Майкрософт прекрасно об этом знает. Следовательно, планируется поддерживать взаимодействие JavaScript в Blazor.
Что теперь?
Должен ли я бежать за Блазором? Еще нет. Это все еще экспериментальная технология, и она может не сработать. Даже если Microsoft выпустит это как продукт где-то через год, вам нужно будет широко использовать .NET (от веб-приложения до нативного приложения). Microsoft может не предоставить возможность использовать только библиотеку .NET на стороне клиента, что заставит вас переписать существующую кодовую базу на C#. Кроме того, большинство сторонних библиотек JavaScript могут не работать с Blazor и могут потребовать написания оболочки. Тем не менее, я в восторге от миллионов возможностей, которые WebAssembly открывает для нас в будущем.
использованная литература
- Мы еще быстры?
- Репозиторий ASP.NET Blazor
- Веб-сборка
- MDN: документация по веб-сборке
- Новый эксперимент: браузерные веб-приложения с .NET и Blazor
- Печать или не печатать: количественная оценка обнаруживаемых ошибок в JavaScript
- Путь к параллельному JavaScript
- Спекулятивное выполнение атаки по сторонним каналам («Спектр)»
- WebAssembly — дизайн/потоки
обсуждения
* Движки JS оптимизируют код во время выполнения. Эта оптимизация ограничена из-за динамической природы JavaScript. Используя статический язык, такой как C/C++, можно оптимизировать код при компиляции самого wasm.
**Можно полностью использовать потоки с помощью SharedArrayBuffer (в настоящее время отключен) или библиотеки parallelJS с помощью веб-воркеров. wasm планирует предоставить полную функцию потоков после MVP.
Первоначально опубликовано на linkedin 7 мая 2018 г.