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.
Spin – WebAssembly Framework
61–70 of 76 posts
Re: Spin – WebAssembly Framework
#62Earlier quoted context omitted.
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.
Re: Spin – WebAssembly Framework
#63I 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 mach…
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.
Re: Spin – WebAssembly Framework
#64Earlier quoted context omitted.
(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…
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).
Re: Spin – WebAssembly Framework
#65Do you offer any hosted services? Spin looks amazing but I don't want to manage my own server.
Re: Spin – WebAssembly Framework
#66Does 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).
Re: Spin – WebAssembly Framework
#67Does 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…
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.
Re: Spin – WebAssembly Framework
#68Earlier quoted context omitted.
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…
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…
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.
Re: Spin – WebAssembly Framework
#69I'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…
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!
Re: Spin – WebAssembly Framework
#70Enterprise WASM beans ??? 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?"