Еще лет 10 назад никто и не предполагал, что JavaScript станет таким популярным. На его пути к мировому господству стояли Java, Flash и другие мощные соперники. Они сильно опережали JS благодаря функциям вроде добавления видео (это было гораздо раньше, чем появились элементы <video>, <canvas> и CSS-анимации). Но данное преимущество со временем превратилось в причину их падения: после зарождения HTML пятой версии - платформы быстро устарели.
Возможно, в ближайшем будущем сильные стороны JavaScript тоже сыграют с ним злую шутку и превратятся в тянущий на дно балласт. С этой точки зрения особое внимание нужно уделить технологии . Но сначала давайте поговорим о сложившейся на текущий момент ситуации, и только потом попробуем заглянуть вперед.
Сегодняшний подход: транспайлинг
JavaScript-разработчики всегда находились в поиске альтернативных решений. Так, были попытки вытаскивать из браузеров код с помощью плагинов (они завершились неудачей). Затем пытались сделать конвертер кода – инструмент, позволяющий преобразовывать написанный на другом языке код в JS.
Процедура «переписывания» программы с одного языка на другой получила название транспайлинг. И она имеет несколько очевидных недостатков.
Синтаксис и функции языков программирования высокого уровня отличаются. Поэтому построить эквивалентные конструкции часто просто невозможно. Но даже если вам удастся их найти, опасностей избежать точно не получится.
Например, что случится, если прекратят разработку транспайлера? Или он станет причиной появления багов? Или понадобится подключить JS-фреймворк? Да и как может работать команда, когда все используют разные языки?
Сегодня транспайлеры пользуются достаточной популярностью, но их применяют только с одной целью: обеспечить обратную совместимость. Написав самый новый JavaScript, разработчики потом с помощью транспайлеров, наподобие Babel, преобразуют код в не такую красивую старую версию JS, которая будет работать везде. Либо же они пишут на TypeScript (усовершенствованный вариант JavaScript), после чего превращают строки в JS-код. Как видно, при любом раскладе мы все еще не выходим за рамки JavaScript.
Технология завтрашнего дня:
Впервые новые возможности замаячили на горизонте в 2013 году благодаря Asm JS – экспериментальному проекту от создателей Mozilla. Они пытались найти способ, как запустить код высокой производительности внутри браузера. И если плагины пытались следовать за браузером, asm прокладывал путь прямиком через JVM.
Asm js представляет собой оптимизированный лаконичный синтаксис языка JavaScript. Он более шустрый, потому что пропускает медленные динамические элементы. Плюс веб-браузеры, распознавая это, применяют дополнительные оптимизации, чем сильно увеличивают производительность.
Проще говоря, asm js соблюдает основной закон – не ломать Web – показывая направление к дальнейшему развитию.
Разработчики Firefox, объединив ресурсы asm js с транспайлером Emscripten, стали помещать в браузер, который работает лишь на JavaScript, 3D-игры в реальном времени, написанные на C++.
Проходя по проводам, формат wasm превращается в нули и единицы. Он предназначен для компилятора. WebAssembly не обязательно писать вручную (но такая возможность есть, если вам хочется ).
WebAssembly был создан в 2015 году. Сейчас его поддерживают 4 крупных браузера (Chrome, Mozilla Firefox, Edge и Safari) как на стационарных, так и на мобильных устройствах. Что касается Internet Explorer, тут поддержки нет, но можно обеспечить обратную совместимость, преобразовав wasm-код в asm js (при этом страдает производительность).
Потенциал WebAssembly
Инструмент WebAssembly дает разработчикам способ писать оптимизированные процедуры, в основном на C++. Такая способность очень мощная, но узконаправленная. Ее используют только для того, чтобы повысить эффективность сложных вычислений. К примеру, fastq bio с помощью wasm ускорял процесс чтения ДНК. Ее применяют и при портировании игр высокой производительности, а также для создания внутрибраузерных эмуляторов.
Но это ещё не всё, иначе у Wasm не было бы ни единого шанса соперничать с JavaScript. В дополнение к вышеописанным сферам использования, WebAssembly открывает программистам возможность помещать платформы в среду разработки JavaScript. Тут-то и начинается все самое интересное.
WebAssembly заключен в рантайм JS, он просто не может его обойти. Wasm не имеет прямого доступа к веб-страницам, поэтому параллельно с ним должно находиться хотя бы минимальное количество кода на JavaScript. Т.е. он не способен манипулировать объектной моделью документа и получать события без прохождения через слой JS. Вы наверняка подумали, что это существенное ограничение. Но разработчики уже придумали, как сделать перенаправление среды выполнения сквозь WebAssembly.
К примеру, майкрософтский фреймворк Blazor использует среду .NET, которая загружается как скомпилированный Wasm-файл. Она работает с JS и предоставляет сборку мусора вместе с другими базовыми сервисами, а также функции высшего порядка. Простыми словами, Blazor применяет виртуальную машину, находящуюся внутри второй виртуальной машины. И это только один пример: кроме Blazor есть и другие эксперименты на базе WebAssembly. Взять хотя бы , размещающий в браузере язык Python, дополненный расширенным списком математических инструментов для работы с данными.
Что это, если не уверенный шаг в продвинутые технологии будущего? Первоначально WebAssembly разрабатывался для с Rust, а сейчас его используют и в более амбициозных проектах. Совсем скоро не JavaScript-фреймворки смогут составить конкуренцию JS-резервам вроде , и .
Wasm развивается стремительными темпами. Его текущее состояние – это лишь минимальный порог, которого хватает для применения только в нескольких важных сценариях. Но после утверждения WebAssembly ситуация измениться к лучшему.
Если Blazor и ему подобные платформы станут широко востребованными, WebAssembly, скорее всего, получит прямой доступ к DOM. А реализацию таких деталей как многопоточность и сборщик мусора браузеры возьмут на себя (по крайней мере, такие планы сейчас вынашивают их создатели).
Думаете, что такой эволюционный путь слишком долгий? Тогда вспомните, как созревал JavaScript. Обретя популярность, WebAssembly обязательно сделает большой вклад в ряд улучшений и получит возможность легко затмить нативные преимущества JS.
Часто можно услышать мнение, что в WebAssembly не закладывали цель стать заменой JavaScript. Но согласитесь: так говорили обо всех революционных платформах. Тот же JS разрабатывался вовсе не для того, чтобы сменить Java в браузере, и миссия веб-приложений состояла не в том, чтобы прийти на смену настольным приложениям. Но когда появилась такая возможность, каждый из них сделал это.