Spin – WebAssembly Framework
21–30 of 76 posts
Re: Spin – WebAssembly Framework
#22I am sure this has been answered before, but a quick google search didn't really clear this up for me but... I don't quite understand the usage of WASM on the server side (not denigrating, just looking for an explanation). If you are using rust, can't you just compile it down to a binary and run that on your server? Or is the main advantage the sandboxing? Or is the idea you have a bunch of wasm compatible servers an…
Your intuition is mostly correct. Before anything, I strongly suggest you read this article on server-side WebAssembly — https://hacks.mozilla.org/2019/11/announcing-the-bytecode-al...
In short, when compiling to Wasm, you are building a binary that is agnostic of the operating system and CPU architecture it is going to run on, so it can be executed in lots of very different places (microcontrollers, Raspbery Pis, in the cloud). You can also use several VERY different programming languages, and interoperate between them (write a component in Rust, import it in a new component in JavaScript, and use those two from C# — this is an example for how the component model will (hopefully soon) enable cross-langauge interop in WebAssembly).
Among other benefits, the compact binary format (which makes it easy to distribute modules), the isolation sandbox, common compilation target.
Hope this is helpful!
Re: Spin – WebAssembly Framework
#23I don't remember how I came up with the name - perhaps the "in" was for interface.
Re: Spin – WebAssembly Framework
#24We went full circle... microservices in web assembly.... one of the worst idea of this decade
People bashed Java and .NET Application Servers, it turns out they actually had some cool ideas in them. Naturally now they have to be packaged and sold as a new revolutionary idea for the newer generations.
Re: Spin – WebAssembly Framework
#25I am sure this has been answered before, but a quick google search didn't really clear this up for me but... I don't quite understand the usage of WASM on the server side (not denigrating, just looking for an explanation). If you are using rust, can't you just compile it down to a binary and run that on your server? Or is the main advantage the sandboxing? Or is the idea you have a bunch of wasm compatible servers an…
(one of the authors of Spin here.) Your intuition is mostly correct. Before anything, I strongly suggest you read this article on server-side WebAssembly — https://hacks.mozilla.org/2019/11/announcing-the-bytecode-al... In short, when compiling to Wasm, you are building a binary that is agnostic of the operating system and CPU architecture it is going to run on, so it can be executed in lots of very different places…
Re: Spin – WebAssembly Framework
#26Does WASM have the ability to interact directly with the DOM now or is that still in development?
https://github.com/WebAssembly/interface-types/blob/main/pro...
Re: Spin – WebAssembly Framework
#27Does WASM have the ability to interact directly with the DOM now or is that still in development?
As I understand it, WASM needs to have some kind of way to universally describe high-level types before it's able to have DOM support. There's currently a proposal for that, but it's not yet in the core spec. https://github.com/WebAssembly/interface-types/blob/main/pro...
Re: Spin – WebAssembly Framework
#28Earlier quoted context omitted.
As I understand it, WASM needs to have some kind of way to universally describe high-level types before it's able to have DOM support. There's currently a proposal for that, but it's not yet in the core spec. https://github.com/WebAssembly/interface-types/blob/main/pro...
The Interface Types and Module Linking proposals were recently superseded by the Component Model proposal, which unifies the two: https://github.com/WebAssembly/component-model
Re: Spin – WebAssembly Framework
#29This looks promising. I'm amazed at the kinds of places WebAssembly has found its way into. I myself am working on putting WebAssembly as a UI reconciliation engine. 1. You write your UI component spec (similar to React) in a language of your choice. 2. This compiles down to a WASM module, that knows how your state interplays with your UI tree. 3. A platform specific embedder can then write a tiny layer of renderer t…
Hi! (one of the authors of Spin here.) As you can assume, we are just as excited about all the places where we can run WebAssembly! That's a pretty intriguing idea, looking forward to seeing it evolve!
I see Spin as a small step towards that future of affordable cloud computing. Here's a twitter rant I wrote about the current state of affairs - https://twitter.com/vettijoe/status/1484507483788161026 (warning: Strong opinions ahead)
Re: Spin – WebAssembly Framework
#30I am sure this has been answered before, but a quick google search didn't really clear this up for me but... I don't quite understand the usage of WASM on the server side (not denigrating, just looking for an explanation). If you are using rust, can't you just compile it down to a binary and run that on your server? Or is the main advantage the sandboxing? Or is the idea you have a bunch of wasm compatible servers an…
Having an in-between bytecode layer allows you to build application architectures in rust that would not be possible when compiling directly to machine code. Hot reloading is a good example. Having the VM hold onto resources like tcp streams and file descriptors allows you to exchange the business logic without even breaking a tcp connection. Fine-grained sandboxing is another good example. Revoking filesystem access from just parts of your applications or limiting memory/cpu usage for each individual request[1] is something that is just impossible to do correctly without a vm managing it.
A less obvious benefit are the improvements to the developer experience, like compile times. Most of the dependencies (async executor, tcp stack, message passing, ...) are usually already part of the wasm runtime and don't need to be compiled/linked again. The rust compiler also seems to have a better time when it comes to generating .wasm executables instead of native ones. Most rust wasm apps I write compile much faster than equivalent native ones. Just because there is so much less for the compiler to do.
Many wasm runtimes, like lunatic, include an async scheduler and green threads/processes. This means that you get most of the benefits of async rust without needing to actually use async and worry about all the issues that come with it[2].
[0]: https://github.com/lunatic-solutions/lunatic
[1]: https://www.youtube.com/watch?v=8gwSU3oaMV8&list=PLdo4fOcmZ0...