Разработчики Mozilla представили (https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webas... проект WASI (https://wasi.dev/) (WebAssembly System Interface), в рамках которого ведётся работа по определению программных интерфейсов, которые можно использовать для организации взаимодействия с операционной системой приложений, поставляемых в формате WebAssembly (http://webassembly.org/). Целью проекта является предоставление API, расширяющего область использования WebAssembly и позволяющего создавать на базе данной технологии обычные программы, выполняемые вне браузера.
WASI даёт возможность (https://github.com/CraneStation/wasmtime/blob/master/docs/WA... из окружения для выполнения WebAssembly получить доступ к предоставляемым операционной системой функциям, таким как файлы и файловая системой, сетевые сокеты, таймеры и генераторы случайных чисел. API WASI изначально развивается как не привязанный к бразуерам и независящий от Web API и JavaScript, но при этом предоставляющий должный уровень изоляции от основной системы (приложения запускаются в sandbox) и позволяющий явно определять предоставляемые приложению полномочия в стиле CloudABI (https://cloudabi.org/) и Capsicum (https://www.opennet.me/opennews/art.shtml?num=40110)).
Применённая в WASI модель безопасности через управление возможностями (https://en.wikipedia.org/wiki/Capability-based_security), в рамках которой программа может выполнять только заведомо разрешённые действия. По аналогии с тем, как WebAssembly ограничивает доступ на уровне импорта функций, в WASI осуществляется контроль доступа к системным возможностям. Файлы, каталоги, сокеты и другие ресурсы ассоциируются с специальным типом файловых дескрипторов (capability), для выполнения действия с каждым из которых приложению должны быть даны полномочия. Полномочия обрабатываются иерархически, т.е. предоставив доступ к каталогу, автоматически открывается и доступ ко всем файлам в нём.В настоящее время уже доступны для тестирования прототипы следующих компонентов:
- wasmtime (https://github.com/CraneStation/wasmtime/) - runtime для выполнения WebAssembly-приложений с поддержкой WASI как обычных обособленных приложений. Поддерживается как запуска байткода WebAssembly при помощи специальной утилиты командной строки, так и компоновка готовых исполняемых файлов (wasmtime встраивается в приложение как библиотека). Для достижения должного уровня производительности применяетяс JIT-компилятор на базе генератора кода cranelift (https://github.com/CraneStation/cranelift).
- WASI SDK (https://github.com/CraneStation/wasi-sdk) - инструментарий для компиляции приложений C/C++ в формат WebAssembly, использующий Clang 8.0 (https://www.opennet.me/opennews/art.shtml?num=50360);
- Сборочная цель (https://github.com/alexcrichton/rust/tree/wasi) с поддержкой WASI для языка Rust, позволяющая компилировать код Rust в WebAssembly. В начале апреля поддержку WASI планируется интегрировать в основную кодовую базу и начать тестирование в ночных сборках;- wasi-sysroot (https://github.com/CraneStation/wasi-sysroot/) - реализация стандартной библиотеки libc для WASI, основанная на коде musl (http://www.musl-libc.org/);
Проектом также развивается JavaScript-библиотека polyfill (https://github.com/CraneStation/wasmtime-wasi/tree/wasi/lib/... (демонстрация (https://wasi.dev/polyfill/)) с реализацией WASI для выполнения приложений внутри браузера, позволяющая применить к выполняемому в браузере коду модель разграничения доступа на основе "capabilities". Из планов упоминается создание на базе WASI системы модулей для интеграции в приложения изолированных плагинов с дополнительной функциональностью, поставляемой в формате WebAssembly.
Напомним, WebAssembly во многом напоминает Asm.js, но отличается (https://www.opennet.me/opennews/art.shtml?num=46117) тем, что является бинарным форматом, не завязанным на JavaScript и позволяющим выполнять в браузере низкоуровневый промежуточный код, скомпилированный из различных языков программирования. Среди основных задач WebAssembly выделяется обеспечение переносимости, предсказуемость поведения и идентичности выполнения кода на разных платформах. По сравнению с JavaScript использование WebAssembly также позволяет существенно сократить размер приложений, благодаря компактному промежуточному коду, и увеличить скорость декодирования. В WebAssembly не требуется применение сборщика мусора, так как применяется явное управление памятью.
URL: https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webas.../
Новость: https://www.opennet.me/opennews/art.shtml?num=50406
Так-так-так. JVM? CLR? Так-так-так. WebAssembly в массы? Чем их обычная бинарь не устраивает?
А бинарь кроссплатформенный?
Какое мне, как пользователю, удобство с кроссплатформенного бинаря?
Теперь вирусы, чтобы запустить, не придется компилять и устанавливать для них Wine. Очевидный профит же.
То, что это не бинарь, не означает, что он не будет win специфичный апи юзать. Ваш кеп
Меньше денег платить за ПО / больше качественных вещей появится за то же время.легенда: "коммерческое ПО"/"свободное ПО".
> Меньше денег платить за ПОверно!
> больше качественных вещей появится за то же время.
НЕ верно.
кросплатформенные программы как правило УСТУПАЮТ в качестве своим НЕкросплатформенным собратьям.
кросплатформенные:
1. НЕ учитывают ни системные особенности каждой из ОС. (то есть работают отвратительно -- изнутри).
2. НЕ учитывают Human Interface Guidelines принятые для каждой конкретной ОС. (то есть выглядят отвратительно снаружи).// P.S.: а вообще (даже если неважно речь про кросплатформенность или нет) -- выбери из трёх любые два пункта:
// сделать быстро!
// сделать дёшево!
// сделать качественно!
> как правило УСТУПАЮТ в качестве своим НЕкросплатформенным собратьям.Примеры собратьев можно?
> 1. НЕ учитывают системные особенности каждой из ОС. (то есть работают отвратительно -- изнутри).Это хорошо. Чем ниже по стеку софта происходит абстракция от железа и ОС, тем лучше устроена программа, тем меньше глупых ограничений на архитектуру, тем красивше код. Другое дело, что это может приводить к тому, что возможности ОС и железа не раскрываются по полной, из-за чего программа работает медленнее, чем могла бы. Но это, как ты видишь, предмет для компромисса: красивая няшная архитектура, которую возможно поддерживать и развивать, против скорости.
> 2. НЕ учитывают Human Interface Guidelines принятые для каждой конкретной ОС. (то есть выглядят отвратительно снаружи).
Вот уж на что мне плевать, так это на эти гайдлайны. Ещё не хватало жертвовать архитектурой или скростью в пользу всей этой хрени.
Тебе-то может и плевать, особенно если ты пилишь софт для себя. А вот юзеры, которые плотют денюжку
за софт (или тратят время, разглядывая рекламку в "бесплатном"), голосуют за нативное.Это-вот-всё уже есть в Java EE- кросс-платформенность, "универсальный" UI, байт-код, компилирующийся в натив. Оно взлетело, но ниша у него весьма своеобразная - кровавый ынтырпрайз, где юзеры - наемные манагеры (люди подневольные) и софт для управления экзотическими железками. Ну и какое-то количество серверного ПО в том же кровавом ынтырпрайзе. Чтобы "откомпилил-работает-не трожь".
Тебе-то может и плевать, особенно если ты пилишь софт для себя. А вот юзеры, которые плотют денюжку
за софт (или тратят время, разглядывая рекламку в "бесплатном"), голосуют за нативное.Это-вот-всё уже есть в Java EE- кросс-платформенность, "универсальный" UI, байт-код, компилирующийся в натив. Оно взлетело, но ниша у него весьма своеобразная - кровавый ынтырпрайз, где юзеры - наемные манагеры (люди подневольные) и софт для управления экзотическими железками. Ну и какое-то количество серверного ПО в том же кровавом ынтырпрайзе. Чтобы "откомпилил-работает-не трожь".
кроссплатформенность означает только то, что разработчик озаботился наличием возможности собрать и запустить приложение на разных платформах. это с интеграцией не связано ни как. ни что не мешает написать по отдельному модулю на каждую платформу для учета как системных, так и UI особенностей
> ни что не мешает написать по отдельному модулю на каждую платформу для учета как системных, так и UI особенностейв уме теоретика может и не мешает.
на практике это необосноанно усложняет программу (и количества кода) в разы.
в уме теоретика может показаться будто программа это в основном ПРИКЛАДНОЙ код который вызывает некоторые СИСТЕМНЫЕ вещи. и достаточно (якобы) лишь обернуть вызовы к системным вещам в "кросплатформенные" обёртки (или в условную компиляцию).
а на практике оказывается что строчек кода вызыващие системно зависимые вещи -- это 90% от всего кода.
то есть переписывая программу под кросплатформенный вариант -- количество строчек кода увеличится в несколько раз. в лучшем случае. а в худшем (если какая платформа не обладает всеми аналогами сущностей другой платформы) в худшем случае это потянет за собой изменение самой архитектуры в угоду более мошного абстрагирования.
после рефакторинга в угоду более мощного абстрагирования ТЕОРЕТИК наверняка скажет -- "вот видите! переписывание программы под кросплатформенный стиль само-посебе-одно-даже-только-это УЖЕ сделало код более хорошим! мы развязали слои абстракции друг от друга..".
а практик заметит что произошло лишь усложнение и увеличило порог вхождения для новых контрибьютеров. добавление фич -- теперь требует внесения кода в хрЕнову тучу мест
JIT-компилятор будет использовать оптимальные инструкции для твоего проца, а не для самого стаорого из поддерживаемых
в свободном софте это решается компиляцией
которая занимает время и системные ресурсы (речь ведь идет о компиляции на целевой системе?)
JIT тоже "занимает время и системные ресурсы". Только если с AOT один раз собрал бинарник и потом запускай сколько хочешь с минимальным оверхедом, то JIT вынужден при каждом запуске по-новой, "каждый раз как в первый раз", компилировать один и тот же код.
emerge и все дела. Не вручную же сидеть и каждую программу собирать.
>JIT-компиляторМы ведь все знаем что можно легко доставить памяти куда угодно. Падажжи...
У JIT-компилятора обычно на это нет времени.
> Какое мне, как пользователю, удобство с кроссплатформенного бинаря?Для разрабов удобно.
>> Какое мне, как пользователю, удобство с кроссплатформенного бинаря?
> Для разрабов удобно.а какое удобство для пользователя?
// P.S.: или хочешь намекнуть что "ды плевать на пользователя!"?
>>> Какое мне, как пользователю, удобство с кроссплатформенного бинаря?
>> Для разрабов удобно.
> а какое удобство для пользователя?
> // P.S.: или хочешь намекнуть что "ды плевать на пользователя!"?Ну будет у пользователя один бинарник универсальный для всех платформ. Как минимум неудобств из-за этого не будет
Не знаю, какое Вам лично удобство. Но мне как разработчику представляется, что сегодня заниматься некроссплатформенными проектами (особенно вновь создаваемыми) - глупость и пустая трата времени. Хотя не исключаю, что профит от таких проектов иметь можно. С другой стороны, мошенники тоже имеют профит от глупости клиентов. Но мы же их не уважаем?
https://ru.wikipedia.org/wiki/POSIXЗачем тут бинарь?
Насколько я понял, пользователю удобство в том, что этот бинарь точно запустится, а не скажет, что в системе не хватает такой-то версии такой-то библиотеки. Но в основном удобство не для пользователя, а для разработчика, которому не придется создавать и распространять кучу бинарей, и при этом он продолжит писать на своем любимом С/С++.
> Какое мне, как пользователю, удобство с кроссплатформенного бинаря?Не будет утекать в сутки по 500 метров оперативки, как у замечательного бинаря leechcraft. Количество разработчиков ограничено, они не могут осилить всё и сразу. Разработчики leechcraft, например, не осилили. А пользовались бы виртуальной машиной со сборкой мусора - хоть JVM, хоть CLR, хоть электроном - смогли бы написать неглючный софт своими силами.
У этих ребят обычный NIH синдром. Лет 5 теперь будут копировать функционал из Java и .NET
У них немного разные цели. Байт-код Java и .NET несколько более высокоуровневый.
Из LLVM…
Что, например, они оттуда будут копировать, мне очень интересно? Ты можешь привести пример?
И как этот функционал использовать в С/С++, не копируя его?
Теперь можно сделать кроссплатформенный systemd.
Всмысле под любой линукс?
Даже под чайник и кофеварку.
not invented in Mozilla
Никакая бинарь не устраивает. Компиляцию вообще следует рассматривать исключительно как кэширование — она нужна только для производительности, а единственной каноничной и пригодной для распространения формой программы является исходный код.
Васян - отличное название для проекта!
это вместо провалившейся ноды-жс?
Это вообще из другой оперы.
> провалившейся ноды-жсА хипстеры и не знали
Так уже нет хипстеров на годе, нода давно не в тренде.
Не уверен, что мне правда хочется это знать, но всё же спрошу: что сейчас в тренде у HDD-хипстеров?
То-то оно для разработки половины сайтов в сети используется. Сразу видно проволилось.
А васян умеет в многопоток? мне кажется что пока нет
В браузере ты можешь запускать WebAssembly в отдельном Worker thread'е.
И на сцену вновь выходит привязка к JavaScript.
В следующих версиях это один из приоритетов. Так что если сейчас не умеет, то скоро будет.
Не факт. Ребята из эмскриптен уже 6 вариант многопоточности изобретают, и все никак нормально не летит.
А вот это уже годнота. WASI за единую VM с единым WASM. Это хорошо. Учитывая, что это идет от браузеров, то с их толщиной слоя разработчиков может стать стандартом де-факто для клиентских приложений, не требующих заточку производительности под определенную платформу.
Это убийца Electron-а?
Нет, это убийца вашей оперативки и нервов руководителей проектов
Если это сможет вытеснить жс с нодой - то я двумя руками за. Даешь веб/десктоп на своем любимом языке и на любой платформе.p.s. Если бы ЖС не был таким уeбищным... А пока обходимся православным С и богомерзким эмскриптен.
> Если это сможет вытеснить жс с нодойДадада, это примерно как смыть с одежды содержимое кишечника содержимым мочевого пузыря.
Ты просто не умеешь его готовить
> Если бы ЖС не был таким уeбищным...
> ES6 is better than all the other popular dynamic languages (Python, Ruby, Perl and PHP) and has far better implementations. Add on Typescript and it's not even close.
> The only dynamic languages better than ES6 are languages that nobody uses (Smalltalk, Scheme, Common Lisp, Clojure, Erlang etc.).
> wasi-sysroot - основанная на коде musl,А как же чудесная libc на Rust из Redox? На Rust решила забить уже даже Мозила?
>Сборочная цель с поддержкой WASI для языка Rust, позволяющая компилировать код Rust в WebAssembly.Redox компилять в WASI. Redox будет поддерживать море железа.
Это пет-проект какого-то alexcrichton.
...Rust в WebAssembly - это ваш код, а не не интерпретатор/компилятор WebAssembly реализованный на Rust.
Сколько ГБ оперативки надо еще докупать?
(Ёмкость самого большого доступного модуля)*(Число слотов в Вашей МП)
Ваш К.О.
Благодаря вполне демократичным ценам ... Вы правы.
У вас за МКАДОМ эти может и можно назвать демократичными, а у нас в России это по пол зарплаты за планку 8ГБ.
Ну так, если предки отстёгивают бабки, чтобы у сыночка был такой компьютер, который ему нужен для учёбы (как они думают) - почему бы сыночку не считать любую цену демократичной?
35$*2
правда?
Неужели оно не экономичнее Электрона?
само оно жрёт процентов на 20 больше натива, как ни странно. Всё остальное - браузернве фишки вроде DOM. Но идея запускать что-то, чему ты не доверяешь - всё равно дурная
WebAssembly в браузере пока никто и не использует, о каком "вне браузера" вообще может идти речь?
Об элементарном. Хотя бы использование C/C++/D/... в Sandbox окружении для системы дополнений к приложению которые не требуют пересборки. Пример - игровая логика в Quake 3 & QVM, где логика была на C, но в Sandbox, практически с идетичной скоростью работы. Да, есть LLVM, но Web Assembly заметно проще, плюс ещё и возможность использовать тот же модуль использовать в Web при необходимости.
Вообще-то используют. Печально известный Coinhive использовал WASM для того чтобы майнить крипту в браузерах. Зато инновационно.
Наверное, и загрубление точности таймеров в браузерах WebAsm-у не помешает спектрить.
помешает. Таймер - это внешний по отношению к васму сервис, загрубление повлияет ровно так же, как и на джаваскрипт какой-нибудь
Неееет! Остановите их кто-нибудь, хватит с нас нодыжс!
Нода божественна! И она тоже умеет в васм.
Не пользуйся, тебя никто не заставляет.
Казалось бы, что общего между JS интерпретором и виртуальной машиной для выполнения кода на C/C++ с практически одинаковой (близкой и ещё ближе в следующих версиях) скоростью исполнения?
То и другое написано на C++.
> Казалось бы, что общего между JS интерпретором и виртуальной машиной для выполнения
> кода на C/C++ с практически одинаковой (близкой и ещё ближе в следующих версиях) скоростью исполнения?Клятвенные обещания и торжественные заверения (причем, еще со времен JIT для первых Жабо-Не-Скрипт-VM), что "еще немного, совсем чуть-чуть и оно совсем уже скоро почти догонит и многократно перегонит нативный Васюк^W код по скорости исполнения!1!"?
https://arxiv.org/abs/1901.09056
> (Submitted on 25 Jan 2019)
> We then use BROWSIX-WASM to conduct the first large-scale evaluation of the performance of WebAssembly vs. native.
> Across the SPEC CPU suite of benchmarks, we find a substantial performance gap: applications compiled to
> WebAssembly run slower by an average of 50% (Firefox) to 89% (Chrome), with peak slowdowns of 2.6x (Firefox) and 3.14x (Chrome)..
LLVM & QVM (Quake 3 VM, но только Pure C) давно умеют в 10% разницы от силы. У We Assembly есть все шансы стать стандартизипрванным LLVM который также умеет в браузере. С поддержкой нескольких крупных производителей. Что есть не плохо.
> LLVM & QVM (Quake 3 VM, но только Pure C) давно умеют в 10% разницы от силы.Только вот VM в LLVM эдакий "исторический прикол" и ни разу не VM в "привычно-традиционном" смысле.
Таким макаром можно и GCC в VM записать, c его GIMPLE/RTL и прочими промежуточными представлениями.
Я в курсе. Но я немного не об этом, не об использовании LLVM для генерации кода, а о возможности использования LLVM BitCode (Target) как библиотеки вне зависимости от операционной системы и ограничения такого модуля от доступа к системным вещам вне предоставленного API приложения которое такой модуль занрузило в качестве изолированной библиотеки.
Так, всё-таки, LLVM BitCode или WebAsm?
> о возможности использования LLVM BitCodehttp://llvm.org/docs/BitCodeFormat.html :
> What is commonly known as the LLVM bitcode file format (also, sometimes anachronistically known as bytecode) is actually two things: a bitstream container format and an encoding of LLVM IR into the container format.
> The bitstream format is an abstract encoding of structured data, very similar to XML in some ways. Like XML, bitstream files contain tags, and nested structures, and you can parse the file without having to understand the tags. Unlike XML, the bitstream format is a binary encoding, and unlike XML it provides a mechanism for the file to self-describe “abbreviations”, which are effectively size optimizations for the content.Отсюда видно, что это эффективно _промежуточное_ представление, которое создано не с целью его интерпретации, а с целью передачи бэкенду-llvm для дальнейшей компиляции. То есть это сложно-структурированный формат, с кучей информации не относящейся непосредственно к выполнению программы. Использовать его вместо байткода для виртуальной машины -- это идея, которая может и заслуживает рассмотрения, но в процессе этого рассмотрения надо не забыть, что итерпретация/компиляция этого дела в native-код может быть медленной и жрущей кучу ресурсов. Это IR представление само по себе может быть слишком жирным, в том смысле что код скомпилированный в wasm окажется меньше. Упоминание "abbreviations" ясно говорит о том, что без динамического выделения памяти под нужды интерпретатора ничего не выйдет.
А теперь давай глянем на wasm design goals: https://webassembly.github.io/spec/core/intro/introduction.h...
> Fast: executes with near native code performance, taking advantage of capabilities common to all contemporary hardware.
Как с этим у llvm ir?
> Safe: code is validated and executes in a memory-safe [2], sandboxed environment preventing data corruption or security breaches.
Я не знаю, насколько это отличает wasm от llvm-ir, поэтому опустим.
> Well-defined: fully and precisely defines valid programs and their behavior in a way that is easy to reason about informally and formally.
Как часто LLVM IR меняется между версиями llvm?
> Hardware-independent: can be compiled on all modern architectures, desktop or mobile devices and embedded systems alike.
wasm проще, значит написать виртуальную машину тоже проще, так ведь? Плюс если он проще, то и виртуальная машина проще и меньше, а значит на более слабых процессорах пойдёт. Как там насчёт запуска llvm на avr?
> Language-independent: does not privilege any particular language, programming model, or object model.
Паритет с llvm-ir?
> Platform-independent: can be embedded in browsers, run as a stand-alone VM, or integrated in other environments.
Тоже наверное паритет?
> Open: programs can interoperate with their environment in a simple and universal manner.
В llvm-ir есть что-нибудь об этом? Мне кажется, что нет, это для него отдельным стандартом придётся определять.
> Compact: has a binary format that is fast to transmit by being smaller than typical text or native code formats.
Это явно не в пользу llvm-ir, для целей которого, как я понимаю, размер .text не играет особой роли.
> Modular: programs can be split up in smaller parts that can be transmitted, cached, and consumed separately.
Сложно сказать, что именно имеется в виду. Давай считать, что паритет.
> Efficient: can be decoded, validated, and compiled in a fast single pass, equally with either just-in-time (JIT) or ahead-of-time (AOT) compilation.
Как у llvm с этим, ты не знаешь?
> Streamable: allows decoding, validation, and compilation to begin as soon as possible, before all data has been seen.
А с этим?
> Parallelizable: allows decoding, validation, and compilation to be split into many independent parallel tasks.
?
> Portable: makes no architectural assumptions that are not broadly supported across modern hardware.
Я не знаю, как там сделано в llvm, но опять же из самых общих соображений, для llvm'а напрашивается иной подход, который позволяет описывать как можно более широкий спектр кода, заточенного под разные архитектуры.
WASM и так почти нативен по скорости, вот прямо сейчас. За исключением случаев, когда в нативе используются какие-нибудь специфические инстукции типа AES-NI. Но, в отличие от джаваскриптов/джав, который можно на лету оптимизировать, не "перегонит" никогда.
> Казалось бы, что общего между JS интерпретором и виртуальной машиной для выполнения кода на C/C++ с практически одинаковой (близкой и ещё ближе в следующих версиях) скоростью исполнения?Например то, что их вытащили из браузера и используют не по назначению.
если сделают компилятор pascal в wasi будет круто
> если сделают компилятор pascal в wasi будет крутоpasiwasi
pascwasi
http://forum.lazarus.freepascal.org/index.php?topic=37474.0
Развитие Васи уже сильно продвинулось
Теперь это надо прикрутить к проекту, в котором "всё URL" ;)
Вы про Redox OS? )
Если оно будет близко по производительности к нативному коду, то почему бы и нет?
Будет ли по производиьтельности близко или нет, а вот песочницу обходить точно будет.
electron 2.0 ?
Ой, опять Мозилла за старое. Подобных прожектов у Мзиллы была уже тонна, самых разных калибров. Большинство потом отправляются известно куда - в забвение. Призм для десктопов, Телефон в браузере, FirefoxOS и так далее.
И это не смотря на то, что пару лет назад они приняли принцип "great or dead" на вообружение, не распыляться, а делать что-то в малом кол-ве, но хорошо, мы все равно видим что все по прежнему. Может быть какая-то польза от проекта и будет, но имхо лучше бы они работали над браузером.
Бюджет сам себя не распилит.
>great or deadСам догадаешься, куда качнулись чаши весов?
О, сколько нам уязвимостей чудных готовит WASI-друг...
я правильно понимаю, что теперь кроссплатформенные приложения будут сначала писаться на полноценных языках, потом транслироваться в жс и превращаться в нативные?Ладно - я могу понять вебмакак, которые не умеют ни во что кроме жс и тянут его на десктоп. Но зачем это нормальным людям? Раз уж все равно на крестах/расте/чо-там-еще-поддерживается работаешь - что мешает писать сразу кроссплатформенный код?
Ну возьмём, к примеру, GUI. В Linux их по факту два. Так что, как кроссплатформенно ни старайся, либо гномеры будут недоволны, либо кдешники.
> либо гномеры будут недоволны, либо кдешники.На эту проблему есть проверенное решение: больше стандартов богу стандартов. Чтобы эти две группы не обижались, что преференции отдали другой группе, надо использовать свой собственный тулкит с блекджеком и шлюхами.
Неправильно. WASM с JS связывает только то, что оно в браузерах есть. А так - просто платформенно-нейтральное представление, довольно низкоуровневое. Ожидаемые мозиллой плюшки - отсутствие необходимости отдельно компилировать под несколько аппаратных платформ и песочница (которую, правда, и так можно сделать, и делают).
10% разницы с нейтивом - это терпимо. Wasm-core встроить в каждую ОС и не нужно больше компилять.
И вирусы будут кроссплатформенными.
> Wasm-core встроить в каждую ОС и не нужно больше компилять.всё это приведёт к тому же говну к которому пришла Java (JVM).
1. программисты вместо того чтобы выдавать ПОЛНЫЙ исходный код проекта (даже если проект ВЕСЬ опенсурсный) -- предлагают компилировать из исходников только ядро-программы.
2. пользователь (или мэйнтейнер дистрибутива) компилирует проект. а на самом деле не проект, а только его ядро-программы, но декларирует будто скомпилировал проект.
3. программа запущенная пользователем -- по мере своей работы докачиает из интернета БИНАРНИКИ остальных своих частей.
4. скачивание НЕ удаётся так как:
a) пользователь НЕ сидит круглосуточно в интернете.b) пользователь СИДИТ в интернете но НЕ все ip-адреса доступны и хорошо работают из Чебурашки (или из VPN-против-Чебурашки, так как ряд CDN-провайдеров намеренно блокируют VPN. типа защищая сервера от "хакеров"). вобщем есть кучу причин почему ДОкачаться из интернета может НЕ удасться.
5. даже если скачивание удаётся -- у пользователя остаётся ощущение будто его обманули -- исходные коды он смотрел от одной программы а накачало ему в итоге хрен пойми что другое.
6. всех проблем можно было бы избежать если бы НЕ было бы уверенности у разработчика что "скомпилируй один раз и запускай везде": в этом случае у разработчика врядли зародилось бы желание ВТЮХИВАТЬ бинарники (докачивая из интернета) прямо во время работы программы.
// P.S.: примеры java-говна смотри: Apache Netbeans (в исходниках одно, а скачивется дополнительно другое, прямо во время работы) и Maven (без интернета вообще не заработает, неважно что ты установил его из репозитория).
// P.P.S.: в чём вообще проблема компилирования? и если не хочешь заставлять компилировать то почему бы не решить это через например flatpak?
Что-то тут перепутаны автоматическое затягивание зависимостей и закрытость кода.Можно подумать, что питон какой-нибудь, который ровно так же тянет зависимости, хоть и не бинарные, принципиально чем-то отличается.
Хочешь иметь все исходники - берёшь GPL-софт. А если лицензия позволяет закрытый код - какие претензии?
> Что-то тут перепутаны автоматическое затягивание зависимостей и закрытость кода.нет. не перепутаны. а взаимосвязаны.
возможность запускать бинарники без компиляции -- тенят за собой СТРАННОЕ жедание разработчиков делать "затягивание зависимостей (бинарников)".
"мы будем автоматически закачивать к клиенту недостающие бинарники, ведь всё равно мы уверены что не будет проблем с их запуском!" -- видимо так думают разработчики.
то есть речь о том что эта возможность портит "культуру".
> Можно подумать, что питон какой-нибудь, который ровно так же тянет зависимости, хоть и не бинарные, принципиально чем-то отличается.
вот как раз python не тянет зависиомси пока ты не попросишь его явно об этом. (а можно устроить себе даже так что вообще не попросит НИКОГДА -- если делать самому вручную ``python setup.py install``)
* можешь поставить зависимость из репозитория
* можешь скачать исходники (настоящие! а не исходники "ядра-программы") и сделать ``python setup.py ...``
* можешь в ЯВНОМ виде попросить накачать из python-овского pypi.любой из трёх способов в конечном итоге приведёт к рабочему результату.
> Хочешь иметь все исходники - берёшь GPL-софт. А если лицензия позволяет закрытый код - какие претензии?
опять-двадцать-пять! всё что с казал КАК ОРАЗ И ОТНОСИТСЯ К GPL/APACHE СОФТУ! софту который имеет открытые исходники, но который всё равно скачивает тебе бинарники (бинарники мимо репозитория и собранные неясно из каких исходников -- из тех которые на github или из каких-то других -- фиг проверишь)
Проблема комиляции - что надо компилировать под разные платформы. В основном боль проприетарщиков, конечно, но и просто держать систему сборки, умеющую собирать под всё и вся - та ещё морока.
Я под ноду запиливал порт гугловского конвертора woff2, на WebAssembly. Ляпота! Один раз собрал, и везде работает, и по мере выхода новых нод не ломается.Правда оно ориентировочно раза в 2 медленнее сишного. Но это приемлемая цена за полное отсутствие гимора. Сейчас наверное уже побыстрее должно быть.
У нативных бинарных модулей обычно раз в год-два чего-нибудь разъезжается.
>MavenОтлично работает без интернета
Прободение песочницы. Саша Грей в безопасности.
Адоб закрывает флэш. Ява так и не взлетела на настольных компах. А эти думают что ухватили бога за бороду и их поделие будет самым крутым.
Неплохая инициатива. Хотя можно было просто открыть Flash. Но...адоби - онаж идейная.
Люся... Вася... Наши люди везде штале?
Тогда и Валеру давайте ужо!