Мы живем в эпоху веб-разработки, когда каждый месяц выпускается новый фреймворк или новый язык, который переносится в 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 открывает для нас в будущем.

использованная литература

обсуждения

* Движки JS оптимизируют код во время выполнения. Эта оптимизация ограничена из-за динамической природы JavaScript. Используя статический язык, такой как C/C++, можно оптимизировать код при компиляции самого wasm.

**Можно полностью использовать потоки с помощью SharedArrayBuffer (в настоящее время отключен) или библиотеки parallelJS с помощью веб-воркеров. wasm планирует предоставить полную функцию потоков после MVP.

Первоначально опубликовано на linkedin 7 мая 2018 г.