I'm not sure why you'd choose webassembly over, say, MSIL for this?

The goal for WASI is a secure-by-default capabilities model for access to system APIs.

It's also an open collaborative cross-vendor specification with at least four different independent implementations.

MSIL/CIL is similar in some ways, but it's still largely only supported by Microsoft and doesn't sandbox binaries the same way. It's an inspiration to We assembly, but not a feasible alternative to it. Similar to Google's PNaCl bytecode.

Some more detail here:

https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webas...

https://hacks.mozilla.org/2019/11/announcing-the-bytecode-al... "secure-by-default foundations for native development that are portable and scalable."

For user interaction that works for everyone, i.e. covering internationalization and accessibility, one could do much worse than to just use the existing web platform APIs, DOM and all. Why reinvent all that?

What's wrong with using a subset of the browser APIs? Or, alternatively, one of the many existing platform APIs?

Browser APIs are not C ABIs and the platform C ABIs are typically not cross platform and make for a bad target.

POSIX, SDL and the usual suspects are pretty much cross-platform and run everywhere.

Browser APIs have C++ ABIs that can be generated through webIDL if I recall well.

What is the benefit of replacing the browser though?

There is no browser to replace. Many of us are trying to look into WASM for loadable modules or entire binaries.

I thought I already could do that since the late 80's.

With what? lisp? Java? MSIL?

https://hacks.mozilla.org/2019/11/announcing-the-bytecode-al.... "secure-by-default foundations for native development that are portable and scalable."

You can compile Hearbleed to WASM, secure by default, as long C or any of its derived languages are not used.

Sure, you can build a flimsy deathtrap house on top of a solid foundation in a lot of contexts. But if the foundation is unsound, it doesn't matter if your Ada is formally verified or not.

At least the Ada folks acknowledge that the language isn't perfect, and don't pretend they were the very first one on its field.

I don't see anyone pretending any such thing about WebAssembly or WASI. If anything they are drawing on the decades of experience with bytecode formats and security research.

Apparently not, otherwise bounds checking inside of the same linear memory segment would actually be supported.

Likewise, they wouldn't "forget" the formats that already had support for languages like C when talking about what is "new" with WebAssembly.

> bounds checking inside of the same linear memory segment

That can be supported in the source language.

Which is meaningless for module consumers and hardly any different from native processes.

AIUI, wasm does support using multiple linear memory segments at the same time. You don't get that on native processes short of using memory segmentation, which no modern architecture supports.

CPUs like SPARC ADI and ARM MTE offer much better memory protection than what is being sold by WASM.

Solaris, iOS and future Android versions take advantage of their existence.

Which is completely irrelevant as by definition they are not portable.

The fact remain that wasm module have a very well defined behavior when embedded in other applications and can be embedded in a portable way.

I'm not sure I understand what you're saying. There are two core principles behind WebAssembly. First of all you can run low level programming languages like C on any architecture. This is possible if the code is available and you are willing to compile the C code before installing the application (see gentoo). Secondly the libraries/APIs that the program depends on must be available.

What you're saying is that every vendor shipped their software with source code and only used cross platform APIs. Is that right?

> First of all you can run low level programming languages like C on any architecture

Just like with TIMI, MSIL, EM, ADF, TendDRA, PNaCL among others.

> What you're saying is that every vendor shipped their software with source code and only used cross platform APIs. Is that right?

Rather that this is nothing new, and the formats listed above, already offered the same capabilities, without the same marketing.

I don’t see how asmjs/wasm’s marketing would be much different to the one of pnacl/nacl. It’s just fundamentally better and that’s why people are excited.

So much better that PNaCL still outperforms WASM.

https://www.pdftron.com/blog/wasm/wasm-vs-pnacl/

And it doesn't offer any significant security improvements, in spite of its marketing, compiling Heartbleed into WASM is still possible.

The reason people are excited about WASM is neither security nor performance.

So what is so exciting about a bytecode format, created out of the political war between PNaCL and asm.js, without any big news for anyone that actually cares about bytecode formats invented since 1958 with the introduction of UNCOL and subsequent attempts?

Compared to other bytecode formats, it has lots of advantages. Browsers support it, LLVM targets it, people are using it.

I don't really see the point of using WebAssembly (or any other bytecode format) outside the browser, though. It just seems like a way to throw away performance for no benefit.

Browsers support it because Mozilla refused to adopt PNaCL, which was also targeted by LLVM, WebAssembly is a political compromise, not any kind of technical achievement as it keeps being celebrated for.

Mainframes and midrange computers have used bytecode formats since the early 60's as hardware independence mechanism, where you AOT compile at installation time, or have an hardware interpreter implemented as part of a micro-coded CPU.

It has allowed those kind of computers to advance their hardware to modern times, while keeping the applications unchanged.

The same idea is widely used on embedded platforms, as it gives OEMs flexibility designing hardware, while reducing software development costs even further.

I honestly do not see the point you are arguing "for" here. I understand you find wrong the hype about webassembly and many of you comparison are adequate.

You say that wasm is a political "bastard" born out of mozilla refusal for PNaCL. I disagree, but it is a way of looking at history.

But then my stance would be that to satisfy the w in wasm it Needs to be a political chimera, the whole web is predicated on the model of vendors fighting political and technical battles over standard. PNaCL lost that battle, Java lost miserably that battle, every other portable assembly ever never even participated.

Are you criticizing wasm or the open web?

Not a technical achievement so much as a different point in the design space. Two key differences. First, NaCl was originally designed to run in its own process, for a few different reasons:

- The original 32-bit x86 implementation fundamentally required it because, due to how it used %ss, a crash in the sandboxed code would crash the whole process. [1] Avoiding that issue would have required a different model that had performance overhead (and was more complicated). Ironically, the 64-bit version had no such requirement, but by then NaCl's design was already well-established.

- AFAIK it was originally developed separately from Chrome, so there was less motivation to deeply integrate it with JS.

- It was apparently conceived as a replacement for plugins (originally using NPAPI, before PPAPI was invented), which Chrome had run in a separate process anyway.

But WebAssembly is designed to run in the same process as DOM/JS, giving it two key advantages: it can reuse Web APIs rather than needing a whole separate set of APIs (PPAPI), and it can directly call and be called from JS. Both make life easier for developers; reusing web APIs also makes life easier for implementers.

The second key difference is that NaCl leaks much more information about the native environment than WebAssembly. Even with PNaCl, the native text segment, the native stack, and certain bits of implementation code were all accessible within the sandboxed address space. If you were up to shenanigans, you could even do things like jump into the middle of a native function, completely breaking the portability abstraction. Was that a problem? I don't know. It was conceptually secure; you couldn't break out of the sandbox without finding a vulnerability, just like WebAssembly. But it was a lot less isolated. In contrast, WebAssembly makes none of those things accessible and enforces full control flow integrity. You can't even tell which architecture you're running on, aside from indirect observations by benchmarking instructions or checking for memory ordering violations.

That difference is certainly responsible for some of the performance gap between NaCl and WebAssembly. Is it responsible for all of it? I don't know. I don't even know how big the gap is in the first place; the PDFTron benchmark makes it look major, but I haven't seen any other benchmarks, and I'm not sure if anyone has investigated what exactly is causing the overhead in the PDFTron benchmark, especially since the code isn't open source.

[1] https://static.googleusercontent.com/media/research.google.c...

Eh, no. Vendors everywhere will package things for your architecture and give you binaries.

That is how it has always been done and is still done.

Yes, you can do it differently with an IL, but that isn't new either (Java, .NET, etc.).

I tried and ran into many (well known, at this point) problems. WASM solves them.

The same as from using Electron, but a step further: less overhead from unneeded browser features, ability to lock the user into a kiosk/fullscreen mode, while most of the code is still reusable.

You mean like standard desktop application we had until the browser took over?

There are significant differences between standard desktop applications, Electron applications, progressive web applications, isomorphic/universal applications and so on. Usually the business case decides. If you want people to make more standard desktop applications, you should figure out a way to make it work for the common Electron app business case. Or stop throwing baseless shit in their general direction just because they've chosen a technology that does not meet your purity requirements. I'm very sure everyone in the community agrees Electron is not ideal.

> There are significant differences between standard desktop applications, Electron applications

That is certainly true.

But I was answering to

> The same as from using Electron, but a step further: less overhead from unneeded browser features, ability to lock the user into a kiosk/fullscreen mode, while most of the code is still reusable.

namely _Desktop applications_

Wasmer claim is

> Use the tools you know and the languages you love. Compile everything to WebAssembly. Run it on any OS or embed it into other languages.

There's no browser involved here, just compile once, run everywhere

I have the feeling I already heard it...

> [..], just compile once, run everywhere

>I have the feeling I already heard it...

If you are referring to java then something to note is

> Use the tools you know and the languages you love.

> Compile everything to WebAssembly.

> [..] embed it into other languages.

Which to my understanding apply only marginally to java; especially the embedding part.

> the common Electron app business case

Serious question: what is the common electron app business case?

Being able to run as a desktop app as well as in a browser?

From my POI: Yes, and reuse developers and code you already have for the web version.

Ok, thanks, that makes sense.

The reuse developers part I suppose could be achieved with QtQuick since QML is javascript based, but beyond the language, not that much else translates and you can’t completely get away from C++ for anything non-trivial, so it’s not really an electron competitor.

>Serious question: what is the common electron app business case?

Easy portability (not perfect) between all major platform

Electron is the least worst technology we have for building expressive 2D GUIs. Carlo and others are just an incremental improvement.

Every other GUI libraries are order of magnitude inferiors except if you just want to look like windows default utilities.

Imagine if apps would blend in with the host OS! The horror!

Sorry but the founder wants his specific UI, I can't do anything about it, my job is to do it.