Программисты хорошо знакомы с Portable Executable, форматом исполняемых файлов для Windows. WebAssembly сулит все те же возможности, что и PE, в браузере. Но у них разный путь становления, что привело к фундаментальным различиям. Различия можно отчасти сгладить, и всё же придётся иметь их ввиду.

Память

Модули Portable Executable имеют доступ к единому адресному пространству процесса. Модули WebAssembly должны импортировать или экспортировать блок памяти. Впрочем, могут не пользоваться массивной памятью или же пользоваться встроенной памятью, но не экспортировать наружу. Модуль Wasm, экспортирующий блок памяти, похож на PE exe: exe является точкой роста, он определяет содержимое своей памяти, а все остальные модули (PE dll) входят в виртуальное адресное адресное пространство, определённое PE exe. В частности, это проявляется в том, что до недавних усилий по повышению безопасности многие PE exe нельзя было перебазировать из-за отсутствия релокаций.

Наиболее гибкие модули WebAssembly, импортирующие блок памяти Wasm.Memory, и они похожи на PE dll. Из-за ограничений WebAssembly имеет смысл и аналоги exe делать в виде модулей Wasm с импортом памяти. Потому что хотя exe и первый определяет виртуальную память, но запуск exe требует подключения всех dll, и только после подключения dll запускается исполнение exe, и воспроизведение такого поведения в Wasm всё же требует, чтобы Wasm.Memory импортировался.

Прямая связь модулей

Однако если можно почти любую PE dll брать и подключать в программу, объявив, конечно, внешние функции, то из-за особенностей WebAssembly нельзя того же утверждать про произвольные модули WebAssembly. В HTML5 практически сложно назвать что-то главной программой, так что там не должно быть аналогов PE exe, и всё же модули Wasm часто устроены таким способом, который не подходит для загрузки их как dll в общую память, в том числе из-за неправильного подключения Wasm.Memory. Про WebAssembly можно утверждать, что модули WebAssembly заворачиваются в интерфейс для работы с ними из JavaScript, но не гарантируется прямая связь WebAssembly-WebAssembly аналогично прямой связи dll-dll или exe-dll в Portable Executable. Без специальных усилий со стороны инструментов разработки вместо WebAssembly-WebAssembly можно получить: WebAssembly-JavaScript-WebAssembly.

Подключение модулей

Portable Executable содержит указания, по каким именам загружать dll. Такие файлы или ресурсы, как config и manifest, могут ещё немного скорректировать места поиска dll. Таким образом, запуск exe или LoadLibrary для dll позволяют загрузить программу или библиотеку со всеми их зависимостями автоматически. В среде браузера это более сложный процесс, и сложность перекладывается на плечи программиста. В частности, в обычном окружении браузера нельзя или крайне нежелательно делать синхронную загрузку файла (в WebWorker можно). Из-за этого сложность загрузки перекладывается на плечи программиста таким образом, что инстанциация модуля WebAssembly требует предоставления его подключенных библиотек в уже инстанциированном виде. А для этого нужно было библиотеки уже как-то рекурсивно найти и асинхронно загрузить. Этот дополнительный код пишется разработчиками трансляторов, и пишется по-разному.

Положительные стороны WebAssembly

В Portable Executable большую популярность получили структуры данных со ссылками на виртуальные адреса. Как само собой разумеющееся предполагается, что PE exe или dll загружен с диска в память, и тогда обходить эти структуры данных становится посильной задачей. Но менять многое невозможно надёжно, либо избыточно сложно. Например, было непросто написать такую программу, как ResHacker. У WebAssembly формат файлов лучше типизирован, с ним удобнее работать в исходном (файловом) виде.

Итог

Компилировать WebAssembly можно так, чтобы они были похожи на Portable Executable dll, но от сторонних разработчиков не приходится ожидать, чтобы они так компилировали.

WebAssembly устроен как конструктор сделай-сам. А сделать самому можно по-разному. Не каждый программист занимается таким конструированием, но разработчики разных трансляторов делают свои воплощения, отличающиеся в подходах. Компилировать WebAssembly как Portable Executable dll теоретически можно, но чужие скомпилированные wasm не работают как dll. И если какой-то новый транслятор заявляет поддержку WebAssembly, то вовсе не обязательно продукты его трансляции получится загружать и вызывать удобно как dll.

Отчасти различия в инструментариях призваны сгладить спецификации WebAssembly Tool Conventions