9 ms·

So many comments here missing the point. As a developer, I can use wasm to ship a single binary that works on Windows, Mac, Linux, Android, and iOS. I can use t

So many comments here missing the point. As a developer, I can use wasm to ship a single binary that works on Windows, Mac, Linux, Android, and iOS. I can use the language that I want. I don't need to have Xcode, visual studio, android studio, or any other set of tools: you can reasonably build an app with your text editor and LLVM. And then, you can use my app by typing its address into your address bar. No installation needed. No polluting your home directory. No registry entries. It's sandboxed, you're never giving the app permissions that you don't intend. A service worker can be used to make the app available offline. My dear grandmother could use this without confusion. My dad can use these apps and feel confident he's not not infesting himself with malware or bundled software. The complaints about "the web doesn't feel native!" and "it's less secure!" and "it's just as easy to ship a native app [for my platform of choice]!" are tired arguments. We've finally got a simple way to distribute apps fully cross platform in a way that CAN respect privacy and guarantees a reasonable level of security. And, it's pretty darn fast.

snek 7y ago
The thing I'm most excited about right now is WASI. It provides abstractions for system calls like fs, sockets, graphics, etc. But the best part is that the entire API is being designed with security and capabilities in mind. WASM binaries have to explicitly declare resources they want access to, or risk not being allowed to access them. (The application could also choose to further prompt the user, but i think in most cases they will just be denied). Once resources are acquired, we use unforgable handles to refer to them. It is a super cool and declarative way to make sure people know exactly what a wasm bin will try to access before it's even run.
- nteon 7y ago
  (I'm one of the authors of Not So Fast) In the paper we build on previous work from our group, Browsix ( https://browsix.org https://browsix.org ) to provide a similar level of abstractions to WASI (the syscall layer). We've talked about having Browsix support running programs targeting WASI in the browser. One of the great things about supporting "Unix" in the browser is that it makes bringing a whole class of already written applications and library into the browser. I'm excited to see what people do with WASI, but its not clear to me what a program designed from the ground up around capabilities would look like!
  - jadbox 7y ago
    Just so I understand, is Browsix running on top of WASI... or are you saying that Browsix will have an option to target WASI? Browsix looks pretty cool, although it's hard to wrap my mind around use-cases outside porting common C libs (like pdf editing). I'm thinking that decentralized apps would be an interesting Browsix use-case where users can run the full app platform stack in their browser... or connect to dedicated self-hosting servers that are running the same exact code but as native Go/C/Node services.
    - nteon 7y ago
      WASI provides a cross platform definition of "system calls" ( https://github.com/WebAssembly/WASI/blob/master/design/WASI-core.md#system-calls https://github.com/WebAssembly/WASI/blob/master/design/WASI-... ), so that you could write a program, compile it for wasm+wasi, and run the program on any implementation that provides those system calls, like cranelift on Linux, something on Windows, Browsix in the browser. Browsix and Browsix-Wasm were developed before Wasm and WASI respectively were available, so they have their own definition of syscalls that are conceptually similar but not exactly binary compatible. We hope to modify Browsix to support running programs targeting WASI in the browser, which would free us from having to maintain our own fork of Emscripten. Do you have specific decentalized apps or usecases in mind? We would love to hear more about the use cases of running things like that in the browser (and have done some work to make socket connections between programs in different browser tabs work over WebRTC)
deleted 7y ago
[deleted]
AnIdiotOnTheNet 7y ago
Literally everything you said except the part about using the language you want has been true of Java for at least a decade. Everything old is new again.
- adwn 7y ago
  > Literally everything you said except the part about using the language you want has been true of Java for at least a decade. Everything old is new again. "Literally everything you said except the part about inflatable tires has been true of wooden wheels for at least 3000 years. Everything old is new again." Sometimes, reinventing the wheel actually makes sense.
  - AnIdiotOnTheNet 7y ago
    You're going to have a hard time convincing me that the browser as a runtime is a better solution than a runtime actually designed for running applications.
    - ScottFree 7y ago
      The problem lays in the UI. Most of what a modern application does is provide a decent UI to interact with data on a remote server. Swing was a terrible UI library. I never saw a java applet that wasn't ugly and clunky.
      - AnIdiotOnTheNet 7y ago
        And the completely non-native snowflake mobile-first slow-as-hell UIs of today's web are better?
        ScottFree 7y ago
        Yes. Presentation matters.
        7y ago
nurettin 7y ago
Sure, list clicker apps can ve distributed in such a manner. On the other hand, I still have no way of distributing my system services easily in a cross-platform way. Say, I have a service that is triggered when RC45 is jacked in or when a passive scan on a wifi device is completed. I still have to package it for android, ios, osx, linux (rpm, deb, aur) and windows separately.
oaiey 7y ago
This is to the point. Adding one thing: the availability of a standardized UI stack. WebAssembly vs a docker container is not that different on a server, but the described client is the differentiator to all competitor. The only real contender QT with C++ is quite a tough and insecure (and ugly) package in comparison.
Merad 7y ago
> So many comments here missing the point. As a developer, I can use wasm to ship a single binary that works on Windows, Mac, Linux, Android, and iOS. But we've accomplished that by effectively turning web browsers into VM's that have a complexity on par with a full operating system. I have a sneaking suspicion that we're going to end up deciding that was a huge mistake.
- jdc 7y ago
  You'd have to go back farther than the intro of WASM to see a time that wasn't the case.
- woah 7y ago
  No, you might be thinking about something like Electron. There are WASM VM’s for many platforms and they are very simple and do not involve a web browser. Whether they have a good common ui library is of course a different question, but one that will be resolved in due course.
- hnick 7y ago
  It's abstractions all the way down!
- manigandham 7y ago
  Web browsers are where it starts but we're getting native WASM runtime/containers that can just start a program from the disk. The browser then just becomes a shell around it with the ability to find a binary over a URL rather than locally, along with some other web-related features.
amptorn 7y ago
What privacy and security attributes does WebAssembly have over a plain old web page?
- bastawhiz 7y ago
  It doesn't need to improve the security or privacy. It's the same. But it lets you write in any language that can compile to LLVM IR, and it's fast. Which means that many applications which were previously impractical in vanilla JavaScript are now possible.
EastSmith 7y ago
Sandboxing is the most underrated browser feature ever. I prefer webapps before any native app just because of the sandboxing. A native app has uncontrolled access to everything on my system (in a usual end user install). Good luck to a browser app that tries to access My Documents or My Pictures.

snek 7y ago

The thing I'm most excited about right now is WASI. It provides abstractions for system calls like fs, sockets, graphics, etc. But the best part is that the entire API is being designed with security and capabilities in mind. WASM binaries have to explicitly declare resources they want access to, or risk not being allowed to access them. (The application could also choose to further prompt the user, but i think in most cases they will just be denied). Once resources are acquired, we use unforgable handles to refer to them. It is a super cool and declarative way to make sure people know exactly what a wasm bin will try to access before it's even run.

nteon 7y ago
(I'm one of the authors of Not So Fast) In the paper we build on previous work from our group, Browsix ( https://browsix.org https://browsix.org ) to provide a similar level of abstractions to WASI (the syscall layer). We've talked about having Browsix support running programs targeting WASI in the browser. One of the great things about supporting "Unix" in the browser is that it makes bringing a whole class of already written applications and library into the browser. I'm excited to see what people do with WASI, but its not clear to me what a program designed from the ground up around capabilities would look like!
- jadbox 7y ago
  Just so I understand, is Browsix running on top of WASI... or are you saying that Browsix will have an option to target WASI? Browsix looks pretty cool, although it's hard to wrap my mind around use-cases outside porting common C libs (like pdf editing). I'm thinking that decentralized apps would be an interesting Browsix use-case where users can run the full app platform stack in their browser... or connect to dedicated self-hosting servers that are running the same exact code but as native Go/C/Node services.
  - nteon 7y ago
    WASI provides a cross platform definition of "system calls" ( https://github.com/WebAssembly/WASI/blob/master/design/WASI-core.md#system-calls https://github.com/WebAssembly/WASI/blob/master/design/WASI-... ), so that you could write a program, compile it for wasm+wasi, and run the program on any implementation that provides those system calls, like cranelift on Linux, something on Windows, Browsix in the browser. Browsix and Browsix-Wasm were developed before Wasm and WASI respectively were available, so they have their own definition of syscalls that are conceptually similar but not exactly binary compatible. We hope to modify Browsix to support running programs targeting WASI in the browser, which would free us from having to maintain our own fork of Emscripten. Do you have specific decentalized apps or usecases in mind? We would love to hear more about the use cases of running things like that in the browser (and have done some work to make socket connections between programs in different browser tabs work over WebRTC)

deleted 7y ago

[deleted]

AnIdiotOnTheNet 7y ago

Literally everything you said except the part about using the language you want has been true of Java for at least a decade. Everything old is new again.

adwn 7y ago
> Literally everything you said except the part about using the language you want has been true of Java for at least a decade. Everything old is new again. "Literally everything you said except the part about inflatable tires has been true of wooden wheels for at least 3000 years. Everything old is new again." Sometimes, reinventing the wheel actually makes sense.
- AnIdiotOnTheNet 7y ago
  You're going to have a hard time convincing me that the browser as a runtime is a better solution than a runtime actually designed for running applications.
  - ScottFree 7y ago
    The problem lays in the UI. Most of what a modern application does is provide a decent UI to interact with data on a remote server. Swing was a terrible UI library. I never saw a java applet that wasn't ugly and clunky.
    - AnIdiotOnTheNet 7y ago
      And the completely non-native snowflake mobile-first slow-as-hell UIs of today's web are better?
      - ScottFree 7y ago
        Yes. Presentation matters.
        7y ago

nurettin 7y ago

Sure, list clicker apps can ve distributed in such a manner. On the other hand, I still have no way of distributing my system services easily in a cross-platform way. Say, I have a service that is triggered when RC45 is jacked in or when a passive scan on a wifi device is completed. I still have to package it for android, ios, osx, linux (rpm, deb, aur) and windows separately.

oaiey 7y ago

This is to the point. Adding one thing: the availability of a standardized UI stack. WebAssembly vs a docker container is not that different on a server, but the described client is the differentiator to all competitor. The only real contender QT with C++ is quite a tough and insecure (and ugly) package in comparison.

Merad 7y ago

> So many comments here missing the point. As a developer, I can use wasm to ship a single binary that works on Windows, Mac, Linux, Android, and iOS. But we've accomplished that by effectively turning web browsers into VM's that have a complexity on par with a full operating system. I have a sneaking suspicion that we're going to end up deciding that was a huge mistake.

jdc 7y ago
You'd have to go back farther than the intro of WASM to see a time that wasn't the case.
woah 7y ago
No, you might be thinking about something like Electron. There are WASM VM’s for many platforms and they are very simple and do not involve a web browser. Whether they have a good common ui library is of course a different question, but one that will be resolved in due course.
hnick 7y ago
It's abstractions all the way down!
manigandham 7y ago
Web browsers are where it starts but we're getting native WASM runtime/containers that can just start a program from the disk. The browser then just becomes a shell around it with the ability to find a binary over a URL rather than locally, along with some other web-related features.

amptorn 7y ago

What privacy and security attributes does WebAssembly have over a plain old web page?

bastawhiz 7y ago
It doesn't need to improve the security or privacy. It's the same. But it lets you write in any language that can compile to LLVM IR, and it's fast. Which means that many applications which were previously impractical in vanilla JavaScript are now possible.

EastSmith 7y ago

Sandboxing is the most underrated browser feature ever. I prefer webapps before any native app just because of the sandboxing. A native app has uncontrolled access to everything on my system (in a usual end user install). Good luck to a browser app that tries to access My Documents or My Pictures.