WASM will replace containers
370 comments
·February 12, 2025not2b
josephg
True, but I suspect it'll be a lot easier to virtualise all those APIs through WASM than it is for a regular native binary. I mean, half the point of docker is that all syscalls are routed into an LXD container with its own filesystem and network. It should be pretty easy to do the same thing in userland with a wasm runtime.
And the nice thing about that is you can pick which environment a wasm bundle runs in. Want to run it on the browser? Sure! Want to give it r/w access to some particular path? Fine! Or you want to run it "natively", with full access to the host operating system? That can work too!
We just ("just") need wasi, and a good set of implementations which support all the different kinds of sandboxing that people want, and allow wasm containers to talk to each other in all the desirable ways. Make no mistake - this is a serious amount of work. But it looks like a very solvable problem.
I think the bigger adoption problem will be all the performance you leave on the table by using wasm instead of native code. For all its flaws, docker on linux runs native binaries at native speed. I suspect big companies running big cloud deployments will stick with docker because it runs code faster.
quesomaster9000
As somebody who's in the process of building a sandbox for RISC-V 64 Linux ELF executables, even I'm still on the fence.
The problem is that in WASM-land we're heading towards WASI and WAT components, which is similar to the .NET, COM & IDL ecosystems. While this is actually really cool in terms of component and interface discovery, the downside is that it means you have to re-invent the world to work with this flavor of runtime.
Meaning... no, I can't really just output WASM from Go or Rust and it'll work, there's more to it, much more to it.
With a RISC-V userland emulator I could compile that to WASM to run normal binaries in the browser, and provide a sandboxed syscall interface (or even just pass-through the syscalls to the host, like qemu-user does when running natively). Meaning I have high compatibility with most of the Linux userland within a few weeks of development effort.
But yes, threads, forking, sockets, lots of edge cases - it's difficult to provide a minimal spoof of a Linux userland that's convincing enough that you can do interesting enough things, but surprisingly it's not too difficult - and with that you get Go, Rust, Zig, C++, C, D etc. and all the native tooling that you'd expect (e.g. it's quite easy to write a gdbserver compatible interface, but ... you usually don't need it, as you can just run & debug locally then cross-compile).
hardwaresofton
> The problem is that in WASM-land we're heading towards WASI and WAT components, which is similar to the .NET, COM & IDL ecosystems. While this is actually really cool in terms of component and interface discovery, the downside is that it means you have to re-invent the world to work with this flavor of runtime.
At the application level, you're generally going to write to the standards + your embedding. Companies that write embeddings are encouraced/incentivized to write good abstractions that work with standards to reduce user friction.
For example, for making HTTP requests and responding to HTTP requests, there is WASI HTTP:
https://github.com/WebAssembly/wasi-http
It's written in a way that is robust enough to handle most use cases without much loss of efficiency. There are a few inefficiencies in the WIT contracts (that will go away soon, as async lands in p3), but it represents a near-ideal representation of a HTTP request and is easy for many vendors to build on/against.
As far as rewriting the world, this happens to luckily not be quite true, thanks to projects like wasi-libc:
https://github.com/webassembly/wasi-libc
Networking is actually much more solved in WASI now than it was roughly a year ago -- threads is taking a little longer to cook (for good reasons), but async (without function coloring) is coming this year (likely in the next 3-4 months).
The sandboxing abilities of WASM are near unmatched, along with it's startup time and execution speed compared to native.
Joker_vD
WASM approach to injecting the host-interaction API seems to me to be similar to what EFI does. You are provided with a table full of magical functions on startup, and that's how you can interact with the host. Some functions weren't provided there? Tough luck.
fwsgonzo
As someone who has written a RISC-V sandbox for that purpose, I say stay the course. We need more competition to WASM. At the end you'll find that register machines make for faster interpreters than Harvard architectures. You can have a look at libriscv or message me if you need any help.
danpalmer
This assumes that everyone implements the same set of APIs that work in the same way.
More likely, the browser will implement some that make sense there, some browsers will implement more than others, Cloudflare workers will implement a different set, AWS Lambda will implement a different set or have some that don't work the same way... and now you need to write your WASM code to deal with these differing implementations.
Unless the API layer is, essentially, a Linux OS or maybe POSIX(?) for Docker, which I doubt it would be as that's a completely different level of abstraction to WASM, I don't have a lot of faith in this being a utopian ideal common API, given that as an industry we've so far failed almost every opportunity to make those common APIs.
hardwaresofton
Good point! This is the hard work that people are undertaking right now.
Things are going to change a little bit with the introduction of Preview3 (the flagship feature there is async without function coloring), but you can look at the core interfaces:
https://github.com/WebAssembly/WASI/tree/main/wasip2
This is what people are building on, in the upstream, and in the bytecode alliance
You're absolutely right about embeddings being varied, but the standard existing enforces the expectations around a core set of these, and then the carving out of embeddings to support different use cases is a welcome and intended consequence.
WASI started as closer to POSIX now, but there is a spectacular opportunity to not repeat some mistakes of the past, so some of those opportunities are taken where they make sense/won't cause too much disruption to people building in support.
josephg
True. Its probably worth creating a validation suite for wasi which can check that any given implementation implements all the functions correctly & consistently. Like, I'm imagining a wasm bundle which calls all the APIs it expects in every different configuration and outputs a scorecard showing what works properly and what doesn't.
I suspect you're right - unless people are careful, it'll be a jungle out there. Just like javascript is at the moment.
cudder
I have a funny feeling that some day we'll see Docker ported to wasm to "abstract it away cleanly". History is a circle and all that.
yencabulator
> half the point of docker is that all syscalls are routed into an LXD container with its own filesystem and network. It should be pretty easy to do the same thing in userland with a wasm runtime.
This is a serious misunderstanding of how containers work.
Containers make syscalls. The Linux kernel serves them. Linux kernel has features that let one put userspace processes in namespaces where they don't see everything. There is no "routing". There is no "its own filesystem and network", just a namespace where only some of the host filesystems and networks are visible. There is no second implementation of the syscalls in that scenario.
For WASM, someone has to implement the server-side "file I/O over WASI", "network I/O over WASI", and so on. And those APIs are likely going to be somewhat different looking than Linux syscalls, because the whole point is WASM was sandboxing.
Quite far from "pretty easy".
funcDropShadow
> True, but I suspect it'll be a lot easier to virtualise all those APIs through WASM than it is for a regular native binary. I mean, half the point of docker is that all syscalls are routed into an LXD container with its own filesystem and network. It should be pretty easy to do the same thing in userland with a wasm runtime.
All of this sounds too good to be true. The JVM tried to use one abstraction to abstract different processor ISAs, different operating systems, and a security boundary. The security boundary failed completely. As far as I understand WASM is choosing a different approach here, good. The abstraction over operating systems was a partial failure. It succeeded good enough for many types of server applications, but it was never good enough for desktop applications and system software. The abstraction over CPU was and is a big success, I'd say.
What exactly makes you think it is easier with WASM as a CPU abstraction to do all the rest again? Even when thinking about so diverse use-cases like in-browser apps and long running servers.
A big downside of all these super powerful abstraction layer is reaction to upstream changes. What happens when Linux introduces a next generation network API that has no counterpart in Windows or in the browser. What happens if the next language runtime wants to implement low-latency GC? Azul first designed a custom CPU and later changed the Linux API for memory management to make that possible for their JVM.
All in all the track record of attempts to build the one true solution for all our problems is quite bad. Some of these attempt discovered niches in which they are a very good fit, like the JVM and others are a curiosity of history.
SEJeff
docker and lxd are competing projects. Docker does not use lxd to launch containers. lxd was written by the lead dev (at canonical) of lxc which was not as polished as docker but sort of kind of did the same thing (ran better chroots)
They both use Linux kernel features such as control groups and namespaces. When put together this is referred to as a container but the kernel has zero concept of “a container”.
tecleandor
Docker started using an LXC driver to run workloads, but it was deprecated 10 years ago. No LXC remaining there :P
guappa
> It should be pretty easy to do the same thing in userland with a wasm runtime.
Not easy and certainly not fast.
resonious
This is what I was thinking. WASM is a good replacement for containers because it doesn't have these things.
gchamonlive
So basically virtual machines, those we can spin up with lxd or firecracker. Not that they don't have file access, it's just that's finnicky compared to containers (I'm thinking docker/podman)
p12tic
One can use something like https://github.com/google/gvisor as a container runtime for podman or docker. It's a good hybrid between VMs and containers. The container is put into sort of VM via kvm, but it does not supply a kernel and talks to a fake one. This means that security boundary is almost as strong as VM, but mostly everything will work like in a normal container.
E.g. here's I can read host filesystem even though uname says weird things about the kernel container is running in:
$ sudo podman run -it --runtime=/usr/bin/runsc_wrap -v /:/app debian:bookworm /bin/bash
root@7862d7c432b4:/# ls /app
bin home lib32 mnt run tmp vmlinuz.old
boot initrd.img lib64 opt sbin usr
dev initrd.img.old lost+found proc srv var
etc lib media root sys vmlinuz
root@7862d7c432b4:/# uname -a
Linux 7862d7c432b4 4.4.0 #1 SMP Sun Jan 10 15:06:54 PST 2016 x86_64 GNU/Linux
hardwaresofton
Yes, but note the difficulty of building a specialized I/O or drivers for controlling access in a virtual machine versus the WASI model.
Also, startup times are generally better w/ availability of general metering (fuel/epochs) for example. The features of Wasm versus a virtual machine are similar but there are definitely unique benefits to Wasm.
The closer comparison is probably the JVM -- but with support for many more languages (the list is growing, with upstream support commonplace).
Capricorn2481
I don't understand WASM, but I read that a big draw of WASM is it's ability to provide portability to any language. This would mean Python libraries that depend on an unpopular C library (which could be lost to time) could instead be a single WASM blob.
Assuming equivalent performance, which I understand might not be the case, is there merit to this idea? Or is there nothing new WASM provides?
zfg
Application plugins could also be wasm. That lets plugin authors write in any language they want and have their plugin work.
That's the idea behind the Extism framework:
uBlock Origin uses WebAssembly in Firefox for better performance:
https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b...
tyingq
The closest way to visualize it is probably how cloudflare offers something kind of like a container (if you squint) via it's workers product.
https://blog.cloudflare.com/announcing-wasi-on-workers/
I assume the merit for cloudflare is lower overhead cost per worker than if they had done something more like AWS lambda. Explained better than I can, here: https://developers.cloudflare.com/workers/reference/how-work...
It does currently present a lot of restrictions as compared to what you could do in a container. But it's good enough to run lots of real world stuff today.
hardwaresofton
> I don't understand WASM, but I read that a big draw of WASM is it's ability to provide portability to any language. This would mean Python libraries that depend on an unpopular C library (which could be lost to time) could instead be a single WASM blob.
Yes, this is a key value of WebAssembly compared to other approaches, it is a relatively (compared to a container or a full blown VM) lightweight way to package and distribute functionality from other languages, with high performance and fast startup. The artifact is minimal (like a static/dynamic library, depending on how much you've included), and if your language has a way to run WASM, you have a way to tap into that specialized computation.
afiori
I think that looking at it in terms of Embeddability is more useful compared to portability.
In the sense that compiling C to any language is easily done without too many problems, what wasm allow is to have a secure and performant interface with that language.
For example IIRC one of the first inclusions of wasm was to sandbox many of the various codecs that had regular security vulnerabilities, in this Wasm is neither the first nor the only approach, but with a combination of hype and simplicity it is having good success.
pjmlp
Basically yet another bytecode based runtime, but being sold as if it is the very first of its kind, despite prior history.
afiori
The idea with wasi containers is that you could spin up a container with only the interfaces it needs.
paul_h
Java's SecurityManager was cool at the start, but over the years there was a steady series of ways to side step it. And now Oracle are wholly deleting it in JDK 25 - https://openjdk.org/jeps/486. It was a stand out feature IMO, and I'll miss it.
throwaway7783
You meant Java applets perhaps? Java is still write-once run-anywhere if you stick with its APIs.
rr808
ActiveX had this sorted out 25 years ago. Code signing with different levels available for access outside the sandbox controllable by the user.
lxgr
And a nice centralized authority that judges the trustworthiness of a given application by staring at a binary extensively?
account42
More like staring at dollar bills. The more bills the more secure the software is.
jeremycarter
Sounds good!
okeuro49
> That's what killed the Java write-once, run-anywhere promise.
I write Java software on Intel and deploy to an arm device.
The promise seems to work for me.
account42
Cross compilers have solved this use case for pretty much any language with enough demand.
Meanwhile you won't have much luck running Eclipse or any other large Java program on your custom OS or hardware platform if you just port the JRE.
yencabulator
That's run-on-the-other-device-I-manage, not run-anywhere. Run-anywhere was used in the meaning of run-by-untrusting-parties, like javascript on the web.
rollcat
> But then you've got to figure out and prevent all the security holes that can be introduced by adding file access, networking, etc. [...] Maybe put the whole thing into a container?
Since this is an emerging ecosystem, why not take a different spin on security, and instead try e.g. capabilities? Instead of opening a connection to the DB, or a listening socket, you get FDs from your runtime. Instead of a path where you can read/write files, such as assets or local cache, you get a directory FD from openat (not sure right now if that could be bypassed with "..", but you get the idea).
Bonus: you can get hot code reloading for very cheap.
lmm
Java write once run anywhere is fine. Java people don't generally bother with containers because there's no point, the JVM already solves the same problem.
bzzzt
Almost all modern Java frameworks specifically target Docker containers in the cloud.
afiori
To be fair it is in part due to containers being a really nice way to deploy languages with fat-runtimes.
afiori
Portability and sandboxing are two very different properties.
danpalmer
WASM solves a different problem to containers. Where WASM does well is in running sandboxed code efficiently, because that's where it started out. I think WASM will likely take over as the standard for shipping things like Functions-as-a-Service implementations, and other forms of plugins, where one host application/server of some kind wants to efficiently run pieces of untrusted logic.
Containers don't solve that problem. They aren't a particularly good security boundary, and they are much heavier weight, in terms of bytes and startup costs, than WASM binaries, because they are deeply integrated into the OS for networking, etc. However, when what you need to do is ship a binary with a bunch of accoutrements, dependencies, files, etc, and then run multiple processes, multiple threads, and use more of the OS primitives, containers are an ergonomic way to do that, and that suits Infrastructure-as-a-Service much more closely.
p12tic
Container security boundary can be much stronger if one wants.
One can use something like https://github.com/google/gvisor as a container runtime for podman or docker. It's a good hybrid between VMs and containers. The container is put into sort of VM via kvm, but it does not supply a kernel and talks to a fake one. This means that security boundary is almost as strong as VM, but mostly everything will work like in a normal container.
E.g. here's I can read host filesystem even though uname says weird things about the kernel container is running in:
$ sudo podman run -it --runtime=/usr/bin/runsc_wrap -v /:/app debian:bookworm /bin/bash
root@7862d7c432b4:/# ls /app
bin home lib32 mnt run tmp vmlinuz.old
boot initrd.img lib64 opt sbin usr
dev initrd.img.old lost+found proc srv var
etc lib media root sys vmlinuz
root@7862d7c432b4:/# uname -a
Linux 7862d7c432b4 4.4.0 #1 SMP Sun Jan 10 15:06:54 PST 2016 x86_64 GNU/Linuxudev4096
gVisor is solid but it comes with a perf hit. Plus, it does not work on every image
yencabulator
FWIW the performance loss got a lot better in ~2023 when the open source gVisor switched away from ptrace. (Google had an internal non-published faster variant from the start.)
jauntywundrkind
You've shown that wasm solves a sandboxing/security concern that containers don't.
But wasm also has done a lot to enable a portable easy to ship blob/inage, and is rapidly tackling the distribution problems that has been key to container's success.
I'm not sure what we can really put firmly on containers side here, what makes them distinct or lasting as compared to what wasm is shaping up to be.
The various wasm runtimes already offer an array of low level threading and networking capabilities. Higher level services like http servers can be provided by runtimes with very optimized native backends, that have excellent performance characteristics but still "appear" as regular wasm. There may be niche long term users of containers for these reasons, but it's unclear to me that the systems programming capabilities will be much of a moat for containers: if anything, I think we'll see wasm implementations competing to provide the fastest performance for the same well specified interfaces in a hot war competition.
The main counter-factor against wasm that I see is just interia. Change is slow. These runtimes are still early. Wasm language targets have been around for a while but at various quality/polish levels. Wasm components are still effectively brand new, a year and a month after release, and the specs are still undergoing major updates to figure out how exactly async is going to work & there's very few runtimes keeping pace with this radical upshift. Its happening & I believe in wasm, but this is a long change and the capabilities aren't really truly here yet.
afiori
Docker-like containers will likely exists as long as there linux servers, maybe the trendiness will leave them behind, but they are a plainly good technology to deploy and distribute application with many fantastic usecases.
I too do see a future where Wasm is way more widespread but as of now we are deploying a small app with a MySQL in single docker container. I suspect that we won't be running MySQL compiled to a Wasm container anytime soon*
* I suspect that we could with the right transpilations/interpreters but for sure we won't
weinzierl
I think WASM will likely take over as the standard for shipping things like Functions-as-a-Service implementations, and other forms of plugins, where one host application/server of some kind wants to efficiently run pieces of untrusted logic.
I really hope WASM takes over as a plugin mechanism. I don't think it will lead to fragmentation because communities will form around their preferred language, it will just not be enforced anymore. And forcing a plugin language did not work so successfully to prevent fragmentation anyway, see GNU Guile or vimscript.
shortrounddev2
I think WASM will end up being more useful as a universal language VM on client machines than it will as a tool for browser computation
konaraddi
Cloudflare, Fastly, and Amex use WASM in their FaaS implementations
andrew_rfc
Cloudflare actually uses workerd which is a V8 isolate (which does support WASM with a lot of caveats.)
yencabulator
And you can tell it's really always Javascript with the ability to call into WASM. WASM on Cloudflare Workers is clearly a second class citizen.
verdverm
There are a lot of package compatibility issues, not everyone has migrated or will migrate away from things like fs access
I'm going through this now, giving a full Cloudflare tech stack a shot, but I'm nearing a limit before I just go back to containers
danpalmer
Yeah and that's where it makes a lot of sense. Less sense is replacing containers where you're using much more of the stack. FaaS hasn't replaced VMs, Kubernetes, Containers, etc, so it seems unlikely that WASM would for similar reasons.
TZubiri
Wasm: client, user's device
Containers: server, dev's device
Cmon OP try to keep up
danpalmer
Well, not quite, that's an oversimplification. As I mentioned I think there's a place for WASM as the common unit of business logic, for things like plugins.
Implementing a FaaS runtime like Lambda is actually quite hard to do in a way that is both safe and multi-language. Compiling down to a safe, sandboxed bytecode, is not a bad idea, regardless of whether you're doing that to run it in a user's browser, or to run a FaaS function on some cloud infra, or to write a server-side plugin to a SaaS product.
verdverm
This is what CUE is exploring for WASM, the ability to have custom functions or plugins that can be shipped with modules and run anywhere. It will be super cool, but they are blocked on upstream changes to the WASM runtime
TZubiri
Yeah sure, there was a time people believed that about javascript, and node.js ended up being a tool used to build website middle-ends and BFF to connect to actual backends.
The user's device which can be a smartphone or a latpop and the developer's device which can be a 24 hour online server or a 24 hour online server, are just two completely different devices that cannot be abstracted away.
WASM is a technology that was born for the frontend, and js was a technology that was born for the frontend, you can for sure metastasize the web front towards the back, but then you end up with a web bias in the frontend (why not make the backend in swift, or Java for phones?, or whatever language will be used for new tech like LLM voice assistants?) and of course a frontend bias in the backend.
Not a good look, let's stop it with the full stack thing, let's specialize, half of use do backend, half of you do frontend, and then we keep on specializing, if everyone does everything we'll cover no ground.
paulgb
> WebAssembly is a true write-once-run-anywhere experience. (Anywhere that can spin up a V8 engine, which is a lot of places these days.)
This is true if your wasm code is purely computational, but if it interacts with the outside world it’s a different story. Each V8 runtime has a subtly different interface, so code that runs on cloudflare V8 might not run in Bun or Deno. Not to mention if you want to support WASI too, which is a different set of bindings even though it’s still WebAssembly.
Love or hate Docker, part of its success was that POSIX was already a fairly established standard and there weren’t a lot of vendors driving it in different directions.
porridgeraisin
> Bun
Nit: bun uses javascriptcore
stackskipton
As PlatformOps (formerly DevOps (formerly SRE (formerly Ops))), either this was hilarious satire or ChatGPT Ketamine trip. I'm not sure.
> In the year 2030, no one will remember Kubernetes.
So what's going to handle out rolling out new versions of your WASM, setting up whatever Reverse Proxy you pick and other stuff involved getting. A bunch of scripts you wrote to do this for you? https://www.macchaffee.com/blog/2024/you-have-built-a-kubern...
> The promise of DevOps has been eroded by complicated tooling and tight coupling of program-container-linux. In my experience, developers want to write code and ship features to hit their quarterly goals.
Here is why we ended up here: In my experience, developers want to write code and ship features to hit their quarterly goals.
Sure, and my angry PlatformOps (formerly DevOps (formerly SRE (formerly Ops))) is stuck picking up the pieces because we are getting crap while we desperately paging you because we have no clue what "duplicate street key" in your logs mean. On top of that, InfoSec dropped us 10 tickets about code level library vulnerabilities in your docker container but all the Developer's Managers got together to convince them it was our problem somehow.
So we are forced to write this bundle of terribly written Ops type software in attempt to keep this train on the tracks while you strap rockets to cafe car.
WASM replacing containers is just a solution looking for a problem. Containers solved a problem of "How do we run two different versions of PHP on a single server without them colliding." Most of the containers problem is higher level DevOps problems that we haven't been able to solve and WASM isn't going to change that. I deal with a team that writes 100% Golang so their code is like WASM as it's ship binary and done. Yea, they begged for Kubernetes because it works a ton better then custom Ansible they wrote to keep these VMs/Load Balancer in sync.
sebstefan
WASM is powering Cloudflare workers in pretty much the fashion the guy describes and it does solve the problem of big latencies for cold starts with Lambda stuff
Instead of spinning up a container on-demand you spin up what is essentially a chrome tab in your V8 instance. Startup time is nil
In terms of solutions looking for a problem, that one seems to have fixed at least one problem for at least one person
It's pretty genius
yencabulator
> Startup time is nil
This is obviously not true when the application itself can take arbitrary amount of time to initialize.
The overhead of WASM startup is small. But Firecracker is also very quick to start the virtualization; a lean compiled app in Firecracker would start quicker than a bloaty interpreted app in WASM. Both approaches can also freeze a pre-initialized application, and even clone those.
Reality is most "serverless" stuff is slow to start because the application itself is slow to start. WASM isn't going to change that, Enterprises are going to Enterprise. The hype field is just very strong.
stackskipton
WASM has select uses. Cold startups for functions is one of them and glad Cloudflare was able to use it.
I however don't have that problem. Every environment I've been in has banished Lambdas for most things because writing ourselves into knots to keep the lambdas going wasn't worth just having a small container listening to SQS/Kafka was easier and if we needed to scale, we could.
Melatonic
Micro VMs are the future in my opinion. Best of all worlds
fujinghg
Funnily enough the first thing I thought was ketamine.
sleepybrett
The impression I got initially was WASM is a way to ship and app into the browser as a blob of bytecode. No more random pile of js files that are largely unreadable due to trying to shave every last extra byte off them.
While I would lament the age that I came up in, where if some hot company down the street had just a killer javascript dropdown menu well you could just view source and maybe learn a few things. I think what that initial impression I got was a great idea.
But yeah, the concept has kind of expanded. I want to say you can write WASM 'plugins' for istio. Which I also think is pretty cool.
Something is going to replace containers, I say let them take a swing at it but I think at the end of the day you get something that ends up looking a lot like containers.
hardwaregeek
When? We’ve been talking about wasm for years. When are we actually getting this future? It’s been 8 years since wasm 1.0, and still we don’t have a stable, easy to use toolchain. Rust has maybe the best support and I still can’t get a basic async application with tokio to work on wasm.
To put it into context, Rust was released in 2012. 8 years later it was stable, had a solid toolchain and plenty of people using it in production. Wasm still feels like a toy compared to that
azakai
Lots of people use wasm in production right now, and toolchain support is in a good place across several languages. In that sense we are already there.
You likely visited a website using wasm today without realizing it, and major apps like Photoshop have been ported to wasm, which was the original dream behind it all. That has all succeeded.
But if you want to replace containers specifically, as this article wants, then you need more than wasm 1.0 or even 2.0. I don't know when that future will arrive.
hardwaregeek
There's a difference between a handful of sites that use wasm and it being the mainstream way in which we write web applications and run hosted software. It's still a very very niche platform that has not fulfilled its promise of either being a first party web tool or a universal runtime.
Like, how easy is it to write a web application in Wasm? Or how easy is it to compile your average program written for a native platform to Wasm without hand picking your dependencies to work on the platform?
azakai
You're right, but wasm's goals were never to be a mainstream way to write web applications. It was designed very specifically to allow things like Photoshop, Unity, and other high-end applications to run on the Web, things that just didn't run at all, and were really important. But despite their importance, those applications are a small fraction of total websites.
Wasm succeeded at its initial goals, and has been expanding into more use cases like compiling GC languages. Perhaps some day it will be common to write websites in wasm, but personally I doubt it - JavaScript/TypeScript are excellent.
zfg
American Express uses WebAssembly for exactly this use case:
https://thenewstack.io/amexs-faas-uses-webassembly-instead-o...
harrall
WASM is another VM and it reminds me of the difficulty that the JVM has faced. You can write-once-run-once a lot of languages like Ruby or JavaScript on the JVM and some of the runtimes are pretty good.
But the rest of the community prefers using the original implementation. If some library that you want to use doesn’t work, no one is going to help you. You’re using the second class implementation.
Dwedit
I tried out WASM for a very small project once. This was built from a freestanding C source file (no libraries at all, not even the standard library). Zig was the C compiler used to build the program.
And I was able to get things working with an understanding of the whole system. You could instantiate the WASM from either a file, or from a byte array, pass in the byte array that held 'system memory' for the WASM program, call the WASM functions from the JavaScript code, and see results of making the function calls. The WASM binary was under 3KB in size.
Now once you want to use libraries, everything light and small about WASM goes out the window. You're at the mercy of how efficiently the library code was implemented, and how many dependencies they used while doing so.
jeroenhd
If you skip the async stuff, Rust in WASM works quite well. I also found that Go has quite good WASM support.
I think the "WASM as containers" and "WASM as .jar" approaches are rather silly, but language support is good enough to use the technology if you think it's a match. I don't think it will be for most, but there are use cases where pluggable modules with very limited API access are necessary, and for those use cases WASM works.
Plus, if you want to run any kind of game engine in the browser, you're going to need WASM. While I'm not replacing my Steam install with a browser any time soon, I have found that WASM inside itch.io runs a lot faster and more stable than Winlator when I'm on my Android tablet.
dustbunny
Emscripten seems pretty stable and easy to use to me?
pjmlp
Still not as easy a C++/CLI in .NET, in terms of tooling.
octopoc
Blazor is stable and extremely easy to use. It’s just a little slow to load, although there are ways to mitigate that.
catmanjan
Blazor is a great developer experience but when you put it side by side with the other technology solutions (react, angular, anything really) its so slow that you will quickly be told to use something else...
octopoc
It depends on the application. And gp was talking about stability and ease of use, not speed.
otterley
> When are we actually getting this future?
Around the same time Linux is ready for the desktop.
milesrout
Unlikely as that was whenever you stopped having to write Xorg.conf by hand, ie the mid 2000s.
pjmlp
As long as, people use their computers as PC towers from 2000, without hardware video decoding, sleep states, modern UEFI features.
There is naturally the version that works, keeping the Linux kernel, and replacing the userland with managed language frameworks, I have heard they are making a huge success in mobile devices and throwaway laptops.
moribvndvs
One benefit of being an old engineer is watching how excited people get when they rediscover something that has gone around the bend over and over again. I swear if you fuckers reinvent DCOM I will shit in your hats.
invalidname
Exactly. It's like the JVM circa 2004. Without all the observability and features we have today and half the performance/reliability/security.
pjmlp
We had them, Java EE application servers had all of that available, as did CLR/IIS, or IBM AS/400 for that matter, really we have seen it before.
cheesekunator
I actually didn't mind COM and DCOM. I didn't overuse it, so it never bit me. I guess it's why I love using Microsoft Orleans. The virtual actor model is enough for me to solve almost every problem. If Cloudflare Durable Objects (https://developers.cloudflare.com/durable-objects) can reduce latency they might have the winning product.
crabmusket
On that note, do you mind helping me understand something I haven't been able to glean from Microsoft's docs? Does Orleans give you a way to globally address a thread?
With Durable Objects, two clients on either side of the world can both request a websocket connection to an object with the same unique identifier, and all the bytes from those clients will land in one single process somewhere inside a CloudFlare data centre.
I am pretty sure the answer is yes, but the docs seem a bit less direct than CloudFlare's web focused use cases.
pjmlp
Actually it is more like CORBA, powered by RMI.
aqueueaqueue
I can invent spinning green balls.
RantyDave
OMG I hated DCOM so thoroughly.
mdaniel
Preach it, because document/literal SOAP and WSDL are The Way, The Truth, and The Light!
birdiesanders
The author has not seemingly considered the vastly different networking in wasm. You don’t have networking. There is an entirely different utility in these environments, containers are meant to host applications, wasm is an application. Don’t even get me started on disk access, env handling, etc. wasi is great, for the places it does well. It is not a replacement for writing a pure golang/rust/c/julia app and running it in a container, it doesn’t have the facilities for that task.
mavdi
Anyone comes up with any shit these days, say apples will replace oranges.
“ChatGPT make me sound confident”
LeFantome
WASM does not run on real hardware. At best, WASM can be considered a virtual machine (in the way that the JVM and the .NET CLR are virtual machines). I guess we can call that a "runtime".
Containers package applications that run directly on real hardware (well, directly on a real kernel that is running on real hardware). There is no runtime. I am talking OCI containers here (Docker and Kubernetes). At least they can. Most containers are probably running on a Linux kernel that is running in a virtual machine (in the way that KVM, EC2, and VirtualBox are virtual machines).
WASM needs a runtime. That is, it is going to run inside an application. That application needs to run on a kernel. So, WASM will always be further from the hardware than a container is.
WASM solves the same "portability" problem that the JVM and .NET do. So, maybe WASM wins against those environments.
That is not the problem that containers solve though. Containers bundle applications with their dependencies. They replace "installation and configuration" with instantiation (deployment). WASM does not magically eliminate dependencies or the differences between environments (not even the difference between V8 implementations).
If anything, the technologies are complementary. Maybe, in the future, all our containers will be runing WASM applications.
Or maybe we will run a different kind of container that ONLY runs WASM applications and then WASM can replace the Linux kernel running in a VM that hosts all our OCI containers today. Perhaps that is what the author really envisions. Even then, it sounds like more of a complement than a true alternative.
lxgr
WASM needs an execution environment just like containers. The execution environment for containers just happens to be largely provided by Linux.
> WASM does not magically eliminate dependencies or the differences between environments (not even the difference between V8 implementations).
Not by itself, and not currently, but I don't find it too much of a leap of faith to assume that that'll be standardized before too long.
invalidname
Yes. It doesn't provide the roughly 20 years of advancements in JVM technology either. Modern observability and JVM scale is at a different level. The trend was to get the maximum use of hardware. Specifically get away from virtualization to containers. This bucks the trend for absolutely no tangible benefit.
yencabulator
> WASM does not run on real hardware.
Here's a compiler from WASM to native code, it can run AoT also not just JIT:
Stevvo
WASM can run on real hardware. e.g. innative.dev
npodbielski
Seems kinda dead. Last release 2 years ago and last commit nine months.
Stevvo
It's used in Flight Simulator, but Microsoft have their own fork with changes not contributed upstream.
Thaxll
"Learning how to use Docker is a distraction"
As if you need to learn anything, you get your Dockerfile and that's it, what else there is to learn? Your WASM app still need Kubernetes to run so it's not adding any value.
The complexity is not in running your app in Docker, the complexity is running your container somewhere, and WASM does not help at all with that.
WebAssembly is not going anywhere, it's pretty clear it won't grow much in the next 5years.
TZubiri
Disagree.
It's not trivial to manage a running container or group of, with firewalls and filesystems and whatnot.
My biggest gripe is that it's quite redundant with the os and tends to reinvent stuff. You end up needing to learn, doc, and build towards both os layer fw and container layer fw for example.
milesrout
WASM will be that but tenfold surely? You would need to program against a completely new interface.
hardwaresofton
Wasm is getting merged in and designed in a way that it is "drop in". As in, the standard libs are written to do WASI calls instead of libc (or whatever else) for standard I/O concerns.
This is represented in some languages better than others -- for many languages you just switch the "target" -- from x86_64-unknown-linux-gnu to wasm32-wasip2 (ex. Rust). Some things won't work, but most/many will (simple file access, etc), as they are covered under WASI[0]
That's not to say that nothing will change, because there are some technologies that cannot be simply ported, but the explicit goal is to not require porting.
trescenzi
Containers have two goals: reproducibility/portability, and encapsulation. WASM could replace the reproducibility but it can't replace the encapsulation.
> My money is on WebAssembly (WASM) to replace containers. It already has in some places. WebAssembly is a true write-once-run-anywhere experience. (Anywhere that can spin up a V8 engine, which is a lot of places these days.)
Luckily a container is a place that can spin up a V8 engine. If you want to bet on WASM my bet would be on containers running WASM.
jagged-chisel
> … it can't replace the encapsulation.
Can you explain your thoughts here? WebAssembly is sandboxed and effort must be expended to provide a mechanism for getting data through that boundary. How does that differ from “encapsulation?”
trescenzi
I'm referring to a different kind of encapsulation. Dependencies, tools, version management, configurations, environment variables, etc. Even if you can fully compile your code into WASM and host it on V8 you need to ship it with configuration files, set specific environment variables and so on. Containers allow you to bundle all of that together into a single unit you can share with others.
hardwaresofton
Note that it is possible to ship containers with configuration files and environment variables. Because Wasm imports can be virtualized (i.e.you could choose to fulfill a file-fetching interface completely or partially by composing two components together), it is possible to build a WebAssembly binary with what you need bundled.
Also, just because you could does not mean you should -- most of the time you don't want to inject environment variables or configurations that could contain secrets until runtime.
Capricorn2481
What about WASM doesn't encapsulate dependencies? Isn't it all one WASM blob at the end of the day?
afiori
That would be handled by the equivalent of a dockerfile/docker-compose.yml,
aftbit
Unless you run the build in WASM itself. Are there any self-hosting WASM build chains?
bocahtie
I'm always reminded of Gary Bernhardt's "the birth and death of javascript" when wasm gets discussed. While it's a bit tongue-in-cheek, I think it really drives home that it's really just another layer of abstraction that may or may not be useful for a given problem, and might not be the silver bullet that anyone is looking for. I recon that whether or not wasm will take over everything will mostly be about trade offs between it and the other solutions.
josh11b
That is what I was thinking of too! From 2014: https://www.destroyallsoftware.com/talks/the-birth-and-death....
tantalor
Yes! I was trying to search for this but I couldn't remember the name.
afiori
This for sure, eg it will never be commonplace to run posgres compiled to wasm.
Most instances of "X will eat the world" and "X will be used anywhere" will be false even for very successful technologies
remram
WASM might replace processes, but the idea that people will take the stuff they can't manage to put in a native process, and somehow manage to cram it into WASM... ridiculous.
There's not even a single argument in there to support the clickbait title. We have containers, but "containers are annoying". WASM won't be annoying? Pray tell, how do you surmise that?
Docker too complicated? Build times too long? You believe WASM tools will be simpler and faster... why?
"The main thing holding back wider adoption is a lack of system interfaces. File access, networking, etc. But it's just a matter of time before these features get integrated."
But then you've got to figure out and prevent all the security holes that can be introduced by adding file access, networking, etc. That's what killed the Java write-once, run-anywhere promise. Maybe put the whole thing into a container? Oops, looks like the container wasn't replaced after all (though perhaps it could be simplified).