10 ms·

With the current state of things WASM is if anything more interesting outside of the browser than in it. Having to shim through JS to interact with browser APIs

by magila 5y ago

With the current state of things WASM is if anything more interesting outside of the browser than in it. Having to shim through JS to interact with browser APIs makes interacting with the outside world sufficiently slow and cumbersome that WASM in the browser usually only makes sense if you have some large computation which requires little-to-no I/O. Outside of the browser you at least have a chance of interacting with the underlying APIs in a performant enough manner to enable a wide variety of applications.

tasogare 5y ago
Genuine question: What does it bring new to the table?
- wtetzner 5y ago
  I think the main thing it brings is a portable compiler target that actually stands a chance at being widely adopted.
- GranularRecipe 5y ago
  Solomon Hykes, author of Docker: If WASM+WASI existed in 2008, we wouldn't have needed to created Docker. That's how important it is. Webassembly on the server is the future of computing. A standardized system interface was the missing link. Let's hope WASI is up to the task! cf https://twitter.com/solomonstre/status/1111004913222324225?lang=en https://twitter.com/solomonstre/status/1111004913222324225?l...
  - junon 5y ago
    This is strange. WASM can't handle half the things Docker needs to run. I'm genuinely confused as to how he can say the two are equivalent in any way, despite being the author of docker. VMs existed at the time. Java was one of them, probably the most prolific of them all, and certainly had a standardized system interface. Further WASI is a nightmare. Most projects I've personally seen disregard it completely.
    - sitkack 5y ago
      You are putting the cart before the Solomon. He is saying they would have built on WASM+WASI in the way that Docker is built on cgroups. Java is not a target for C++ code compiled via Clang/LLVM. Wasm is. Expert advice done cheap.
      - pjmlp 5y ago
        https://www.graalvm.org/reference-manual/llvm https://www.graalvm.org/reference-manual/llvm Experts happen to know what is actually possible.
        sitkack 5y ago
        Graal has AoT, you cannot compile Java to native with LLVM. But you know this already. You cannot compile C++ to the JVM w/o heroics or interpreting a RISC machine (nestedvm). Are you going to quip that Burroughs did all this already as well?
        pjmlp 5y ago
        Of course you cannot compile Java to native with LLVM, the support isn't there, that doesn't mean there aren't other Java AOT compilers to choose from, like the now gone Excelsior JET, or PTC and Aicas still on the market. Not Burroughs, but AS/400 TIMI (now IBM i), Microsoft MSIL, TenDRA compiler suite, if you want to talk about C++ aware bytecodes.
      - junon 5y ago
        But... you can't. They still would have had to have built a custom VM that could forward full-on Syscalls, so Docker (or something similar) would still have to be written. This still doesn't make sense to me. Cgroups are a Linux kernel feature, WASM is a VM. They do not have the same (or similar) scope of features.
        sitkack 5y ago
        You no longer need syscalls when you can interpose the whole runtime, you don't need cgroups either for a wasm process. Sandboxing becomes a purely user mode construct, no OS magic needed.
  - pjmlp 5y ago
    He should have gone talk to Microsoft and learn about MSIL.
- follower 5y ago
  For me, the most interesting potential of WASM is it provides a platform-independent sandboxed way to run untrusted code written in multiple programming languages. This means it's in theory possible to run the same code on an embedded hardware platform, a desktop app or in the browser. And while I'm sure there's "serious" business uses for that capability :) I'm most interested in what it enables in terms of user customisation/modding of games. Which was my main motivation for creating a Wasmtime WASM runtime add-on for the Godot game engine: https://gitlab.com/RancidBacon/godot-wasm-engine https://gitlab.com/RancidBacon/godot-wasm-engine And also designing the "WebAssembly Calling Card" specification as a way of demonstrating how the same code could produce graphical output that is then used in 2D or 3D environments: https://wacc.rancidbacon.com https://wacc.rancidbacon.com
  - jsd1982 5y ago
    This is exactly what I'm doing right now with SNES emulators, bsnes-plus specifically. The idea is to be able to extend certain games and give wasm module the ability to read/write the emulated memory and send/receive messages over a network connection to another process, among other things.
    - follower 5y ago
      Sounds cool! Do you have anywhere that interested people can read more about the project/progress?
      - jsd1982 5y ago
        Hm not really but I do update my repo on github.com. It's all work in progress stuff being designed as I go. https://github.com/alttpo/bsnes-plus/tree/wasm/bsnes/wasm https://github.com/alttpo/bsnes-plus/tree/wasm/bsnes/wasm
  - still_grokking 5y ago
    > This means it's in theory possible to run the same code on an embedded hardware platform, a desktop app or in the browser. Maybe want to talk to the Java guys, and ask them why this doesn't work out in practice? ;-) Just having a common byte-code interpreter isn't enough for portability of applications.
- tiew9Vii 5y ago
  Think of WASM as a JVM alternative, but it has heavy sandboxing. By default, WASM is pure computing. It can't interact with the outside world. You need to allow WASM to talk to the outside world explicitly. You have native performance. It's fast. It's platform-independent, and multiple languages can compile to WASM. The properties lead to some useful applications. Serverless, FaaS. If you use WASM for Serverless you get very fast execution + cold starts. Cloudflare Workers can do 200ms cold starts and 20ms a request. Fastly Cloud@Edge not being a Chrome browser, but instead, its own runtime can do better and serve requests in 10ms. The low overhead and secure sandboxing means you can bin-pack these at a massive scale and call them with little overhead. It's much more efficient than Lambda etc. Cloudflare and Fastly as edge CDN providers allow you to deploy fast apps, globally distributed by default, piggyback off their existing caching functionality with no need for API gateways/complex plumbing etc. Fastly's C@E is especially interesting. Unfortunately, Fastly have failed to capitalise on it product-wise. As a product, Cloudflare is way ahead. The best tech doesn't win. I'm not disparaging Cloudflare here. I personally use Cloudflare over Fastly because, at this point, Cloudflare are a more complete product/ecosystem with superior pricing model. For serverless, it's early days but WASM/WASI will probably disrupt the current FaaS providers once the rough edges are worked out. I wish Fastly had a better product/business execution team to realise C@E properly. Outside of Serverless/FaaS it makes massive sense instead of people deploying full OS's in a Docker image on Kubernetes, instead deploy WASM modules. Wasmcloud (https://wasmcloud.dev/ https://wasmcloud.dev/) looks to be one of the first here running an actor system in Kuberenetes where the Actors are WASM apps. The other place where it has big potential is to be the Electron from hardware devices. Here's a talk for building a WebAssembly runtime for IPlayer https://www.youtube.com/watch?v=28paRXqI-Gk https://www.youtube.com/watch?v=28paRXqI-Gk . They essentially made the bulk of the logic/app in Webassembly then created small shims for different devices to load it. Webassembly allowed the hardware providers to offer a portable runtime that can execute 3rd party software in a restricted runtime. WebAssembly in the browser is the least exciting part about WebAssembly. I'm incredibly excited to see how it is used for Microservices and serverless.
  - pjmlp 5y ago
    > By default, WASM is pure computing. It can't interact with the outside world. You need to allow WASM to talk to the outside world explicitly. That only applies to MVP 1.0, the long term roadmap hardly makes it any different from the myriad of other bytecode distribution formats.
lcnmrn 5y ago
WASM is to Node what C/C++ extensions are to Python.
- deleted 5y ago
  [deleted]
  - deleted 5y ago
    [deleted]
- ameliaquining 5y ago
  That doesn't particularly sound right to me. Node also supports C/C++ extensions, and AFAICT the use of Wasm in Node for performance is still relatively uncommon.

by magila 5y ago

tasogare 5y ago

Genuine question: What does it bring new to the table?

wtetzner 5y ago
I think the main thing it brings is a portable compiler target that actually stands a chance at being widely adopted.
GranularRecipe 5y ago
Solomon Hykes, author of Docker: If WASM+WASI existed in 2008, we wouldn't have needed to created Docker. That's how important it is. Webassembly on the server is the future of computing. A standardized system interface was the missing link. Let's hope WASI is up to the task! cf https://twitter.com/solomonstre/status/1111004913222324225?lang=en https://twitter.com/solomonstre/status/1111004913222324225?l...
- junon 5y ago
  This is strange. WASM can't handle half the things Docker needs to run. I'm genuinely confused as to how he can say the two are equivalent in any way, despite being the author of docker. VMs existed at the time. Java was one of them, probably the most prolific of them all, and certainly had a standardized system interface. Further WASI is a nightmare. Most projects I've personally seen disregard it completely.
  - sitkack 5y ago
    You are putting the cart before the Solomon. He is saying they would have built on WASM+WASI in the way that Docker is built on cgroups. Java is not a target for C++ code compiled via Clang/LLVM. Wasm is. Expert advice done cheap.
    - pjmlp 5y ago
      https://www.graalvm.org/reference-manual/llvm https://www.graalvm.org/reference-manual/llvm Experts happen to know what is actually possible.
      - sitkack 5y ago
        Graal has AoT, you cannot compile Java to native with LLVM. But you know this already. You cannot compile C++ to the JVM w/o heroics or interpreting a RISC machine (nestedvm). Are you going to quip that Burroughs did all this already as well?
        pjmlp 5y ago
        Of course you cannot compile Java to native with LLVM, the support isn't there, that doesn't mean there aren't other Java AOT compilers to choose from, like the now gone Excelsior JET, or PTC and Aicas still on the market. Not Burroughs, but AS/400 TIMI (now IBM i), Microsoft MSIL, TenDRA compiler suite, if you want to talk about C++ aware bytecodes.
    - junon 5y ago
      But... you can't. They still would have had to have built a custom VM that could forward full-on Syscalls, so Docker (or something similar) would still have to be written. This still doesn't make sense to me. Cgroups are a Linux kernel feature, WASM is a VM. They do not have the same (or similar) scope of features.
      - sitkack 5y ago
        You no longer need syscalls when you can interpose the whole runtime, you don't need cgroups either for a wasm process. Sandboxing becomes a purely user mode construct, no OS magic needed.
- pjmlp 5y ago
  He should have gone talk to Microsoft and learn about MSIL.
follower 5y ago
For me, the most interesting potential of WASM is it provides a platform-independent sandboxed way to run untrusted code written in multiple programming languages. This means it's in theory possible to run the same code on an embedded hardware platform, a desktop app or in the browser. And while I'm sure there's "serious" business uses for that capability :) I'm most interested in what it enables in terms of user customisation/modding of games. Which was my main motivation for creating a Wasmtime WASM runtime add-on for the Godot game engine: https://gitlab.com/RancidBacon/godot-wasm-engine https://gitlab.com/RancidBacon/godot-wasm-engine And also designing the "WebAssembly Calling Card" specification as a way of demonstrating how the same code could produce graphical output that is then used in 2D or 3D environments: https://wacc.rancidbacon.com https://wacc.rancidbacon.com
- jsd1982 5y ago
  This is exactly what I'm doing right now with SNES emulators, bsnes-plus specifically. The idea is to be able to extend certain games and give wasm module the ability to read/write the emulated memory and send/receive messages over a network connection to another process, among other things.
  - follower 5y ago
    Sounds cool! Do you have anywhere that interested people can read more about the project/progress?
    - jsd1982 5y ago
      Hm not really but I do update my repo on github.com. It's all work in progress stuff being designed as I go. https://github.com/alttpo/bsnes-plus/tree/wasm/bsnes/wasm https://github.com/alttpo/bsnes-plus/tree/wasm/bsnes/wasm
- still_grokking 5y ago
  > This means it's in theory possible to run the same code on an embedded hardware platform, a desktop app or in the browser. Maybe want to talk to the Java guys, and ask them why this doesn't work out in practice? ;-) Just having a common byte-code interpreter isn't enough for portability of applications.
tiew9Vii 5y ago
Think of WASM as a JVM alternative, but it has heavy sandboxing. By default, WASM is pure computing. It can't interact with the outside world. You need to allow WASM to talk to the outside world explicitly. You have native performance. It's fast. It's platform-independent, and multiple languages can compile to WASM. The properties lead to some useful applications. Serverless, FaaS. If you use WASM for Serverless you get very fast execution + cold starts. Cloudflare Workers can do 200ms cold starts and 20ms a request. Fastly Cloud@Edge not being a Chrome browser, but instead, its own runtime can do better and serve requests in 10ms. The low overhead and secure sandboxing means you can bin-pack these at a massive scale and call them with little overhead. It's much more efficient than Lambda etc. Cloudflare and Fastly as edge CDN providers allow you to deploy fast apps, globally distributed by default, piggyback off their existing caching functionality with no need for API gateways/complex plumbing etc. Fastly's C@E is especially interesting. Unfortunately, Fastly have failed to capitalise on it product-wise. As a product, Cloudflare is way ahead. The best tech doesn't win. I'm not disparaging Cloudflare here. I personally use Cloudflare over Fastly because, at this point, Cloudflare are a more complete product/ecosystem with superior pricing model. For serverless, it's early days but WASM/WASI will probably disrupt the current FaaS providers once the rough edges are worked out. I wish Fastly had a better product/business execution team to realise C@E properly. Outside of Serverless/FaaS it makes massive sense instead of people deploying full OS's in a Docker image on Kubernetes, instead deploy WASM modules. Wasmcloud (https://wasmcloud.dev/ https://wasmcloud.dev/) looks to be one of the first here running an actor system in Kuberenetes where the Actors are WASM apps. The other place where it has big potential is to be the Electron from hardware devices. Here's a talk for building a WebAssembly runtime for IPlayer https://www.youtube.com/watch?v=28paRXqI-Gk https://www.youtube.com/watch?v=28paRXqI-Gk . They essentially made the bulk of the logic/app in Webassembly then created small shims for different devices to load it. Webassembly allowed the hardware providers to offer a portable runtime that can execute 3rd party software in a restricted runtime. WebAssembly in the browser is the least exciting part about WebAssembly. I'm incredibly excited to see how it is used for Microservices and serverless.
- pjmlp 5y ago
  > By default, WASM is pure computing. It can't interact with the outside world. You need to allow WASM to talk to the outside world explicitly. That only applies to MVP 1.0, the long term roadmap hardly makes it any different from the myriad of other bytecode distribution formats.

lcnmrn 5y ago

WASM is to Node what C/C++ extensions are to Python.

deleted 5y ago
[deleted]
- deleted 5y ago
  [deleted]
ameliaquining 5y ago
That doesn't particularly sound right to me. Node also supports C/C++ extensions, and AFAICT the use of Wasm in Node for performance is still relatively uncommon.