Live data from Hacker News

Spin – WebAssembly Framework

fermyon.com

21–30 of 76 posts

Re: Spin – WebAssembly Framework

#22

I 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 (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

#23
Heh, in 2017 I was writing a C++ framework to use with my custom Wasm runtime (Gate). It was also called Spin. However, I abandoned the work as Rust's Wasm support improved.

I don't remember how I came up with the name - perhaps the "in" was for interface.

Re: Spin – WebAssembly Framework

#24
post #11

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

Since no company owns WebAssembly I'd call this repackaging a win.

Re: Spin – WebAssembly Framework

#25

I 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…

Ah that makes a lot of sense! I wasn't connecting the dots with the language interop. That seems very cool. Thanks for the explanation.

Re: Spin – WebAssembly Framework

#26

Does 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

#27

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

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

#28

Earlier 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

Brilliant, thanks for the link!

Re: Spin – WebAssembly Framework

#29
post #2

This 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!

Thanks, and I'm really rooting for Spin's success. The cloud computing costs have reached ridiculous levels recently. I blame the new age DevOps culture trained to hit every nail with Kubernetes ecosystem for this inflation. I believe WebAssembly could be the liberating weapon against these rising infra costs.

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

#30

I 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…

I'm the author of a Wasm on the server side runtime[0] that focuses primarily on rust compiled to Wasm, and this question comes up quite often. Why compile to Wasm if you can compile to native code directly? To add to Radu's answer, here are some of my favourite reasons.

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

[2]: https://eta.st/2021/03/08/async-rust-2.html

Post reply on HN