Релиз Wasmer 1.0

WebAssembly в браузере - понятно. Зачем WASM еще где-то? И это, еще не понравилась кнопка «Conact Sales»

JVM здорового человека.

У них конкуренты есть - https://wasmtime.dev/ и https://github.com/bytecodealliance/lucet.

Вообще желаю развития этим рантаймам и самому стандарту WASI

Есть несколько сценариев применения.

1. Не компилять высокопроизводительные NodeJS модули каждый раз с голого C/C++/Rust, требуя установки компилятора. WASM/WASI рантайм уже встроен в ноду и превращает WebAssembly в натив на множестве архитектур моментально.

2. Те же модули и изоляция. WASI runtime - это кросплатформенная прослойка доступа к ОС в духе Posix, но по «все что не разрешено - запрещено». Каждый ресурс нужно разрешать из-за пределов контейнера. Наверное можно что-то такое соорудить через AppArmor/SELinux, но это встроено прямо в WebAssembly.

3. Serverless в edge computing. В отличие от датацентров, edges много сотен. Твое приложение устанавливается в каждый, почти в каждом большом городе в мире и там спит. Запуск WebAssembly рантайма полностью безопасно для edge провайдера и очень быстро. Его можно успеть запустить прямо во время первого запроса к нему и пользователь этого даже не заметит, в отличие от докера. Но потом latency будет огонь. Так уже делают Fastly и Cloudflare.

JVM

Это хорошо или плохо?

здорового человека.

для среднестатистического человека, который может быть одновременно здоровым курильщиком

Это хорошо или плохо?

Так точно!

Это хорошо или плохо?

Ну в JVM было две проблемы - обязательный сборщик мусора и слишком долгий и тяжелый JIT, и недостижимый AOT. Это подробно описано в дизайн-доках WebAssembly. Там вообще страниц наверное 10 только JVM обсуждают.

Ок, допустим мы не будем использовать сборщик и просто создадим ByteBuffer и будем С++ транслировать в JVM инструкции по работе с ним. Я не очень знаю насколько это будет хорошо или плохо.

Но вторая проблема - это серьезно и потому JVM в браузере не взлетел. Там даже верификация байткода была какой-то квадратической сложности по стандарту, если не какой-то еще более безумной сложности. Насчет AOT все сказано в GraalVM. Там hello world превращается в натив 1 минуту. Если взять и втянуть зависимостей обычных для Java мира, то скорее всего ты не дождешься превращения в натив. Представь получить такой модуль в SPA приложении в браузере. Да что представлять, все помним spinner в апплетах.

WebAssembly в браузере проводит полный оптимизированый AOT быстрее чем закачивается wasm файл. Это было заложено в дизайн и таким образом и подбирался набор инструкций

Случайно запостил, но твое несравненное остроумие не позволяет мне теперь удалить или редактировать пост

Надеюсь, редактор ушел отдохнуть.

То есть разница в том, что выкинули лишнее (для веба?) из jvm и привязали к JS окружению (c DOM). И чем это лучше человекочитаемого JS, кроме предварительной (недо)компиляции в промежуточное представление, обфускации, при сравнимой скорости работы с jit JS?

Но вторая проблема - это серьезно и потому JVM в браузере не взлетел. Там даже верификация байткода была какой-то квадратической сложности по стандарту, если не какой-то еще более безумной сложности.

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

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

Про wasm мало что знаю, там есть аналог SecurityManager и permissions. Например, для апплетов можно было запретить самостоятельную работу с сетью, доступ к файловой системе, убрать доступ к env-переменным (т. е. можно было сделать, что апплет даже не мог определить, в какой ОС и браузере запускается). Подобное можно сделать в wasm?

Насколько слышал, в wasm нет доступа к DOM-дереву. Т. е. по факту переизобрели java applet-ы.

Ну это плафторма чтобы брать языки без GC, с явным аллокатором, предсказуемым потреблением памяти и пихать их в веб. Тебе нужно умножить миллион матриц, тебе JS с JIT как-то не лучший вариант. Ну еще WebCL конкретно для этого случая, но не все примеры такие идеализированые чтобы ускорять их на GPU

Подобное можно сделать в wasm?

В wasm который в браузере вообще нету API общения с системой. Никаких. Только с твоим JS приложением.

Он просто экспортирует функции и в свою очередь принимает указатели на твои функции из JS. Получается sandbox JavaScript переиспользуется, со всеми преимуществами и недостатками.

А, и да, апплеты использовали в том числе из-за криптографии, в sun/oracle jre встроенная криптография сертифицировалась, поэтому её использовали банки, гос. структуры, военные и пр. В wasm есть поддержка криптографии?

В wasm есть поддержка криптографии?

Смотри выше. Я думаю что нужно использовать и сертифицировать API браузера. Или в свою очередь просто кросскомпилировать какой-то Ring или OpenSSL в wasm.

В wasm который в браузере вообще нету API общения с системой. Никаких. Только с твоим JS приложением.

Значит, это не замена апплетам. Тот же КриптоПро раньше работал через апплеты, т. к. надо было достать сертификат локального пользователя, потом был эпичная драма с переездом на native-extension, которые работали только в хроме. И всякая подпись файлов, печать, локальный кэш уже не реализуем через wasm.

Ясно. Т.е. на текущий момент wasm - жалкий огрызок от апплетов.

Это ещё больший геморой, чем был с апплетами. Я видел много внутренних систем, которые ставились в крупных компаниях для автоматизации документооборота и производства, и в 2000-2015-х годах была тенденция ухода от толстых клиентов к тонким в виде браузера. А сейчас получается опять возвращаются к толстым клиентам.

Значит, это не замена апплетам

https://en.wikipedia.org/wiki/Java_applet

Java applets were deprecated since Java 9 in 2017 and removed from Java SE 11 (18.9), released in September 2018

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

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

Значит, это не замена апплетам.

Идея апплетов – давайте запихнём в веб как можно больше фич.

Идея wasm – давайте запихнём в веб 3д-игрушки без тормозов.

Идея wasm – давайте запихнём в веб 3д-игрушки без тормозов.

Ну и «хватит насиловать JS, компилируя в него всякое говно, это НЕ набор низкоуровневых инструкций, не нормальный target компилятора. Божемой да как это вообще все работает до сих пор!? Если вы компилируете все в JS, то почему вы едите ложкой, а не ножкой от стула, а?»

JVM здорового человека.

довести бы его до ума и оптимизировать и тогда можно весь репозиторий дебиана на васм скомпилировать и работать будет на всех ос и на всех архитектурах процессоров и с не сильным падением производительности. Мечта! а с играми насколько проще было бы если бы они все были на опенжл или вулкане и скомпилированны на васм? везде бы работали и всегда!

Насколько слышал, в wasm нет доступа к DOM-дереву. Т. е. по факту переизобрели java applet-ы.

JS - это asm для веба. Wasm - это машиночитаемый js. Все это (включая человекочитаемый js) работает в одном болоте - js окружении (вроде, если по стандарту). Так что, дальше браузера не вылезешь (или что там вместо браузера).

с явным аллокатором

Ога, а потом эта хрень будет сегфолтится через раз, уж лучше пусть жрет память с GC. Не умеет народ в правильное управление памятью.

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

Во-первых, Rust - nuff said. В WebAssembly сейчас прямо язык, поддержка которого первична, а уже не С++. Это вообще похоже уже одна тусовка разработчиков.

Во-вторых С++ вырос над собой с новыми стандартами и практиками. Сегфолт словить все еще можно, но практически уже намного меньше, линтеры ловят большинство ошибок. Что-то не ловят, но ШТОШ

финансового софта в банановых государствах.

Swift (https://www.swift.com/our-solutions/interfaces-and-integration/swift-certificate-centre/how-use-and-manage-personal-tokens), австрийский банк Sparkasse, USAA (штаб расположен в штате Техас) раньше использовали апплеты. Т. е. США и Австрия - банановые государства. Ну ok, твои же слова.

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

Ну так, в банановых государствах (Австрия и США) апплеты использовали финансовые организации и не только, это ладно.

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

использовали

некий функционал

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

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

Еще раз…

ШТОШ ))

Если серьезно, то почему-бы не стрелять. Все-таки компилятор должен помогать. Ровно до того момента когда ты решил что он не помогает. Решение за человеком и его задачей. И риски тоже

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

Мы уже выяснили, что США и Австрия - банановые государства, чьи служащие не понимают в безопасности в отличии от.

ужаснейшую технологию вроде апплетов в светлое будущее.

Да пусть хоть трижды ужаснейшую, что на замену-то использовать? Костыли и подпорки? И это светлое будущее?

Мы уже выяснили, что США и Австрия - банановые государства, чьи служащие не понимают в безопасности в отличии от.

https://ru.wikipedia.org/wiki/%D0%90%D0%BF%D0%B5%D0%BB%D0%BB%D1%8F%D1%86%D0%B8%D1%8F_%D0%BA_%D0%B0%D0%B2%D1%82%D0%BE%D1%80%D0%B8%D1%82%D0%B5%D1%82%D1%83

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

Я не против доверять США или Австрии, но все же, чем так ценна Java? Это же не первый раз когда бюрократы просто боятся современных технологий и заставляют всех сидеть в легаси.

Да пусть хоть трижды ужаснейшую, что на замену-то использовать?

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

Слушай, спасибо за объяснения, но не понятно, почему есть вообще противостояние wasm vs апплеты, если настоящее противостояние апплеты vs добавление фич в стандарт js.

Почему js такой плохой target? По-моему замечательный. Прежде всего человекочитаемостью и какой-никакой прозрачностью, в отличие от непрозрачных блобов, которые ты будешь скачивать в свою песочницу браузера. Wasm хорош тем, что потенциально может убить блокировщики рекламы?

США и Австрия - банановые государства, чьи служащие не понимают в безопасности

Ну если смотреть на организацию выборов в США… ну ты понял.

Прежде всего человекочитаемостью и какой-никакой прозрачностью,

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

Размер js меньше, чем у какого-нибудь Rust/C++ скомпилированного в wasm, не говоря уже про С#/Go

Мне казалось, ИБ банка определяется квалификацией специалистов и используемыми технологиями, а не страной.

Только потому, что жс будет компилироваться на клиенте. Васм, кроме того, куда лучше сжимается.

противостояние апплеты vs добавление фич в стандарт js

Я тоже вот не понял. Это и пытаюсь обьяснить, но как-то тяжело выдавить из собеседника конкретные фичи апплетов, которые нельзя достать нигде и никак.

Я думаю нужно говорить о конкретном приложении и его зависимостях. Всегда есть возможность уменьшать.

Если wasm только для вычислений, то он хорош, мало весит: https://allen-garvey.github.io/wasm-dither-example/

Когда пишут всё, то выходит не очень:

https://jetli.github.io/rust-yew-realworld-example-app/

https://elm-spa-example.netlify.app/

Rust wasm почти в 10 раз больше, приложение одинаковое: 28кб vs 257кб…

Вангую зато, что wasm парсится в разы быстрее.

JS - это asm для веба. Wasm - это машиночитаемый js

Нет. JS предоставляет высокоуровневый набор команд и готовых структур данных и возможность пользоваться всем API браузера. WASM — низкоуровневая виртуальная машина (с машкодами уровня микропроцессора), в которой можно только байтики тасовать, ничего больше. API браузера напрямую вызвать нельзя, только явно передавать специально написанные функции из JS в WASM. Даже JS-строки нужно преобразовывать в типизированные массивы чисел и обратно.

А ты хитрый, взял Elm.

Elm это вообще state of art для веба, а Yew считай вчера написали. Возьми Angular/React/Vue, обмажь Redux или еще каким-то калом

Вангую зато, что wasm парсится в разы быстрее.

Конечно, считай тупо машинный код:

;; 1 + 2

i32.const 1
i32.const 2
i32.add

высокоуровневый

человекочитаемый

низкоуровневая

машиночитаемый

А можешь оспорить или подтвердить тезис о том, что с wasm-only будет сложнее блокировать рекламу?

Интересная и пожалуй хорошая технология.

Такой поступью они все скриптовые языки вытеснят.

Владимир

человекочитаемый

Оптимизированный и особенно обфусцированный JS вообще не человекочитаем.

машиночитаемый

Бывают виртуальные машины с высокоуровневым машиночитаемым набором инструкций — как JVM и .NET, которые классами и объектами умеют оперировать.