Spin – WebAssembly Framework(fermyon.com)
fermyon.com
Spin – WebAssembly Framework
https://www.fermyon.com/blog/introducing-spin
75 comments
Heh, I've been working on something not that dissimilar from the C++ side in https://github.com/celtera/avendish (at compile time though, but I plan to target WASM so maybe some collaboration's possible) - https://vimeo.com/manage/videos/694659185 ; the definition of the UI widgets don't need to include any library and will be able to compile against Qt and others :)
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!
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)
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)
Enterprises were using (wasting) full ec2 instances long before Kubernetes came along. K8s can certainly be used to get more utilization on a small cluster -if that's something you value.
And that's just it, most companies I've seen are content to ship code and deployments that are poorly architected (for performance and efficiency) and poorly performing.
I saw the same thing when I worked in the energy space. Effort is only expended when the ROI is big enough to justify it. And sometimes not even then! It's kind of depressing.
I actually think that the silly high cost of cloud infra can help bring about an appreciation of leaner runtimes (Go, Rust, etc) especially with cheap edge computing (cloud flare workers). That's an uphill battle though.
That said, I can envision a leaner orchestration model ( leaner than k8s) that strongly encourages more efficient computing. I'm excited to see how WASM fits into this, it could be a game changing tool for simplification.
And that's just it, most companies I've seen are content to ship code and deployments that are poorly architected (for performance and efficiency) and poorly performing.
I saw the same thing when I worked in the energy space. Effort is only expended when the ROI is big enough to justify it. And sometimes not even then! It's kind of depressing.
I actually think that the silly high cost of cloud infra can help bring about an appreciation of leaner runtimes (Go, Rust, etc) especially with cheap edge computing (cloud flare workers). That's an uphill battle though.
That said, I can envision a leaner orchestration model ( leaner than k8s) that strongly encourages more efficient computing. I'm excited to see how WASM fits into this, it could be a game changing tool for simplification.
This is so true. I think this project feels like breathe of fresh air and also forced you to think different on how to go about building serverless stuff.
Someone mentioned about carbon footprint of increase due to containerization and the kubernetes culture during discussion about dagger [1]. Cloud cost, cloud waste and climate impact of current cloud computing setups are some biggest problem of this decade that are often ignored. I think webassembly and frameworks like these are the answer to that problem.
[1] https://news.ycombinator.com/item?id=30857012
Someone mentioned about carbon footprint of increase due to containerization and the kubernetes culture during discussion about dagger [1]. Cloud cost, cloud waste and climate impact of current cloud computing setups are some biggest problem of this decade that are often ignored. I think webassembly and frameworks like these are the answer to that problem.
[1] https://news.ycombinator.com/item?id=30857012
Hi! (Another one of the Spin authors here)
We have been talking about the efficiency/footprint thing a lot. So many things sit idle in the datacenter, consuming electricity without a good reason. WebAssembly is so fast to startup and shutdown that we think we can actually make a sizable dent into amount of compute required (and hence, amount of electricity consumed) if we can build this tooling right.
Spin took a first pass at this, but there is more we want to do to boost that efficiency even more! Hopefully in a few months I will be able to write a blog post with some progress on this.
We have been talking about the efficiency/footprint thing a lot. So many things sit idle in the datacenter, consuming electricity without a good reason. WebAssembly is so fast to startup and shutdown that we think we can actually make a sizable dent into amount of compute required (and hence, amount of electricity consumed) if we can build this tooling right.
Spin took a first pass at this, but there is more we want to do to boost that efficiency even more! Hopefully in a few months I will be able to write a blog post with some progress on this.
Looking forward to write up! Super excited about the project. We might actually end up using it.
You can run your own workloads really cheaply on a self-hosted Kubernetes cluster on a cheap provider like Hetzner or similar. Cloud being expensive is really just because AWS, Google, and Microsoft are milking the enterprise market. If you're a price sensitive cloud customer go somewhere else.
Cool project
> Github renders text files without line wrappings
Save it as .md not .txt and it should work
> Github renders text files without line wrappings
Save it as .md not .txt and it should work
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 and then you can just schedule a bunch of different wasm programs on a server no matter what language you wrote it in?
Is the workflow: Build app in rust, compile it down to WASM, and then run it on a server with wasmtime? I think I am missing some step.
Is the workflow: Build app in rust, compile it down to WASM, and then run it on a server with wasmtime? I think I am missing some step.
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
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
Thanks for the response. Lunatic seems like a really interesting piece of software. Allowing you to run anything that compiles down to wasm seems like an awesome opportunity for a platform to solve some of the headaches of current serverless setup.
But you can already do this with DLLs or with SOs files. You can keep your network logic for example inside another module (perhaps the host app) and then load the logic that acts on the received data as a dll.
Process separation and IPC natively using a library such as Qt is literally a few hundred lines of code.
Process separation and IPC natively using a library such as Qt is literally a few hundred lines of code.
I can't take a DLL and expect it to work on Linux/Mac. Wasm allows free sharing of portable binaries - with cross-language interop.
But that's sort of moving the goal posts now. Original claim for WASM was that it allows hot reloading. Which is a thing you can do with DLLs just fine.
No, the original claim of Wasm definitely isn't only one side point about development. The original claim of Wasm is that all of these features are packaged in a well thought out whole + the success of this platform (thanks to browsers mostly) is what's so interesting about it.
It is also hard to contain the DLL/SO, every system has different mechanisms to ensure it can not access 'everything'. Wasm, as build for the browser, has it in its DNA.
Could you explain more about how hot reload works? I don't see how you can continue from some arbitrary point in an HTTP request, for example, without having detailed knowledge about how a language stores its state in memory and how the code changed between versions.
(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!
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!
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.
so you're all building a JVM but hipster. Got it.
Sure, I suppose that's one way to put it. It has a lot of real, practical benefits over the JVM though (locked down by default, small surface area, simpler, buy in from major platforms, compilation target for multiple major languages), and this feels like a dismissal you could put on anything that follows in the footsteps of something else. One could dismiss Rust as hipster C++, but that wouldn't really engage with the issues of compile-time memory safety or concurrency or ADTs. Or JSON as the hipster XML! These are all true in a sense, but it doesn't address the actual advantages and disadvantages (both of which exist for all of these examples).
Sandboxing. The new way of doing containers.
I'd think of it as plugins everywhere, like L7 proxies [1]. The code for a network filter could be reloaded in the server upon detection to a configuration change. I believe the startup mad dash is on to capture who is going to run the container runtimes, and host the plugin repositories.
So my guess is that Fermyon Technologies with Spin could be looking to follow the Vercel with NextJS model where everything will be open source and runnable from the development runtime, but there eventually will be features like Edge Functions [2] in five years that will only be available when you deploy to their hosted service. They'll likely work towards that with web services with Spin [3] and CMS with Bartholomew [4] for starters. Instead of everything linked together in a NodeJS app directly, your code will run from a WASM library in a sandbox.
But my guess about the Vercel model could be slightly wrong after checking out their solid founding team [5] -- the bios emphasize the WASM and Kubernetes worlds. The problem if it is something like the Docker model is that the standard will just be made with the big players like OpenContainer [6] and the enterprise business sold off [7], and/or folded into one of the cloud infra players (with the data centers).
[1] https://github.com/proxy-wasm/spec
[2] https://vercel.com/docs/concepts/functions/edge-functions
[3] https://spin.fermyon.dev/
[4] https://github.com/fermyon/bartholomew
[5] https://www.fermyon.com/about
[6] https://opencontainers.org
[7] https://www.mirantis.com/blog/mirantis-acquires-docker-enter...
I'd think of it as plugins everywhere, like L7 proxies [1]. The code for a network filter could be reloaded in the server upon detection to a configuration change. I believe the startup mad dash is on to capture who is going to run the container runtimes, and host the plugin repositories.
So my guess is that Fermyon Technologies with Spin could be looking to follow the Vercel with NextJS model where everything will be open source and runnable from the development runtime, but there eventually will be features like Edge Functions [2] in five years that will only be available when you deploy to their hosted service. They'll likely work towards that with web services with Spin [3] and CMS with Bartholomew [4] for starters. Instead of everything linked together in a NodeJS app directly, your code will run from a WASM library in a sandbox.
But my guess about the Vercel model could be slightly wrong after checking out their solid founding team [5] -- the bios emphasize the WASM and Kubernetes worlds. The problem if it is something like the Docker model is that the standard will just be made with the big players like OpenContainer [6] and the enterprise business sold off [7], and/or folded into one of the cloud infra players (with the data centers).
[1] https://github.com/proxy-wasm/spec
[2] https://vercel.com/docs/concepts/functions/edge-functions
[3] https://spin.fermyon.dev/
[4] https://github.com/fermyon/bartholomew
[5] https://www.fermyon.com/about
[6] https://opencontainers.org
[7] https://www.mirantis.com/blog/mirantis-acquires-docker-enter...
It is more like, container folks rediscovered what we were doing with app servers.
To be fair I don't think this is really the same - if I understand correctly, app servers were always a poor approximation for actual co tainers.
Browser containers may be better, but you share the same problem with app containers that you share physical memory and a kernel space.
Same type of challenges though, yes. Just a brand "new" secure sticker on the front, whatever that's actually worth.
Browser containers may be better, but you share the same problem with app containers that you share physical memory and a kernel space.
Same type of challenges though, yes. Just a brand "new" secure sticker on the front, whatever that's actually worth.
I have a demo Spin application running on a small VPS [1] and the performance is amazing. It boggles the mind that the server is loading the WASM, instantiating a runtime, parsing markdown, applying templates, etc. all in just a few milliseconds. You can see the source for the blog [2], and the original blog engine Bartholomew [3] that it's based on.
Note this is a toy deployment, not actual content. Don't expect all the links to work or any content to be accurate or relevant :)
[1] https://spin.brian.dev/blog/2022-03-18-caddy-zero-downtime [2] https://github.com/bketelsen/wasmblog [3] https://github.com/fermyon/bartholomew
Note this is a toy deployment, not actual content. Don't expect all the links to work or any content to be accurate or relevant :)
[1] https://spin.brian.dev/blog/2022-03-18-caddy-zero-downtime [2] https://github.com/bketelsen/wasmblog [3] https://github.com/fermyon/bartholomew
(one of the Spin authors here.)
This is so cool! The Spin documentation website (https://spin.fermyon.dev) is also served by Spin itself, running on a Nomad cluster, with the same blogging engine mentioned here.
We're really looking forward to improving the rolling deployments, but it's really great seeing something like this live!
This is so cool! The Spin documentation website (https://spin.fermyon.dev) is also served by Spin itself, running on a Nomad cluster, with the same blogging engine mentioned here.
We're really looking forward to improving the rolling deployments, but it's really great seeing something like this live!
I've been excited about WebAssembly being a new back-end target when someone on HN (I forgot whom) pointed out, hey dont be fooled by the name, it's not just for browsers. I know some people will cry that it is just Java in the browser or whatever, but it really is much more than that. It is way more secure, far more minimal, and people can build their own run times for it. I am excited to see where WASI goes moving forward, I also like the idea of WAGI, which I really hope is being designed to match similar efforts in other languages such as WSGI, and ASGI.
When I first wrote WAGI, I just wanted to show people that WebAssembly could be run efficiently on the server. Basically, like you were saying, I wanted something to demo to people and say, "Look, Wasm can do a lot more than crypto-mine in a browser tab!"
Now with Spin we are able to go beyond those first assumptions made with Wagi and explore exactly how far we can push it. It has been so much fun to explore how to have a Wasm module handle Redis events, or try out Python on Wasm for the very first time, or build a little CMS in Wasm... it feels like the early days of Docker all over again!
Now with Spin we are able to go beyond those first assumptions made with Wagi and explore exactly how far we can push it. It has been so much fun to explore how to have a Wasm module handle Redis events, or try out Python on Wasm for the very first time, or build a little CMS in Wasm... it feels like the early days of Docker all over again!
Thank you for doing this, I’m excited for WASM on the backend but not a lot of bandwidth a lot of my other projects take higher priority atm. I would love to someday see if someone can make a WASM backend for Erlang with support for Erlang features. Would be interesting to give devs from any background indirect access to Erlang via WASM.
I applaud their effort on this! It's great to see push from more companies of WebAssembly on the server-side (disclaimer, I work at Wasmer).
I have one nit about the article though. I think I haven't seen the claimed support for the Component Model anywhere in the code (other than naming the Wasm modules components), as its mainly based on the extent of WebAssembly Interface Types (WIT). Could anyone from the team give more info on where the Component Model proposal is actually used?
I have one nit about the article though. I think I haven't seen the claimed support for the Component Model anywhere in the code (other than naming the Wasm modules components), as its mainly based on the extent of WebAssembly Interface Types (WIT). Could anyone from the team give more info on where the Component Model proposal is actually used?
Hi, and thanks for your comment!
(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!
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!
This blog post is enjoyable to read. It's a clear and friendly without trying the sell the idea too hard. It respects the reader's capability to understand and evaluate the thing by themselves and makes a good effort build up the required knowledge. Also I like the design. Kudos!
After working on a microservices framework I've opinions about frameworks but one thing that caught my attention is the shifting of outbound network calls [security responsibility] from firewalls to the [application] runtime.......driven by a config file. It'd be interesting to hear from some security engineers here -- there will likely have to be some tooling written for them, etc., but this is one of the more interesting things about spin/WASM.
I wonder how this will scale to large apps -- assumning thats one of the goals...if the target is just some kinda serverless cruft then maaaybe that can work, but I can already foresee a small config template hell unravelling in front of my eyes.
I might be missing something fundamental here, so take what I said with a pinch of salt.
I wonder how this will scale to large apps -- assumning thats one of the goals...if the target is just some kinda serverless cruft then maaaybe that can work, but I can already foresee a small config template hell unravelling in front of my eyes.
I might be missing something fundamental here, so take what I said with a pinch of salt.
(one of the Spin authors here.)
This is not shifting the security responsibility from the firewall entirely — it's just an additional guard rail to ensure only allowed domains can be accessed. It does not mean setting proper firewall rules is no longer a concern, but just continuing WebAssembly's "deny by default" stance on accessing anything outside the sandbox.
We have not explored exactly how large scale apps will look like with Spin and WebAssembly — our initial target, at least in the beginning, is making sure building and running function-as-a-service(-like) applications is a great experience.
That's a great call-out regarding configuration and templates — we do have previous experience with "config template hell" from working in Kubernetes, Helm, CNAB, and other distributed systems platforms, so hopefully we can try to make things better!
This is not shifting the security responsibility from the firewall entirely — it's just an additional guard rail to ensure only allowed domains can be accessed. It does not mean setting proper firewall rules is no longer a concern, but just continuing WebAssembly's "deny by default" stance on accessing anything outside the sandbox.
We have not explored exactly how large scale apps will look like with Spin and WebAssembly — our initial target, at least in the beginning, is making sure building and running function-as-a-service(-like) applications is a great experience.
That's a great call-out regarding configuration and templates — we do have previous experience with "config template hell" from working in Kubernetes, Helm, CNAB, and other distributed systems platforms, so hopefully we can try to make things better!
> This is not shifting the security responsibility from the firewall entirely — it's just an additional guard rail to ensure only allowed domains can be accessed. It does not mean setting proper firewall rules is no longer a concern, but just continuing WebAssembly's "deny by default" stance on accessing anything outside the sandbox.
Yes, "shifting" was a terrible choice of words on my side, sorry about that :)W hat I meant was, it gives developers more ways to manage outbound traffic -- which is both great but I wonder how the intersection of Ops and Devs handle this going forward because these things often become contention points at organizations (remember the enterprise proxies, etc.); let's see how this all plays out, but I'm glad devs now have more ways to [express and] manage these aspects of their apps.
Yes, "shifting" was a terrible choice of words on my side, sorry about that :)W hat I meant was, it gives developers more ways to manage outbound traffic -- which is both great but I wonder how the intersection of Ops and Devs handle this going forward because these things often become contention points at organizations (remember the enterprise proxies, etc.); let's see how this all plays out, but I'm glad devs now have more ways to [express and] manage these aspects of their apps.
Web apps always had a chance to decide who to talk to.
This is trivial when they are clients of some other APIs, so about server side choices:
- domains, if reverse proxies / firewalls give them the IP of the client
- routes, by servicing the good URIs and 404 the bad ones (attacks more than honest mistakes)
- users, with many different authentication systems
- data, with validations.
The former points are traditionally more in the domain of the network infrastructure, the latter ones are for the application. I've seen all the possible combinations in the last 30 years.
This is trivial when they are clients of some other APIs, so about server side choices:
- domains, if reverse proxies / firewalls give them the IP of the client
- routes, by servicing the good URIs and 404 the bad ones (attacks more than honest mistakes)
- users, with many different authentication systems
- data, with validations.
The former points are traditionally more in the domain of the network infrastructure, the latter ones are for the application. I've seen all the possible combinations in the last 30 years.
It's not super clear, but it looks like Fermyon was started by people formerly at DeisLabs, which has done quite a bit of wasm work. It looks quite promising, even more so considering the lineage and expertise of the team.
Thanks for your comment!
(one of the authors of Spin here, working at Fermyon.)
You are correct, a lot of our team worked in the DeisLabs R&D team at Microsoft before joining Fermyon!
You are correct, a lot of our team worked in the DeisLabs R&D team at Microsoft before joining Fermyon!
I'm not too familiar with WebAssembly but I like the concept of compiling different source languages to a common "bytecode" language so it can run on various platforms.
However, with the way things are currently going, are we using WebAssembly to reinvent the concept of Java applets? It all sounds very familiar. And if this is the case, will it run into similar problems?
However, with the way things are currently going, are we using WebAssembly to reinvent the concept of Java applets? It all sounds very familiar. And if this is the case, will it run into similar problems?
(one of the authors of Spin here, and a WebAssembly enthusiast.)
There are, of course, a lot of similarities between the Java or .NET runtimes and WebAssembly, and other comments made excellent points about the lower level nature of Wasm, or the isolation sandbox.
I would also point out that there are significantly more languages that either have support for compiling to WebAssembly today, or that have started adding support (in the last month alone there were initial announcements for Python, Ruby, and .NET, for example).
There are, of course, a lot of similarities between the Java or .NET runtimes and WebAssembly, and other comments made excellent points about the lower level nature of Wasm, or the isolation sandbox.
I would also point out that there are significantly more languages that either have support for compiling to WebAssembly today, or that have started adding support (in the last month alone there were initial announcements for Python, Ruby, and .NET, for example).
It's much lower level and has a robust sandboxing model, so the security issues with Java are not really a concern here. There are still security risks but they're different ones and generally less severe.
Because it's lower level it's a more viable compile target for things that couldn't easily be compiled to Java, like C++ for example.
Because it's lower level it's a more viable compile target for things that couldn't easily be compiled to Java, like C++ for example.
Yeah like other snide comments mention - not sure this is that useful or something we really want.
Like, I get the company wanting to sell services to people who might do wasm stuff, the whole quip about cross platform CLI? I don't think devs care, we have multiple tools for that already, thanks, generally I dont think CLIs are selling points to the "end user". If they are, small niche market with crossover with said devs.
The rest of it, been there done that, JVM, JavaBeans. The point of wasm was to allow better browser experiences, not build components in another esoteric runtime. In this regard Wasm is no different than any other scripting language, and this product is another dime a dozen 'enterprise offering', with all the usual pitfall that comes with. "Developers aren't Operators"? Ugh. "We want to chain you to your desk and churn out crappy feature after feature onto our already unmaintainable pile of slop"
Dislike.
Like, I get the company wanting to sell services to people who might do wasm stuff, the whole quip about cross platform CLI? I don't think devs care, we have multiple tools for that already, thanks, generally I dont think CLIs are selling points to the "end user". If they are, small niche market with crossover with said devs.
The rest of it, been there done that, JVM, JavaBeans. The point of wasm was to allow better browser experiences, not build components in another esoteric runtime. In this regard Wasm is no different than any other scripting language, and this product is another dime a dozen 'enterprise offering', with all the usual pitfall that comes with. "Developers aren't Operators"? Ugh. "We want to chain you to your desk and churn out crappy feature after feature onto our already unmaintainable pile of slop"
Dislike.
Enterprise WASM beans ???
And history repeats.
And history repeats.
(One of the Spin authors here)
In all honesty, I think many of the concepts that we saw in early Java deserve to get another chance in a more language-agnostic ecosystem. I never did a lot of EJB, but CORBA/DCOM are definitely part of the inspiration for what Bytecode Alliance is doing with WebAssembly components.
Java sometimes gets a bad wrap (and so does .NET). Both ecosystems are full of amazing tooling and well-thought-out concepts. I think it's a great idea to look through these landscapes and ask, "Would these features be good additions to the WebAssembly ecosystem?"
In all honesty, I think many of the concepts that we saw in early Java deserve to get another chance in a more language-agnostic ecosystem. I never did a lot of EJB, but CORBA/DCOM are definitely part of the inspiration for what Bytecode Alliance is doing with WebAssembly components.
Java sometimes gets a bad wrap (and so does .NET). Both ecosystems are full of amazing tooling and well-thought-out concepts. I think it's a great idea to look through these landscapes and ask, "Would these features be good additions to the WebAssembly ecosystem?"
So, if I understood correctly the main benefit of using this on server-side would be that its an easier alternative to Docker for achieving sandboxing.
This may or may not be an issue since they operate on different niches, but spin (and recently spin2) are languages used to program parallax propeller microcontrollers: https://www.parallax.com/propeller/qna/Content/QnaTopics/Qna...
SPIN is also a model checker.
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.
I don't remember how I came up with the name - perhaps the "in" was for interface.
Webassembly is growing fast. Do you think running a Java Swing application is going to be possible in the near future on Wasm in a browser?
(one of the Spin authors here.)
I'm not all that familiar with the Java ecosystem, but I seem to recall the CheerpJ people having examples for running Swing applications in the browser. (I don't know much about how their solution works, or whether it's open source.)
https://cheerpjdemos.leaningtech.com/SwingDemo.html
I'm not all that familiar with the Java ecosystem, but I seem to recall the CheerpJ people having examples for running Swing applications in the browser. (I don't know much about how their solution works, or whether it's open source.)
https://cheerpjdemos.leaningtech.com/SwingDemo.html
Do you offer any hosted services? Spin looks amazing but I don't want to manage my own server.
I'm part of Fermyon (the company that created Spin), and we are definitely talking about this. There's a news signup at Fermyon.com (right at the top-right) that you can sign up for if you'd like to get early news about that. And for sure, if you have specific things you'd like to see in a hosted platform, I'd love to hear about it.
Does WASM have the ability to interact directly with the DOM now or is that still in development?
Genuinely curious: why would you want to access the DOM with wasm? Can't we finally let html be for documents and wasm be for applications? The pain of shoe-horning applications into the DOM is not going to end because wasm has access to it. This also seems like a classic way to have the entire industry misunderstand a technology, misapply it, and again, continue the pain of building applications on top of html with JavaScript/wasm.
Sorry for that rant, but I went into panic mode when I saw your question.
It reminds me of how everyone misunderstood smalltalk/OOP because they saw on it in terms of the existing paradigm. The misunderstanding pretty much cut us off from the real benefits of the idea because we got distracted writing classes and abstractions instead of passing around code with data across the network.
Maybe I'm off base here but my fear is that people see wasm new/cool/shiney and use it instead of JavaScript, and in the ensuing hype we lose the most valuable aspects of the technology (as partially demonstrated by Spin).
Sorry for that rant, but I went into panic mode when I saw your question.
It reminds me of how everyone misunderstood smalltalk/OOP because they saw on it in terms of the existing paradigm. The misunderstanding pretty much cut us off from the real benefits of the idea because we got distracted writing classes and abstractions instead of passing around code with data across the network.
Maybe I'm off base here but my fear is that people see wasm new/cool/shiney and use it instead of JavaScript, and in the ensuing hype we lose the most valuable aspects of the technology (as partially demonstrated by Spin).
That's fine, I use Flutter which eschews the DOM and uses the canvas to build applications, but people don't seem to like that very much since it's not as introspectable as HTML, CSS and JS. So if WASM had DOM access, people could build their apps on whatever language they wanted to, that would compile to WASM which would then manipulate the DOM. That way people don't have to use JS. If WASM couldn't manipulate the DOM, then that's also fine, it'd just have to manipulate a canvas element or something similar like Flutter and Skia does.
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...
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!
what are the benchmarks?
(one of the authors of Spin here.)
WIth the disclaimer that this is really early, and we don't have extensive benchmarks yet, there are a few things we are tracking for HTTP workloads (you can see the actual benchmark apps here — https://github.com/fermyon/spin/tree/main/crates/http/benche..., and the rendered results here — https://fermyon.github.io/spin-benchmarks/criterion/reports/):
- the response times — here are some benchmarks for requests that simulate 1 ms of work — https://fermyon.github.io/spin-benchmarks/criterion/reports/...
- the "cold" startup time — https://fermyon.github.io/spin-benchmarks/criterion/reports/...
Another disclaimer is that we have not focused on optimization work at all, so we expect to make significant improvements over the next few months.
WIth the disclaimer that this is really early, and we don't have extensive benchmarks yet, there are a few things we are tracking for HTTP workloads (you can see the actual benchmark apps here — https://github.com/fermyon/spin/tree/main/crates/http/benche..., and the rendered results here — https://fermyon.github.io/spin-benchmarks/criterion/reports/):
- the response times — here are some benchmarks for requests that simulate 1 ms of work — https://fermyon.github.io/spin-benchmarks/criterion/reports/...
- the "cold" startup time — https://fermyon.github.io/spin-benchmarks/criterion/reports/...
Another disclaimer is that we have not focused on optimization work at all, so we expect to make significant improvements over the next few months.
(Another Fermyon person here)
On a lighthearted unscientific note: After getting absolutely bombarded with traffic today (5-10x normal, YAY!), we noticed: - No increased latency in responding to requests - Flat memory usage at 130MB per worker (we run Nomad) - Spiky CPU traffic (which is expected when starting and stopping Wasm modules hundreds of times a second), but never really over about 60% of the CPU on a small VM size on AWS - No Wasm downtime (though we did have a non-Wasm load balancer hiccup at about peak load, cause unknown)
On a lighthearted unscientific note: After getting absolutely bombarded with traffic today (5-10x normal, YAY!), we noticed: - No increased latency in responding to requests - Flat memory usage at 130MB per worker (we run Nomad) - Spiky CPU traffic (which is expected when starting and stopping Wasm modules hundreds of times a second), but never really over about 60% of the CPU on a small VM size on AWS - No Wasm downtime (though we did have a non-Wasm load balancer hiccup at about peak load, cause unknown)
We went full circle... microservices in web assembly.... one of the worst idea of this decade
Hi! (one of the authors of Spin here)
Interesting to hear your thoughts on this, why do you think that?
We believe that the things that make WebAssembly attractive in the browser (compact binary, near-native speed, the sandbox isolation model) make it really compelling outside the browser, on the server.
We believe that the things that make WebAssembly attractive in the browser (compact binary, near-native speed, the sandbox isolation model) make it really compelling outside the browser, on the server.
I think while it is a good idea, more acknolwedgement to previous work should be considered,
> More than 20 programming tools vendors offer some 26 programming languages — including C++, Perl, Python, Java, COBOL, RPG and Haskell — on .NET.
From https://news.microsoft.com/2001/10/22/massive-industry-and-d...
> It has frontends for the following programming languages: C, Pascal, Modula-2, Occam, and BASIC.
> Maximum portability is achieved by using an intermediate language using bytecode, called EM. Each language front-end produces EM object files, which are then processed through several generic optimisers before being translated by a back-end into native machine code.
From https://en.wikipedia.org/wiki/Amsterdam_Compiler_Kit
> The hardware isolation provided by the TIMI allowed IBM to replace the AS/400's 48-bit IMPI architecture with the 64-bit RS64 architecture in 1995. Applications compiled on systems using the IMPI instruction set could run on top of the newer RS64 systems without any code changes, recompilation or emulation, while also allowing those applications to avail of 64-bit addressing
From https://en.wikipedia.org/wiki/IBM_i#TIMI
> More than 20 programming tools vendors offer some 26 programming languages — including C++, Perl, Python, Java, COBOL, RPG and Haskell — on .NET.
From https://news.microsoft.com/2001/10/22/massive-industry-and-d...
> It has frontends for the following programming languages: C, Pascal, Modula-2, Occam, and BASIC.
> Maximum portability is achieved by using an intermediate language using bytecode, called EM. Each language front-end produces EM object files, which are then processed through several generic optimisers before being translated by a back-end into native machine code.
From https://en.wikipedia.org/wiki/Amsterdam_Compiler_Kit
> The hardware isolation provided by the TIMI allowed IBM to replace the AS/400's 48-bit IMPI architecture with the 64-bit RS64 architecture in 1995. Applications compiled on systems using the IMPI instruction set could run on top of the newer RS64 systems without any code changes, recompilation or emulation, while also allowing those applications to avail of 64-bit addressing
From https://en.wikipedia.org/wiki/IBM_i#TIMI
(one of the authors of Spin here.)
I think this is an excellent point — while we do try to give acknowledgement to the previous technology that paved the way for what we are doing (there are a few articles that treat microservices, containers, serverless https://fermyon.com/blog/index), I agree that we could do a better job at talking about programming languages and language runtimes.
Thanks for the suggestion!
I think this is an excellent point — while we do try to give acknowledgement to the previous technology that paved the way for what we are doing (there are a few articles that treat microservices, containers, serverless https://fermyon.com/blog/index), I agree that we could do a better job at talking about programming languages and language runtimes.
Thanks for the suggestion!
How so? I think WASM has major benefits for specific applications, especially for sandboxing, and running things in a cross-platform way. As far as I can tell, it's not that different from what Java and C# do (compile to your own bytecode, run that in a VM), except that you only give it access to specific functions.
While it might be slightly slower than running native code, I think that for certain users those are benefits that they can't overlook.
While it might be slightly slower than running native code, I think that for certain users those are benefits that they can't overlook.
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.
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.
WebAssembly co-developed by " W3C; Mozilla; Microsoft; Google; Apple" and unless they put the people to develop it further, it stays at it is.
And I wouldn't be surprised if some of those companies wouldn't be feeling like patent ways to compile and optized WebAssembly into native code, or anything else related to tooling.
And I wouldn't be surprised if some of those companies wouldn't be feeling like patent ways to compile and optized WebAssembly into native code, or anything else related to tooling.
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 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
Github renders text files without line wrappings, so here's the raw link: https://raw.githubusercontent.com/joelewis/kwasm/master/note...