by hpincket on 2/12/25, 1:24 AM with 356 comments
by not2b on 2/12/25, 2:02 AM
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).
by danpalmer on 2/12/25, 3:03 AM
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.
by paulgb on 2/12/25, 2:18 AM
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.
by stackskipton on 2/12/25, 2:55 AM
> 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.
by hardwaregeek on 2/12/25, 2:09 AM
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
by moribvndvs on 2/12/25, 3:01 AM
by birdiesanders on 2/12/25, 2:03 AM
by LeFantome on 2/12/25, 3:06 AM
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.
by Thaxll on 2/12/25, 2:17 AM
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.
by trescenzi on 2/12/25, 1:57 AM
> 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.
by bocahtie on 2/12/25, 2:25 AM
by remram on 2/12/25, 2:56 AM
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?
by kryptiskt on 2/12/25, 7:47 AM
The WASM world doesn't have most of the pieces of that puzzle and WASM itself is quite irrelevant. Say we standardized on a sandbox running x86_64 VMs under Firecracker, with the proper sandboxing that would work just as well as running WASM. You might say that WASM is portable, x86_64 assembler is not, to that I would counter that ARM (and probably RISC-V too) can emulate x86_64 faster than they can run WASM. So what's the point of the WASM piece of the puzzle?
by aartav on 2/12/25, 11:56 AM
Funny. The most obvious place for WASM is a web browser and yet WASM STILL cannot access the browser DOM. Its only been, what? At least 8 years of promises about it coming soon and how people are working on it.
by ninetyninenine on 2/12/25, 2:10 AM
WASM will never replace containers. People will be running wasm inside of containers. That's what will happen.
by ianburrell on 2/12/25, 2:40 AM
Also, I think most uses of containers lose the advantage of WASM. WASM is about running on any platform, great for browsers and serverless. But containers are usually run in controlled environment where can compile once and not pay the penalty of compiling each time.
by tombert on 2/12/25, 1:54 AM
I wonder if someone could make a decent cross-platform GUI toolkit to save us from the horribly slow Electron-hell we've carved out for ourselves.
by krackers on 2/12/25, 2:14 AM
by udev4096 on 2/12/25, 8:06 AM
by algorithmsRcool on 2/12/25, 2:37 AM
by c0balt on 2/12/25, 5:16 AM
As a sys admin, no, we will have to remember. Once a system is in place and "functions", they tend to stay for a long time.
by kortex on 2/12/25, 2:42 AM
> WebAssembly is a true write-once-run-anywhere experience.
Except not. The wasm ISA is really quite limited in the types of operations. A full-blown RISC/CISC ISA will have way more opportunities for optimization. To say nothing of multithreading and pipelining. JITing also has overhead.
> You can compile several languages into WebAssembly already.
But if you can compile them, why not just compile to container, and get free performance?
Wasm will have a hard time with anything low level: networking, I/O, GPU, multimedia codecs.
by sleepy_keita on 2/12/25, 2:58 AM
by syrusakbary on 2/12/25, 8:58 AM
Personally, I don't think that Cloudflare is the best provider for Wasm at the Edge as everything needs to go through a Javascript layer that eventually hurts performance and prevents further optimization, but is a strong one nontheless (note: take everything with a grain of salt, even though I try hard to not be biased, I'm also founder of Wasmer)
> "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."
Wasmer launched WASIX [1] a few years ago which fulfills the vision that the article describes. With WASIX you can have sandboxed access to:
1. Filesystem
2. Networking / Sockets
3. Processes
4. Threads
by chambers on 2/12/25, 2:22 AM
What I found was the JS version was a bit faster than the compiled WAT. Yikes.
EDIT: I think I'll try debugging it more
by bayindirh on 2/12/25, 8:44 AM
Containers are much more than that. They're service providers for small installations, short-running VeryFatBinaries, close to the metal, yet isolated complex applications in HPC environments.
WASM will be all and well, it'll be a glorified CGI, and might be a good one at that, we'll see, but it'll not and can't snipe containers with one clean headshot and be done with that.
It'll replace Kubernetes? Don't be silly. Not everyone is running K8S for the same reason, and I'm telling that as a person who doesn't like K8S.
by gigel82 on 2/12/25, 2:06 AM
It would be immensely silly to run full x86 emulators in WebAssembly and go through 2 layers of transpiling / interpreting for what can run natively on the host's CPU.
This argument always reminds me of "Square Hole!" video: https://www.youtube.com/watch?v=6pDH66X3ClA (just because you can make it fit, it doesn't mean you should do it).
by tbrownaw on 2/12/25, 2:59 AM
That's 5 years from now.
Which is a pretty good time frame for getting enterprisey things on to kubernetes.
And maybe a bit short for getting vendors to add a new sandboxed VM type to their supported platforms.
by colonial on 2/12/25, 6:05 AM
At their heart, modern containers are a clever way to create something that looks like a Linux VM without the overhead of actual virtualization. Your application still executes "natively," just inside of a Potemkin environment (modulo whatever holes you poke in the veneer.) The latter bit is why we use containers.
WASM is a bytecode format. It doesn't carry around the environment it needs to execute correctly like a container does. In fact, it (by definition) needs an environment with certain properties (interpreter/JIT present) to work!
by jb_gericke on 2/12/25, 3:22 AM
by fngjdflmdflg on 2/12/25, 2:48 AM
by h0l0cube on 2/12/25, 2:19 AM
A big constraint here is the memory model. Languages include a specification for memory allocation, deallocation, lifetime and garbage collection, and WASM has it's own way of going about that that is engine dependent. The performance lost from reimplementing the memory model within WASM could only be regained by going back to something that looks like containers.
by Humphrey on 2/12/25, 2:03 AM
by tibbar on 2/12/25, 1:59 AM
I mean I don't enjoy Docker either, but I think it's more that there are many problems k8s + Docker help you solve, and WASM alone wouldn't solve a lot of them.
by bborud on 2/12/25, 10:41 AM
If this was done in a way that works in mechanical sympathy with a wide range of languages I think WASM would be more successful. Making an API available inside a sandbox is painful. You have to manually roll something that can deal with memory, marshal calls and parameters etc. I'm not suggesting it is easy. I'm merely pointing out that this is what I see as the main obstacle to adoption.
I am not interested in "generic" access to system resources (filesystem, network etc) at all. In fact, I can't think of any scenario where I'd actually want to do that. I want to provide APIs that deal with external resources in narrowly defined ways.
It is much easier to do this securely when you explicitly have to provide functionality rather than say "here's the filesystem" and then try to clamp down access.
I want to use WASM on servers. Primarily in Go. I want to be able to create a bunch of APIs that provide narrow access to persistence and communication and project those APIs into the sandbox. In a manner that is interoperable and easy to use from various languages. I don't want to have to craft some application specific marshalling scheme.
If projecting APIs into sandboxes in a (mostly) language agnostic way that is natural, safe and easy to use, it'd be easy enough to write system interfaces. I have no idea why so few people see this as important since I feel it should be self-evident.
(And yes, being able to offer concurrency would be nice, but that's a much smaller issue than the problem of there being no good way to marshall APIs into WASM containers)
by hansmayer on 2/12/25, 7:43 AM
by iLemming on 2/12/25, 4:30 AM
I've grown less young since then, and I can probably count numerous other claims for some great idea to replace "all this crap very soon." Turns out, "one-size-fits-all" solutions are almost always hype, sometimes not even backed up with pragmatic arguments. There are simply no silver bullets in our industry, especially in relation to web tech. Guess what? Some websites are still being built with jQuery, and maybe there's nothing wrong with that.
No, WASM not going to replace containers. At best, it will likely find its specific niches rather than becoming a universal solution. That's all.
by thesz on 2/12/25, 1:16 PM
And author loves shiny new things [1]: "...use 10% of your time writing code (or telling AI to write code)..."
[1] https://creston.blog/stop-writing-code/
What about old, not shiny things?
For example, SQL is Turing complete and expresses simulation of data flow paradigm [2]. It is effectively executable on current massively parallel hardware and even scales horizontally, enabling safe transactional "microservices." Why should we embrace WASM, but not SQL?
by malkia on 2/12/25, 2:12 AM
by bovermyer on 2/12/25, 12:49 PM
by kodama-lens on 2/12/25, 11:12 AM
Right now I can run containers and WASM workloads in the same k8s clusters. I dont even have to think about it with runtimes like crun/youki or wasmedge. The OCI image format is the universal package format. It always has all its need and the tooling is broad and mature.
With containers I can basically put any app in any language in there and it just runs. WASM support is far from that, there is migration toil. Containers are and will be more flexible then WASM
by imglorp on 2/12/25, 2:02 AM
I feel like this prolog missed an important point. Kubernetes abstracts data centers: networking, storage, workload, policy. Containers implement workloads. They're at different layers.
And back to the article's point: WASM may well replace containerized workloads, indeed there are already WASM node runtimes for Kubernetes. Something else may well replace Kubernetes in five years, but it won't be something at the workload layer.
by stlava on 2/12/25, 3:20 AM
I highly doubt that. Maybe there will be an evolution to k8s but fundamentally it solves a whole host of challenges around defining the environment an application runs in.
by sargun on 2/12/25, 4:29 AM
by cess11 on 2/12/25, 10:16 AM
I sure hope "developing on Cloudflare" is not "what the future looks like".
There are many, many VM:s and programming languages that are more or less easy to compile to many architectures and/or possible to run straight on a hypervisor or metal. JavaScript, Python, Lua, V, and so on. None of them are seen as container competitors.
by SEJeff on 2/12/25, 6:23 AM
https://github.com/firedancer-io/firedancer/blob/main/src/ut...
He researched chromeos process virtualization, moby (docker upstream), and chrome tab isolation. It’s all done ebpf magic on top of seccomp at its core.
by kukiTsui on 2/17/25, 7:26 AM
by weinzierl on 2/12/25, 9:02 AM
Maybe not, but one can dream at least.
What do we need containers for, if we can build a service in a binary that you can throw on any Linux of the past 20 years and it just starts to serve network requests?
What do we need to support other platforms if the server world is one big Linux monoculture and the next best platforms are just a cross-compile away?
Why wouldn't I compile everything statically if containers don't share libraries anyway?
by nunez on 2/12/25, 5:56 AM
by 0dayz on 2/12/25, 2:38 AM
I don't doubt that wasm has potential, but personally I imagine more esoteric use cases as the go to than necessarily the replacement for containers (where my money is more on unikernel).
by ninetyninenine on 2/12/25, 2:04 AM
The purpose of docker is like a VM. To simulate the running of two or more server machines with OS's to run on one machine.
wasm is like java.
by jpillora on 2/12/25, 4:42 AM
- Containers are wrappers for binaries. Any binary can be contained, and when run, it gets a constrained (fake) view of the kernel.
- WASM defines a portable binary format. WASM is intermediate-representation, in the same vein as Java byte-code.
You could reasonably put WASM binaries inside containers
by quotemstr on 2/12/25, 2:58 AM
by bloopernova on 2/12/25, 1:58 AM
We'd use a Dockerfile, install nodejs or use a source image to build from. How does that work for wasm? Does it have layers to reuse?
by awill88 on 2/12/25, 5:04 AM
by orliesaurus on 2/12/25, 2:01 AM
I'm curious what's holding it back?
It seems like despite its technical advancements, WASM hasn't captured the public's interest in the same way some other technologies have. Perhaps it's a lack of easily accessible learning resources, or maybe the benefits haven't been clearly articulated to a broader audience. There's also the possibility that developers haven't fully embraced WASM due to existing toolchains and workflows.
by dowager_dan99 on 2/12/25, 4:37 AM
>> I am a software developer for a top 100 app. I've written code you've probably used. That makes me qualified to say stuff.
Ah... that explains a bunch of it.
by pjmlp on 2/12/25, 5:24 AM
by mikewarot on 2/12/25, 3:04 AM
If someone tacks on file system access to WASM, the whole system becomes worthless.
by fergie on 2/12/25, 9:14 AM
Is there any compelling reason not to just compile TypeScript to WASM? Why should it have JavaScript as its compile target?
by sebstefan on 2/12/25, 12:11 PM
The draw of WASM is to be able to have your code run in a browser tab exactly as it can run on your local hardware, as it can run if you embed it in your own application, with the only thing moving being custom syscalls between the 3
The biggest limitation of the JVM was that it's closed
You can spin up your own WASM interpreter and integrate it anywhere you like. It wouldn't be an impossible bridge to cross, it's RISC, it's open, there's many open implementations. Is it even possible to write your own JVM from scratch?
by stego-tech on 2/12/25, 5:20 AM
Servers were the future of code after mainframes because of simplicity and write-once run-anywhere code but without all the complexity, they just needed similar networking and storage solutions as mainframes had to be viable first.
Virtual machines would be the future of bare metal servers, allowing code to be written once and run anywhere, eliminating the complexity of bare metal servers. VMs just needed better networking and storage first to be viable.
Containers would replace the complexity of VMs and finally allow code to be written once and run anywhere, once orchestration for storage and networking was figured out.
Serverless would replace containers and allow code to be…
You get the idea.
The only thing holding back code from truly being “write-once, run anywhere” is literally everything that keeps it safe and scalable. The complexity is the solution. WebAssembly will start with the same promise of a Golden Path for development, until all the ancillary tooling ruins the joy (because now it’s no longer a curiosity, but a production environment with change controls and SOPs) and someone else comes along with an alternative that’s simpler and easier to use, because it lacks the things that make it truly work.
I don’t particularly care how it’s packaged in the end, so long as it runs and has appropriate documentation. Could be a container, or a VM template, or an OS package, or a traditional installer, or a function meant for a serverless platform.
Just write good code and support it. Everything else is getting lost in the forest.
by ok_dad on 2/12/25, 1:55 AM
by mabedan on 2/12/25, 11:53 AM
No oversimplification to see here.
by Evidlo on 2/12/25, 6:33 AM
by cprogrammer1994 on 2/12/25, 9:45 AM
by ein0p on 2/12/25, 2:45 AM
by WhereIsTheTruth on 2/12/25, 7:26 AM
Who wants everyone to be forced to use the same BigTech slop?
by pluto_modadic on 2/12/25, 2:17 AM
no way someone would engineer their way out of not over-engineering a kubernetes stack.
The other bit of this is that FNaaS pricing is crazy expensive. Unless someone goes an order of magnitude cheaper than cloudflare's wrangler offering on the edge, I don't see it happening. You get none of the portability by writing yourself into a FNaaS cage like cloudflare or fastly.
Companies start off with business logic that solves a problem. Then they scale it (awkwardly or not) as it balloons with customers. Then they try to optimize it (sometimes by going to the cloud, sometimes by going back to their own VMs). VCs might not like "ending growth", but once you're on a stable customer basis you can breath, understand your true optimal compute, and make a commitment to physical hardware (which is cheaper than cloud scaling, and FAR cheaper than FNaaS).
The piece that might travel the entire way with you? Containers and Kubernetes.
by phendrenad2 on 2/12/25, 6:18 AM
by LunicLynx on 2/12/25, 7:59 AM
by poisonborz on 2/12/25, 7:51 AM
by tomrod on 2/12/25, 1:58 AM
It's been about 3 years since I dug into WASM and was bewildered about how to use it.
Is it time to dig back in?
by gedw99 on 2/13/25, 1:30 AM
That’s double server costs.
It’s golang so maybe that’s why ?
by ACELARE on 2/12/25, 10:18 AM
Fellow Wikipedians may show their interest in the comment section.
by xyst on 2/12/25, 3:02 AM
by il-b on 2/13/25, 7:34 AM
by t2o34h234234 on 2/12/25, 2:48 AM
by oppositelock on 2/12/25, 3:05 AM
Containers, VM's, physical servers, WASM programs, Kubernetes, and countless other technologies fill niches. They will become mature, boring technologies, but they'll be around, powering all the services we use. We take mature technologies, like SQL or HTTP for granted, but once upon a time, they were the new hotness and people argued about their suitability.
It sounds like another way to distribute software has entered the chat, and it'll be useful for some people, and not for others.
by nottorp on 2/12/25, 10:39 AM
Truly buzzword compliant, this article.
by zombiwoof on 2/12/25, 2:50 AM
by tonymet on 2/13/25, 1:38 AM
by gnarbarian on 2/12/25, 2:36 AM
by diego_moita on 2/12/25, 2:09 AM
Author's argument is "because it is easier today and will be as powerful as containers in the future".
Well, what about it gets as powerful but 3 times more complex? Frankly, I find it quite messy to develop WASM in C++ without downloading an emscripten ...container. Yeah, AFAIK, there is no WASM compiler in WASM.
Oh an there is the *in the browser*, also. Yeah, but the truth of the matter is that most WASM frameworks have a mediocre performance when compared to JS (because of the memory isolation).
In this job we love new projects. We like them so much that we keep forgetting that the vast majority of them fail.
by markhahn on 2/12/25, 2:13 AM
by KaiserPro on 2/12/25, 12:15 PM
The problem with modern containers is not the container (well it kinda is) its the thing that works out how to run and connect that container.
Kubernetes is a shit to configure, insecure unless you spend effort tracing and managing permissions, expensive to run.
But it is cool.
Apart from the networking. Thats just fucking batshit.
TLDR: Containers aren't the problem its the stupid orchestration layers people insist on building.
by smarklefunf on 2/12/25, 2:35 AM
by taurknaut on 2/12/25, 2:18 AM
by kristjank on 2/12/25, 12:13 PM