Live data from Hacker News

Standardizing WASI: A system interface to run WebAssembly outside the web

hacks.mozilla.org

51–60 of 238 posts

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#52
post #29

This is nice and I'm excited about it, however there is a concern that people are going to start building code that targets WASI and then shim it to run in the browser. This happened to JavaScript when Node.js was released; people began using APIs intended for servers and then shimmed them to also run in the browser resulting in code bloat. I'm worried that the same is going to happen here; the video actually encoura…

I think the browser shouldn't be a platform at all, frankly, and WASI is one possible way we can finally stop trying to shoehorn it into being one. If everything runs a WASI runtime, which is designed to run applications from the ground up, there really isn't any need for the browser to run applications anymore, is there?

That's like saying "now that we have Minix there isn't any need for Windows anymore". WASI is awesome, but the Web is here to stay.

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#53
post #40

Love it. This could be a huge innovation and really push the dream of cross platform development to the next level. I suppose this would have pretty big implications for Electron or a similar successor to aid in the UI portion of this endeavor.

Yep, just like....wait for it....UCSD Pascal.

Nobody is saying that the idea of a sandboxed VM is original. The interesting parts of wasm are the theoretically-uninteresting but important-in-practice features: JS interoperability, the LLVM backend, cross-browser support, etc.

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#54
post #35

Earlier quoted context omitted.

The idea of isolation that java espoused is not a bad one - it just wasnt executed well. Its not a java only idea either - see Native Client[0]. As with all things, execution and marketing matter. Java was lacking in both. [0] - https://static.googleusercontent.com/media/research.google.c...

OK, that's all correct and valid. Java still exists and is a valid deployment platform. Why is WebAssembly outside of the browser needed?

Using Oracle's Java Programming Language is an immeasurable legal liability.

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#55
post #45
post #22

Earlier quoted context omitted.

1. It's an open standard that the major browsers have agreed to, so it's not a plugin that you have to install. A WASM app will work seamlessly in your browser without any additional software. 2. WASM is designed from the ground up as a compile target, not a language. We already see many languages with support for building to WASM. C, C++, Rust, and eventually when WASM supports garbage collection we'll probably see…

Go already can be compiled to WASM, and it is likely that the Go GC will always perform better than the WASM one for Go applications (with some minor exceptions)

The current Go implementation is pretty slow for a number of reasons though.

GCs usually need low level system acces in a way that is not supported by WASM for obvious reasons (security, sandboxing, ...). Go also has problems with the way they implement Goroutines if I remember correctly.

WASM will definitely need some kind of GC bridge to make things efficient for garbage collected languages. Potentially with certain primitives exposed that make shipping your own GC efficient. We'll see how it develops.

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#56
post #29

This is nice and I'm excited about it, however there is a concern that people are going to start building code that targets WASI and then shim it to run in the browser. This happened to JavaScript when Node.js was released; people began using APIs intended for servers and then shimmed them to also run in the browser resulting in code bloat. I'm worried that the same is going to happen here; the video actually encoura…

I think the browser shouldn't be a platform at all, frankly, and WASI is one possible way we can finally stop trying to shoehorn it into being one. If everything runs a WASI runtime, which is designed to run applications from the ground up, there really isn't any need for the browser to run applications anymore, is there?

> there really isn't any need for the browser to run applications anymore, is there?

Of course there is. You can open a new "application" without installing, just by clicking a link or entering a URL. The beauty of browser as a platform is simplicity of navigation between apps you haven't previously installed.

Also, note that the distinction between a document and an application is vague. Is interactive document, perhaps containing an interactive map, an application? If yes, do you really want to install these interactive documents before accessing them?

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#57

I would love for WASI/WasmTime to emphasize on: 1. Backwards compatibility with existing libc. (Maybe pick musl) 2. Platform agnostic wasm generation: the same wasm file should run in the browser (with emscripten polyfills) and across ALL OS-es, mobile included. List: iOS, Android, Mac, Linux, Windows, FreeBSD #1 shall enable decades of legacy programs to work with minimal porting, while #2 shall enable true cross pl…

> 1. Backwards compatibility with existing libc. (Maybe pick musl) Honestly, that ought to be a non-goal. We already know that POSIX often enforces models that we don't want--filesystem permissions and the fork model are two good examples of things that are broken. So why start with "implement POSIX"?

The backwards compatibility isn't a testament for POSIX's merit. Sure, please introduce better, safer paradigms whenever you set standards, but enabling legacy software to run immediately is a great value proposition.

Also, goading legacy maintainers to adopt the newer, safer paradigms is likely more effective if you show them the traction the new platform is gaining

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#58

ok, so I hate to be this guy and I'm going to do it anyway because it has to be said: Did they just invent Java again? Aren't they promising what Java promised? Won't they hit the same problems that Java hits during its write-one-run-anywhere promises? I'm asking honestly - why is WebAssembly outside of the browser needed?

> why is WebAssembly outside of the browser needed? It's arguably a better standard runtime than Java, for certain use cases. You don't see modern compilers targeting the JVM as an output target, but you do see them targeting WASM, there's probably good reason(s) for that (both technical and political/legal). Furthermore, my understanding of WASI is that it allows standardization of _multiple_ runtimes, each domain s…

OK you answered a few of my questions and I still don't see why WASM is a requirement for any of this to happen.

No matter what language I use, no matter what platform I deploy to, if I want to interact with a service or with infrastructure, I'm going to have to use the provided API(s), WASM included.

If I deploy a pre-compiled binary to an AWS Lambda and an Azure Function, and it works on both, it's because I had to have that in mind when I wrote that software. Will that not be true for a runnable WASM binary? It sure seems like it would be true that I would need to detect which platform I'm running on and then execute the proper stuff for the detected platform.

If all APIs are going to be compatible with each other, so that, say, storing a file uses the same API call no matter what system or platform you're on (never going to happen; bear with me) implementing that in WASM outside of the browser does not suddenly make it possible.

This is an opinion, and on HN this is likely to be a very unpopular opinion. I don't expect anyone to adopt this opinion, nor do I expect to sway anyone's thought with this opinion. This really (really, really, really) feels like JavaScript/web people wanting to do things outside of the browser, with performance better than JavaScript alone can provide, and then, rather than simply using an existing language and runtime, deciding that the best route forward is to pave their own road to this destination with web technologies. This does not feel like the best route to take if you want to write software that performs well outside of a browser.

There are lots of other languages, runtimes, and platforms, that allow this today. And the web is a bag of chaos: I can't even get a consistent design or UI language across major websites, today. Buttons sometimes look like links, links sometimes look like menus, and buttons sometimes look like any of those, but somehow WASM outside of the browser is something everyone (except me) can agree on?

I'm skeptical that this is a good idea for anything serious.

Just like there are implementation problems with Java, there are going to be implementation problems with these runtimes that every platform is going to need in order to run this code, now. There are going to be many security concerns because (warning: incoming opinion) nearly all developers are terrible at thinking about preventing security vulnerabilities. Those same developers are usually OK when it comes to fixing them, and terrible at thinking about vulnerability prevention.

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#59

I would love for WASI/WasmTime to emphasize on: 1. Backwards compatibility with existing libc. (Maybe pick musl) 2. Platform agnostic wasm generation: the same wasm file should run in the browser (with emscripten polyfills) and across ALL OS-es, mobile included. List: iOS, Android, Mac, Linux, Windows, FreeBSD #1 shall enable decades of legacy programs to work with minimal porting, while #2 shall enable true cross pl…

> 1. Backwards compatibility with existing libc. (Maybe pick musl) Honestly, that ought to be a non-goal. We already know that POSIX often enforces models that we don't want--filesystem permissions and the fork model are two good examples of things that are broken. So why start with "implement POSIX"?

POSIX != C and from what i understand from the official docs, they already have a (musl derived, even) C library.

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#60
post #35

Earlier quoted context omitted.

The idea of isolation that java espoused is not a bad one - it just wasnt executed well. Its not a java only idea either - see Native Client[0]. As with all things, execution and marketing matter. Java was lacking in both. [0] - https://static.googleusercontent.com/media/research.google.c...

OK, that's all correct and valid. Java still exists and is a valid deployment platform. Why is WebAssembly outside of the browser needed?

Java is no longer a valid deployment platform for dynamically executing untrusted code.

https://www.java.com/en/download/faq/chrome.xml

The Java Plugin for web browsers relies on the cross-platform plugin architecture NPAPI, which had been supported by all major web browsers for over a decade. Google's Chrome version 45 and above have dropped support for NPAPI, and therefore Java Plugin do not work on these browsers anymore.

All the other browsers killed it as well.

There's probably some way you can do it outside the browser, but I've never seen it used. Was it called Java WebStart or something?

I think it's because the sandbox had too many holes, and it was large and clunky. It didn't integrate well with the browser.

Java is obviously still extremely popular, but it's used in trusted contexts, like on the server, or "semi-trusted" contexts, like the Android app store. Although that is a different JVM which is probably easier to secure. And in that case there has to be a manual review process before allowing arbitrary code to execute (which is imperfect, but better than nothing.)

Post reply on HN