Что случилось с «убийцей Javascript» WebAssembly? Она уже мертва?

Глядя на текущую ситуацию на рынке технологий, шумиха вокруг Web3.0, Metaverse, Blockchain, AI, ML и т.д. напоминает нам о том, как быстро меняется рынок технологий. Он настолько быстро развивается, что технологии, которые сегодня мы считали будущим отрасли, послезавтра могут полностью исчезнуть из нее.

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

Мы вспомним об одной из таких разрекламированных технологий «Web Assembly», ответив на вопросы «Что», «Почему» и «Когда»:

Что такое WebAssembly?

Почему мы называем ее загипсованной?

Когда она умрет?

Содержание
  1. Что?
  2. WebAssembly (сокращенно Wasm) — это формат двоичных инструкций для виртуальной машины на основе стека. Wasm разработан как переносимая цель компиляции для языков программирования, позволяющая развертывать в Интернете клиентские и серверные приложения.
  3. Теперь, он никогда не предназначался для того, чтобы вытеснить javascript, но работать рядом с ним, преодолевая его проблемы и увеличивая его преимущества.
  4. Почему?
  5. И обычно WASM был на 30-60% быстрее, чем JS, в зависимости от браузера и устройства.
  6. Но одной из самых заметных неудач WASM было обещание улучшить безопасность по сравнению с JS.
  7. Мы, разработчики и представители технологического сообщества, понимаем, что новая технология не может быть совершенной с первого раза. Требуется много итераций, чтобы обрести форму и начать приносить пользу. Поэтому мы очень хотим, чтобы WASM постепенно улучшался и начал приносить результаты в течение нескольких итераций.
  8. Когда?

Что?

Во-первых, давайте разберемся, что такое WebAssembly или сокращенно WASM? Почему все думали, что она станет «убийцей Javascript»?

Итак, что такое WebAssembly? Если мы воспользуемся определением с официального сайта, то оно гласит:

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

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

Как указано в определении, WASM был разработан как цель компиляции для других языков, позволяя компилировать в него код на стороне сервера (например, код на C или C++) и выполнять его в браузере.

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

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

Теперь, он никогда не предназначался для того, чтобы вытеснить javascript, но работать рядом с ним, преодолевая его проблемы и увеличивая его преимущества.

Однако, как я уже говорил, он был разрекламирован широкой аудитории как замена javascript, что совершенно неверно. Люди по всему миру начали сравнивать его с javascript, как будто WASM был конкурентом JS, но на самом деле WASM — это компаньон JS, и именно поэтому появился тег «убийца Javascript».

Причина, по которой люди начали сравнивать WASM с JS, заключается в том, что WASM обещал решить несколько проблем, которые есть у JS, например, проблемы безопасности, кросс-платформенную поддержку, повышенную скорость, улучшенную отладку и сборку мусора.

Но выполнил ли он это обещание? Давайте выясним это в следующем разделе.

Почему?

Итак, почему мы назвали WASM гибридом? Потому ли, что она не выполнила своих обещаний? Ну, частично, ДА!!!

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

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

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

И обычно WASM был на 30-60% быстрее, чем JS, в зависимости от браузера и устройства.

Так что же пошло не так, спросите вы?

Несмотря на то, что WASM превосходил результаты эталонных тестов, пользователи и разработчики обнаружили, что реальная производительность не соответствует эталонным показателям. Она действительно превышает производительность JS, но не настолько, как предполагалось в эталонных тестах. Что, в общем-то, разочаровало многих людей.

Но одной из самых заметных неудач WASM было обещание улучшить безопасность по сравнению с JS.

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

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

Вот почему говорят, что он частично не выполнил свои обещания.

Но это еще не все.

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

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

Хотя он был выпущен с шумом в 2017 году, и позже многие продукты, такие как Blazor, сделали заголовки с WASM, многие люди не знают, на что способен WASM, или никогда не брали его в руки, чтобы понять, чем он отличается от других front-end/client-side фреймворков. Прошло слишком много времени, чтобы получить заслуженное внимание и широкую адаптацию в реальных приложениях.

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

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

Когда?

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

Так сможет ли он продолжать в том же духе и выжить, или же он умрет, и когда он умрет?

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

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

До тех пор, счастливого обучения!!!

Оцените статью
Procodings.ru
Добавить комментарий