На сайте Sitepoint была недавно опубликована статья под названием: Жизнь после JavaScript: преимущества изучения второго языка, в которой указывался на растущий вопрос о росте популярности Web Assembly. :

Чем станет JavaScript, когда появится возможность писать более быстрые веб-приложения с использованием более низкоуровневых языков? (и как насчет будущего разработчиков JavaScript?)

Автор статьи спросил своих читателей, к какому второму языку мы, разработчики JavaScript, более склонны обращаться. В ответ я написал длинный комментарий, который на удивление был помечен как «спам». Что бы ни! Это повод начать писать полные сообщения в блог, так что вперед ...

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

В то время как Web IDL, используемый для стандартизации веб-API, сначала был разработан как независимый от языка (с реализациями Java, VB и JS), Web IDL второе издание гораздо больше зависит от JavaScript с полным разделом привязки ECMAScript. На сегодняшний день все члены рабочей группы по веб-API думают об использовании с точки зрения JavaScript. Чтобы другие языки полностью переняли JavaScript, им, вероятно, потребуется время, чтобы:

  • соответствовать требованиям второй редакции Web IDL (изначально или через библиотеки)
  • дождитесь разделов выделенной привязки во втором издании Web IDL
  • или дождитесь третьего издания Web IDL.

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

Веб-сайты и веб-приложения Доступность полагаются на элементы и атрибуты HTML DOM (например, ARIA), и многие учреждения или законы требуют, чтобы многие из них были доступны. Рендеринг холста уже является проблемой на этом этапе, поэтому я позволю вам представить, с помощью веб-сборки, если не используется DOM. При собственной разработке для настольных и мобильных приложений доступность обеспечивается основными фреймворками через собственные компоненты пользовательского интерфейса и через выделенные API. Так что, если программы веб-сборки используют DOM для рендеринга, то производительность будет намного более сопоставимой с таковой на JavaScript.

Так что, по крайней мере, в первую очередь, Web Assembly в основном позволит писать очень родные сопоставимые быстрые модули для дорогостоящих или разумных вычислений, таких как: видео и аудиокодеки, игровая анимация, настраиваемые алгоритмы сжатия, потенциальные модули DRM EME (Cisco? Verimatrix ? Nagra?…), Некоторые шифры шифрования безопасности… Многие вещи, которые нам пришлось ждать, пока не будет реализован поставщик браузеров, могут упроститься в виде модулей wasm для веб-приложений.

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

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

Затем многие веб-разработчики могут захотеть вернуться к разработке дополнительных основных функций и начать использовать язык, который компилируется в веб-сборке, но какой?

Итак, Брендан Эйх сказал также, что из-за динамической природы JavaScript он не видел возможности скомпилировать JavaScript в веб-сборке в ближайшее время, что означает, что такое ограничение, вероятно, применяется к другим слабо типизированным / интерпретируемым языкам (PHP? Python ? Рубин? …). Это, вероятно, ограничит количество людей, начинающих использовать язык, который компилируется в веб-сборке.

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

  1. Rust из Mozilla
  2. Swift от Apple
  3. C # от Microsoft
  4. и Go (или Dart?) от Google

Поскольку поддерживается Mozilla, которая предоставляет компилятор веб-сборки (emcc), я не удивлюсь, увидев Rust как один из первых языков, поддерживающих emcc. И даже более того, теперь, когда браузер все больше и больше поддерживает многопоточность (V8 и AO по крайней мере являются поточно-ориентированными, веб-воркеры становятся все более и более поддерживаемыми, а SharedArrayBuffer уже на подходе), оптимизация параллелизма в Rust может быть интересна в этом контексте. . Обратите внимание, что Rust использовался Mozilla для написания совершенно нового браузера под названием Servo, поэтому он также может помочь быстрее открыть веб-API для этого языка.

Знакомые мне разработчики, использующие Swift, заявили, что его подходы близки к подходам JavaScript, а также как основной язык для программирования на платформах Apple (iPhone, iPad, Apple TV, предстоящая Apple Car OS, …), Это может быть очень хорошая ставка. Apple хочет продвигать свой домашний язык, поддержка Web Assembly может стать для них вариантом работы и хорошей возможностью привлечь веб-разработчиков в свою экосистему.

Я слышал, что Promises и async / await были во многом вдохновлены реализацией C #, поэтому я думаю, что разработка Async на C # должна быть достаточно оптимизирована с помощью, вероятно, хорошей коллекции библиотек, ориентированных на Async. Это также один из ближайших языков к C / C ++ и, как один из основных компонентов платформы .NET, вероятно, именно то, что Microsoft будет продвигать. Он также был стандартизирован в ECMA (как ECMA-334), но, к сожалению, последние публикации всегда устарели по сравнению с последними версиями. Для этого языка реализация все еще предшествует стандартизации ;-)

Четвертым основным действующим лицом в браузере является Google (я не говорю о конкуренции за использование браузеров). Было бы справедливо сказать, что даже если Dart может быть более близок к JS, у меня также будет взгляните на его язык Go, который он может продвигать как провайдер веб-сборки. Это может быть более легкая альтернатива для новичков, что было одной из целей JavaScript.

Тем не менее, мы должны учитывать одну вещь. С давних пор можно писать веб-серверы в нативном коде, но разве большинство из них не написано на интерпретируемых языках, таких как PHP, python, ruby, perl, а в настоящее время все больше и больше на JavaScript?

Так что меня не очень волнует будущее JavaScript в веб-разработке. Веб-сборка в основном будет означать:

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