Live data from Hacker News

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

hacks.mozilla.org

81–90 of 238 posts

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

#81

Excuse me if I come across as naive, I'm kind of a noob on these architectural topics, but how is this different/better than what the JVM is/accomplishes? When WASM first popped up I thought about the similarities with Java Web Applets and Flash.

Java applets and Flash are dead. WASM isn't.

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

#82
post #75

Earlier quoted context omitted.

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?

From reading your other comment "you can pull things over a network without a web browser...", your argument appears to be: we could have a separate platform from the browser for running web applications, and lose the need for the browser to support applications. Correct me if I misunderstood. A benefit of applications in the browser is that they share and benefit from the same security policy decisions which are mad…

> we could have a separate platform from the browser for running web applications, and lose the need for the browser to support applications.

Yes. And the benefit of that is that it building a new WASI implementation is almost certainly going to be much easier than building a new web browser currently is. If web browsers were to revert to being simple hypertext renderers, then those would be orders of magnitude easier to implement as well.

> Users are often coerced into giving up unnecessary permissions

How is that different from the web?

> and they have less control over the user experience (can't block ads or change styles).

If I have control over who the WASI VM can and cannot talk to, I can block ads using exactly the same mechanism that is used today. Styling would depend on precisely what interface ends up in common use to render graphics for WASI applications, it is totally possible to style native widgets or something like QT/GTK. You can't style anything that uses a canvas regardless.

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

#83
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?

I think the world in which the browser disappears and all we have is apps is a worse world than the one we have now.

With HTML/CSS we get the relatively easy ability to add extensions to dig deep into the data of a page. One of my favorite extensions is rikaikun which adds popup translation of Japanese words. It can only do this because it can inspect a standardized data structure (the DOM) with standardized APIs.

I also love the ad blockers. They let me not only block ads but also hide parts of websites I find distracting. For example I hide the "Hot posts from other stack exchange sites" section of stack overflow because I find I get sucked into 20-40-60 minute distractions if I don't hide it.

I can also copy and paste nearly any content and link to almost any content.

An a world of native apps none of this is really possible. Every native app will use its own internal representations of data. Different UI kits or libraries. Much of it is un-linkable, un-copyable, It drives me nuts when I can't copy and paste of phone number, or address in a native app.

I don't believe getting rid of the web for a WASI based app world would be a good thing for users.

PS: I think WASI is a great idea. I just think trying to replace HTML based apps with WebAssembly apps using WASI and rendering with WebGPU is the wrong direction for most web apps.

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

#84
post #10

Earlier quoted context omitted.

Will WASI normalize differences between platforms? e.g. convert argv or paths to a consistent character encoding?

Yes!

How will you deal with valid paths such as:

  /tmp/[DE][AD][BE][EF].txt # ext2 / linux
  # OR
  C:\stuff\[DEED][FFFE].txt # ntfs / windows
  # where [hex] indicates a single filesystem charater with that value

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

#85
post #60

Earlier quoted context omitted.

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…

It remains to be seen if WASI will actually have fewer holes in its sandbox. Fundamentally it is not different.

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

#86
post #59

Earlier quoted context omitted.

> 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.

The C stdlib is so married to POSIX they may as well be the same thing.

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

#87
post #78

Can't help being reminded of that talk by Gary Bernhardt: “The Birth & Death of JavaScript”[0] — exploring a hypothetical future where JS takes over everything without (most) anyone using it of their own volition. 0: https://www.destroyallsoftware.com/talks/the-birth-and-death...

Except entirely irrelevant as WASM is not Javascript.

Sure, though it’s still a web technology taking over an otherwise unrelated space ¯\_(ツ)_/¯

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

#88

These Mozilla blogs are some of the best edited, articulated and illustrated explanations I've seen on the web. I wish more people could put in the resources to help communicate their mission like this.

The author, Lin Clark[0], is the person behind Code Cartoons[1]. She does absolutely amazing work. Unfortunately, there isn't really a single place to find everything she has done. She has done quite a few conference talks[2] as well.

[0] https://twitter.com/linclark

[1] https://code-cartoons.com/

[1] https://hacks.mozilla.org/category/code-cartoons/

[1] https://twitter.com/codecartoons

[2] https://www.youtube.com/playlist?list=PLIIHcC8epcPqhBrQ1dRmI...

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

#90
post #60

Earlier quoted context omitted.

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…

Java inside the browser doesn't exist. That's fine. That's not what I'm talking about or making comparisons to.

Java runs just fine outside of the browser. You don't even need a browser installed to run Java applications.

Javascript and WASM run fine inside the browser, and that's not what I'm talking about or making comparisons to.

I'm talking about running WASM binaries outside of the browser. Similar to how Java runs outside of the browser. Very similar, actually. Java needs a runtime to be installed or available, so will WASI. Java is a write-once-run-anywhere type of platform, so is WASI.

Why does WASI need to exist if Java already exists for the intended uses?

Post reply on HN