Our great sponsors
-
spin
Spin is the open source developer tool for building and running serverless applications powered by WebAssembly.
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
(one of the authors of Spin here.)
First, both Spin and the component model are in their early stages, but there are a few things I'd mention here:
- as you correctly pointed out, all "trigger" interfaces are based on WIT (https://github.com/bytecodealliance/wit-bindgen/blob/main/WI...), the new WebAssembly interface format, so a) building a WebAssembly binary that implements a trigger interface can be done pretty easily in languages with bindgen support, and b) extending Spin with a new trigger type can also be done by starting with the WIT interface (really early on this topic, but here's an example — https://spin.fermyon.dev/extending-and-embedding/)
- we want to add support for defining component dependencies, and dynamically linking them at runtime based on the environment.
- all "platform features" we want want to add to Spin will be initially based on host implementations for WebAssembly interfaces (you can see an early example of this in this PR — https://github.com/fermyon/spin/pull/165)
- we are closely following the tooling in the component model (https://github.com/bytecodealliance/wit-bindgen/pull/183) and will add support for natively executing actual components once that is available upstream.
Hope this is helpful!
3. A platform specific embedder can then write a tiny layer of renderer that translates commands from the WebAssmelby VM into native UI updates.
This way we can liberate UI programming from being too close to a platform and possibly could run on servers (damn fast SSR)
I'm attempting a proof of concept and I've logged my thoughts as I'm working through the project - https://github.com/joelewis/kwasm/blob/master/notes.txt
(one of the authors of Spin here.)
First, both Spin and the component model are in their early stages, but there are a few things I'd mention here:
- as you correctly pointed out, all "trigger" interfaces are based on WIT (https://github.com/bytecodealliance/wit-bindgen/blob/main/WI...), the new WebAssembly interface format, so a) building a WebAssembly binary that implements a trigger interface can be done pretty easily in languages with bindgen support, and b) extending Spin with a new trigger type can also be done by starting with the WIT interface (really early on this topic, but here's an example — https://spin.fermyon.dev/extending-and-embedding/)
- we want to add support for defining component dependencies, and dynamically linking them at runtime based on the environment.
- all "platform features" we want want to add to Spin will be initially based on host implementations for WebAssembly interfaces (you can see an early example of this in this PR — https://github.com/fermyon/spin/pull/165)
- we are closely following the tooling in the component model (https://github.com/bytecodealliance/wit-bindgen/pull/183) and will add support for natively executing actual components once that is available upstream.
Hope this is helpful!
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
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
