Признаки перемен
Несмотря на то, что многие из нас согласились бы называть усталость от Javascript настоящей болезнью, веб-платформа, похоже, является единственной средой, которая действительно успешно справляется с проблемами совмещения сложности, гибкости и стабильности при проектировании системы. в мировом масштабе. На данный момент менеджер пакетов узлов (npm) предлагает сообществу разработчиков 650 000 строительных блоков многократно используемого кода javascript. Эти блоки бывают разных размеров и форм в виде небольших функций, библиотек или полноценных фреймворков. И хотя эта цифровая экосистема сопряжена со своими проблемами, разработчики привыкают работать с такой податливой и очень богатой субстанцией. Но что, если эта шкала - лишь верхушка айсберга…
Я всегда с нетерпением жду будущего, которое каждый новый стандарт веб-платформы предлагает разработчикам, но я считаю, что целостный анализ WebComponents и WebAssembly, в частности, может пролить свет на об общей тенденции, которая в ближайшем будущем изменит Интернет. Цель этой статьи - поразмышлять об этом будущем и представить, как изменится жизнь веб-разработчика, когда обещание этих двух технологий будет выполнено.
Короче говоря, оба эти стандарта достаточно революционны, чтобы каждый заслужил достойную книгу. Веб-компоненты без фреймворка могут изменить и упростить дизайн приложений точно так же, как пакеты npm помогли многим разработчикам решать повседневные проблемы, которые варьируются от обычных преобразований дат до сложных вычислений машинного обучения. Безъязыковая WebAssembly в качестве целевого объекта компиляции предлагает новые уровни выражения и скорости, никогда ранее не встречавшиеся в браузере или, если уж на то пошло, в любом другом веб-стеке. Несмотря на то, что в настоящее время эти идеи свежи и все еще не приняты, они обе будут способствовать развитию друг друга.
Важность WebComponent
Около 4 лет назад многочисленные фреймворки Javascript, такие как Angular и React, решили использовать компоненты в качестве основных единиц при структурировании кода пользовательского интерфейса. Этот шаблон помог рассуждать о все более сложных одностраничных приложениях. Примерно в то же время W3C начал работу над новым стандартом под названием WebComponents. С появлением в 2017 году таких библиотек, как Polymer и Stencil, мы начали осознавать реальную мощь этой технологии. Внезапно разработчики смогли потратить свое время на независимый от фреймворка способ создания многоразовых частей пользовательского интерфейса для своих приложений. Независимо от того, что вы используете сейчас, будь то Angular, React или Vue - каждый может адаптировать эту модель. Шаг за шагом он устраняет трение на многих уровнях существующих проектов. Такие компании, как Ionic, уже смогли заработать, создав библиотеки высококачественных элементов для веб-сайтов, которые напоминают встроенные элементы управления iOS и Android. Их историю вы можете найти в следующем видео:
В настоящее время WebComponents.org предлагает около 1000 различных строительных блоков пользовательского интерфейса, которые можно интегрировать и повторно использовать в проектах по всему миру. Это число предназначено для роста и расширения в многочисленные высококачественные элементы управления, элементы пользовательского интерфейса или полноценные приложения, которые могут легко взаимодействовать с приложениями хостинга. HTML и CSS, являющиеся языковым языком для UX-дизайна в изолированных веб-компонентах, сделают веб-платформу и приложения еще более конкурентоспособными по сравнению с собственными решениями ОС. Но хотя шаблон WebComponent является хорошим ответом на архитектурные проблемы, с которыми мы столкнулись в наших проектах, веб-платформа до сих пор не имела ответов на фундаментальные проблемы производительности по сравнению с собственными приложениями. Именно здесь WebAssembly выходит вперед, чтобы проложить путь… Большой путь… Действительно большой…
Wasm
Если завтра вы будете выполнять код в окне инструментов разработчика, не паникуйте, когда вам будет представлен код, который выглядит следующим образом:
(module
(func (param $lhs i32) (param $rhs i32) (result i32)
get_local $lhs
get_local $rhs
i32.add))Вероятно, вы попали в библиотеку, которая решила оптимизировать свой код, чтобы он работал быстрее и был меньше по размеру. Эта библиотека была скомпилирована в WebAssembly (для краткости wasm) и передана в ваш браузер так же, как и обычный статический файл javascript. Несмотря на то, что wasm компилируется в двоичный формат, с помощью инструментов преобразования мы все равно можем сделать его доступным для чтения людям. Если приведенный выше код кажется вам совершенно незнакомым - посетите этот веб-сайт MDN для получения дополнительной информации Общие сведения о текстовом формате Webassembly. Также проверьте этот g репозиторий ithub WebAssembly, чтобы узнать больше о двоичных кодировках wasm. Если этого недостаточно, посмотрите это видео от Jay Phelps:
До сих пор Javascript был единственным ребенком в затруднительном положении, когда дело касалось выбора языка в браузере. Другие языки, такие как Java, пытались, но не смогли войти в картинку при работе в отдельной виртуальной машине. И хотя Javascript - отличный, выразительный и очень динамичный язык, у него есть недостатки, когда речь идет о производительности, статических типах и размере. Webassembly.org предлагает Wasm следующее определение:
WebAssembly (сокращенно Wasm) - это двоичный формат инструкций для виртуальной машины на основе стека. Wasm разработан как переносимая цель для компиляции языков высокого уровня, таких как C / C ++ / Rust, что позволяет развертывать в Интернете клиентские и серверные приложения.
Это означает, что такие языки, как C #, TurboScript, Elm и многие другие, будут предлагать wasm в качестве цели компиляции. Это хорошая статья от Скотта Хансельмана под названием .NET и WebAssembly - это будущее веб-интерфейса, в которой он заявляет, что WebAssembly никуда не денется. Хотя .NET определенно не единственное будущее для внешнего интерфейса, это хороший кандидат для людей, которые предпочли бы писать приложения с полным стеком на C #, VB или даже F # ...
«Вавилонская башня» рушится
Нравится вам это или нет, этот новый стандарт вызовет взрывной рост языков, которые будут использоваться в сети. Это не означает, что Javascript устареет, это означает лишь то, что в ближайшем будущем у нас будет гораздо больше возможностей для выбора. Разработчики, которые работают над библиотеками и фреймворками общего назначения, выиграют, потому что они смогут упаковать больше функций в пакет того же размера. И пользователи таких модулей выиграют, потому что их инфраструктура станет легкой и, надеюсь, оптимизированной для работы намного быстрее.
Потребность в новых языках существовала некоторое время в мире браузеров. За последние три года мы наблюдали взрывной рост надмножеств Javascript, таких как Typescript, Reason M L или Elm. Все эти языки обещают улучшить масштабируемость, удобство для разработчиков и стабильность кода Javascript. Не стоит удивляться тому, что WebAssembly был положительно воспринят как интерфейсным, так и серверным сообществами, чтобы вывести эти цели на еще более высокий уровень.
Но где же революция?
Хотя это действительно захватывающе, свобода говорить на любом языке в Интернете на самом деле не делает WebAssembly убойной функцией платформы. Выполнение кода на скорости, близкой к исходной, изменит внешний вид наших веб-сайтов. Впервые в истории браузеры смогут составить конкуренцию нативным ОС по производительности. WebAssembly реализует согласованную модель многопоточности. И если вы думаете, что веб-воркеры стали улучшением, подождите, пока не испачкаете руки клиентом, работающим на процессорах потоковой передачи, или о любом другом будущем чуде человечества.
После снятия фундаментальных ограничений производительности клиента окно Pandoras открывается - игры, трассировки лучей и физические движки, приложения 3D CAD, серьезные библиотеки моделирования наконец-то смогут войти в пространство браузера. Это также имеет реальный потенциал возродить VR и AR в Интернете. Вот ссылка на Epic Zen Garden Demo, которую вы можете использовать для вдохновения. Не забывайте, что это настоящий игровой интерактивный опыт, а не просмотр предварительно отрендеренного фильма. Ознакомьтесь с этой статьей Люка Вагнера IEEE Spectrum для получения более подробной информации о высокопроизводительных приложениях, которые будут доступны с помощью wasm. Если этого недостаточно - обещано, что это повлияет на мир Интернета вещей аналогичным, если не более серьезным образом. Узел 8 LTS с его двигателем V8 и ChakraCore от Microsoft также уже поддерживают wasm. Для получения дополнительной информации посмотрите это видео от Ben Smith:
Конечно, все еще остаются проблемы, и в WebAssembly отсутствует множество практических вещей, таких как сборка мусора или обработка исключений. Вы можете найти список возможностей публикации MVP здесь. Также, если вам интересно, вы можете проверить это сообщение в блоге, чтобы получить хорошее краткое изложение этой технологии из The New Stack. Есть также люди, обеспокоенные последствиями проприетарного двоичного кода, работающего через WebAssembly, что затруднит чтение кода других людей. Но тот факт, что версия 1.0 уже выпущена и все основные поставщики браузеров согласились с этой спецификацией, указывает на то, что сейчас нет пути назад от всех развлечений, которые мы получим в ближайшие годы.
Куда все это нас денет…
Итак, как веб-компоненты связаны с WebAssembly и как они будут способствовать дальнейшему внедрению? Что ж, оба эти стандарта предлагают уровень модульной абстракции для стеков внешнего интерфейса. Представьте себе объединение веб-компонентов, которые визуализируют контент САПР на WebGL в виртуальной реальности, с веб-компонентами, оптимизированными для многопоточного моделирования в wasm, с веб-компонентами, которые предназначены для создания уникальных элементов управления пользовательского интерфейса с помощью веб-компонентов ... с веб-компонентами ... по кругу.
Эта модульная система из быстро связанных между собой веб-компонентов, на которых выполняется код wasm, - вот что будет определять будущее веб-разработки в ближайшем будущем. Управление информационным потоком между этими компонентами по-прежнему будет проблемой, но с такими библиотеками, как Redux и Apollo GraphQL, мы находимся на правильном пути к поиску решения для этого. Добавьте к этому возможность писать код внешнего интерфейса со статически типизированными языками, и веб-платформа внезапно будет работать на стероидах. 650 000 пакетов npm в этом контексте кажутся действительно очень скромным началом.
В общем, одни только эти новые стандарты, вероятно, могут превратить усталость от javascript в более общую веб-тупость, но это хорошо. Чем быстрее мы справимся с этим, тем раньше мы ощутим новые возможности, открываемые этими стандартами. Тем временем webpack теперь поддерживает WebAssembly с помощью wasm-loader, и с помощью всего лишь нескольких правильных полифиллов мы можем заставить веб-компоненты работать на наших веб-сайтах. Так что давайте наслаждаться и вводить новшества в будущее.
