И что мы можем сделать, чтобы вывести его из лаборатории?

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

Tl;Dr: Web Assembly обладает таким большим потенциалом, но он не получит значимого распространения, пока люди не смогут использовать его для решения не только узкоспециализированных задач. Давайте коснемся модели DOM.

Обещание

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

Когда Web Assembly была представлена ​​почти десять лет назад, она описывалась как решение многих различных веб-ориентированных проблем, и я с нетерпением наблюдал за ее развитием, ожидая дня, когда я смогу ее использовать.

Больше никаких транспиляторов!

Одной из проблем, которую он пытался решить, был шаблон компиляции кода в код (транспиляция), широко используемый разработчиками веб-приложений.

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

        Source Code
            ↓
  Webpack + Babel + Terser
            ↓
Smaller Unreadable JavaScript

Web Assembly обещает использовать более эффективный байт-код в качестве цели компиляции для этих вариантов использования, что позволяет создавать меньшие «пакеты», которые анализируются быстрее.

      Source Code
           ↓
WASM JavaScript Compiler
           ↓
     Tiny WASM Binary

Несколько языков

В настоящее время можно преобразовать многие языки в Интернет, используя методы транспиляции кода в код.

Существует компилятор Go to JavaScript, и знаменитые TypeScript, CoffeeScript, ClojureScript конвертируют исходный код в JavaScript. Этот подход работает, но оставляет желать лучшего.

Могут быть специфичные для языка функции, которые нельзя эмулировать в результирующем выводе JavaScript (например, параллелизм в Go), и вы рискуете плохой поддержкой сторонних библиотек.

Двоичный формат Web Assembly предлагает цель компиляции, которая не ограничена языковой функцией, ограничивающей использование JavaScript при использовании в качестве цели компиляции.

Поэтому стоит потратить время на поддержку языка, чтобы предложить официальную поддержку Web Assembly в качестве цели компиляции.

Убийца JavaScript?

Мантра гласит, что Web Assembly не убьет JavaScript, и по большей части это правда.

Когда мы смотрим на историю веб-технологий, переход к веб-приложениям, которые размещают большую часть логики в клиенте, не «убивает» php или другие технологии пользовательского интерфейса, управляемые сервером.

На самом деле существуют десятки простых веб-сайтов, работающих на WordPress и подобных им, которые работают на JavaScript, и они никуда не денутся.

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

Когда мы смотрим на растущее желание писать одностраничные приложения, которые напоминают нативные мобильные и настольные приложения, мы видим, что они приносят с собой некоторые из тех же концептуальных проблем, что и нативные приложения, но на платформе, которая не предлагает такие же вспомогательные наборы инструментов пользовательского интерфейса. для обработки сложного поведения (например, навигация, многопоточность и т. д.).

Я не могу переоценить важность многопоточности в клиентских приложениях — то, что JavaScript не поддерживает качественно, и это одна из причин, по которой нативные приложения работают более плавно и производительно.

Естественная эволюция

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

Полифилы и прогрессивное улучшение доминируют, поскольку проекты, которые жаждали новых функций, пытались получить их раньше.

Хотя приложения Electron/PhoneGap не были (напрямую) связаны с Web Assembly, они начали появляться, поскольку относительно низкая стоимость разработки веб-приложений в сочетании с их переносимостью платформы сделала их очевидным выбором при распространении приложений на Windows, MacOS, Linux (шутки, кто разрабатывается для Linux 😭), iOS и Android.

Сейчас мы видим веб-фреймворки на Rust и Go, которые создают целевую веб-сборку, несмотря на то, что для их функционирования необходимо реализовать безумное количество связующего кода.

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

JavaScript, каждый язык

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

Web Assembly представляет собой фундаментальный сдвиг в этом мышлении.

Если бы компания, которая любит функциональное программирование, могла использовать полный Closure или F#, им было бы все равно, реализует ли ES оператор конвейера.

Если бы компания, которая любит объектно-ориентированное программирование, могла использовать Java, C#, Kotlin, им было бы все равно, реализует ли ES декораторы.

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

А как насчет времени выполнения?

Среда выполнения должна быть предоставлена ​​вместе с вашим банером wasm, чтобы запустить код приложения.

Есть много стратегий для управления этим. Одним из подходов является «разделение кода» на среды выполнения, иначе называемые кэшируемыми средами выполнения, которые можно динамически связывать.

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

Сосредоточьтесь от JavaScript на DOM и функциях платформы

Предполагая, что Web Assembly обладает теми же возможностями, что и JavaScript, он предлагает разработчикам внешних языков возможность расширять и поддерживать свой язык независимо от браузера, что снижает нагрузку на разработчиков стандарта ES и разработчиков браузеров.

Я бы сказал, что развитие функций веб-платформы представляет большую ценность, чем развитие функций ES. Например;

Предоставление пользователю изолированного/безопасного нижнего уровня доступа к функциям ОС сделает такие проекты, как Electron, избыточными и предложит пользователям более эффективные настольные веб-приложения — такие проекты, как VSCode и Slack, действительно могут стать устанавливаемыми веб-приложениями, которые можно было бы лучше оптимизировать благодаря совместному использованию. тот же движок браузера, а не новый независимый процесс Electron.

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

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

Итак, где мы сегодня?

Легко (и непопулярно) критиковать прогресс, который мы наблюдаем в развитии Web Assembly, но я думаю, что полезно спросить, где мы находимся, попытаться понять, что нас ждет в будущем, и найти, где мы можем помочь. .

Академический, в основном

Разработка Web Assembly в основном была академической работой, и с этой точки зрения она добилась значительного прогресса.

Однако, когда мы смотрим на коммерческие (и увлеченные проекты) приложения Web Assembly сегодня, они ограничены и обременены сложностью интеграции.

Удивительно видеть такие библиотеки, как ffmpeg и библиотеки сжатия изображений, перенесенные в Интернет через Web Assembly, однако в моих повседневных усилиях по веб-разработке я редко сталкиваюсь с вариантом использования, когда мне нужно сжимать/преобразовывать видео/изображения в браузер способами, которые оправдывают дополнительную сложность интеграции модуля wasm (ранее я сжимал изображения перед загрузкой с помощью холста).

В своем нынешнем виде Web Assembly — это, по сути, просто сложно интегрируемый Web Worker, который можно писать на языках, отличных от JavaScript. За исключением некоторых случаев использования wasm представляет собой чистую потерю в производительности приложения.

У Web Assembly проблемы с вниманием и пиаром

Люди, участвующие в проекте Web Assembly, невероятно умны и поэтому определили, что проект потенциально может быть абстрагирован, чтобы его можно было использовать для решения проблем за пределами веб-домена.

Однако без общей способности среднего веб-разработчика использовать Web Assembly практически для чего угодно — это не совсем тот проект, который заслуживает того внимания, которого он заслуживает.

Я считаю, что Web Assembly пошла по пути преждевременной абстракции, прежде чем предоставить продукт, который вызовет интерес к его дальнейшей разработке.

Чтобы представить, как давно была анонсирована Web Assembly, вот некоторые события, произошедшие примерно в то время, когда она была анонсирована, и после:

  • React находился в стадии альфа-тестирования и с тех пор перешел на версию 18.
  • Vue находилась в стадии альфа-тестирования и с тех пор перешла на версию 3.
  • Был анонсирован Angular 2, и с тех пор он перешел на версию 14.
  • Выпущен первый стабильный выпуск Rust (v1)
  • Версия ядра Linux по-прежнему была 3.x.x , сейчас 5.x.x.
  • Chrome был версии 30, сейчас 103.
  • Объявлено Windows 10 и выпущена Windows 11
  • Мы были на iPhone 6
  • Сенсорная панель MacBooks еще не существовала
  • Обама был президентом США

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

Что ты можешь сделать?

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

Однако инженеры могут вносить свой вклад в Web Assembly, не внося прямого вклада в спецификацию, определяя, почему они этого хотят, и призывая к инвестициям в нее.

Для чего вы хотите его использовать?

Мне кажется важным задать вопрос: для чего вам нужна веб-сборка?

Означает ли Web Assembly, что такие проекты, как Angular, Svelte и Vue, которые используют компиляторы для преобразования синтаксиса своего шаблона в оптимизированные для AoT инструкции по манипулированию DOM, могут заново изобретать себя, избавляясь от ограничений своих хакерских/ограничивающих подходов к обнаружению мутаций (исправление обезьяны, zone.js, Прокси-ловушки).

Означает ли Web Assembly, что вы можете взять существующее строгое приложение TypeScript React и без изменений отправить меньший двоичный файл, который будет быстрее и эффективнее?

Означает ли Web Assembly, что вы можете создать свой следующий SPA на C++, Rust или Go и сделать из него многопоточность?

Что это значит для вашего продукта/компании?

Когда вы думаете о том, что вам нужно от Web Assembly, относится ли это к существенному улучшению вашего продукта?

  • Улучшит ли это производительность приложений, улучшив качество обслуживания клиентов?
  • Позволит ли более эффективная работа распространить ваше приложение на большее количество устройств, привлекая больше потребителей?
  • Предлагает ли перспектива использования того же языка на клиенте, что и на сервере, возможность совместного использования кода/моделей, что повышает стабильность платформы?
  • Позволяет ли языковая однородность сосредоточить свои требования на найме на одном языке и лучше использовать имеющиеся инженерные ресурсы?

Можете ли вы дать количественную оценку улучшения Web Assembly?

Более того, можете ли вы в финансовом отношении оценить, как поможет Web Assembly?

Обратитесь к соответствующим компаниям и спонсорам с просьбой инвестировать интерес и время в разработку или пропаганду их вариантов использования, которые будут представлены в Web Assembly!

Проект живет или умирает благодаря участию, и если обещания, которые он предлагает, никого не вдохновляют, участие сойдет на нет.