10 ms·

WASM will replace containers

• malkia 2y ago
  No, it won't. Especially when comes to CPU or GPU intensive tasks... and not only that...
• tombert 2y ago
  It would be so great if WASM gives us the paradise that Java promised thirty years ago. Being able to get fast, "write once, run anywhere" would be awesome. 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.
  • mdaniel 2y ago
    We could name it the Abstract Window Toolkit and it would render the same on every platform. But then, someone would get butthurt about it having a "distinct look" and decide to make the Standard Widget Toolkit that uses native bindings. Fantastic that it stops that distinct look, with the small asterisk that you now have to ship .dll/.so/.dylib shims in your "cross platform" app I'm no wasm expert, but I find it just fantastically unlikely that they're going to beat the decades of research that have gone into the JIT in the JVM anytime soon. But, I guess if the objective is just "run this bytecode in every browser on Earth," that ship has sailed and I will look forward to more copies of node infiltrating my machines
    • tombert 2y ago
      > I'm no wasm expert, but I find it just fantastically unlikely that they're going to beat the decades of research that have gone into the JIT in the JVM anytime soon Probably not, but that's sort of orthogonal to my point. Java started as "write once run anywhere", but it has almost become the opposite of that: "write once, run it on your specific server". "Portability" is not nearly the same concern with Java as it was thirty years ago; I don't have direct numbers on this, but I would guess that a vast majority of Java code written in 2025 is either running on a server or running an Android app, neither of which are nearly as "portable" what was kind of promised in the 90's, at least not on the desktop.
      • koiueo 2y ago
        > "write once, run it on your specific server". Funny, how people forget that a "specific server" can be running Linux on bare metal ARM or a x86 container, or maybe Windows or even MacOS.
        • tombert 2y ago
          I guess what I'm trying to say is that you're not typically deploying JAR files outside of an extremely controlled environment. For a server environment, I set all the parameters I want and then I code around it. Obviously there's a lot of variation between different servers, but you typically develop your server code a specific set of servers.
          • koiueo 2y ago
            And you don't have to think about your server architecture when you run unit tests on your jar locally from your M4 MacBook. How convenient is that, huh?
      • mdaniel 2y ago
        You say that, and yet for your cited Android apps, they are built using gradle, which is written for the JVM, or using Maven, which is written for the JVM, and likely even typed inside IntelliJ (aka Android Studio) which is written for the JVM. Also, this may be splitting hairs, but Android is actually dalvik, not the JVM
        • tombert 2y ago
          That's why I deliberately said "Java", not JVM (though I think dalvik has been deprecated and it's ART now). I'm sure you can list any number of programs that are written in Java, but it certainly has not been the cross-platform standard that everyone was promised; it feels like Electron has more or less taken its mantle in the world of desktop land.
  • lylejantzi3rd 2y ago
    The Orca project is attempting to do exactly that: https://github.com/orca-app/orca https://github.com/orca-app/orca
    • mdaniel 2y ago
      > Windows 10 or later, or Mac 13 or later (Linux is not yet supported) Aww, man, they nixed my chances of trying that out on _both_ of my local machines in one fell swoop (still on macOS 12.7 because it works fine) Does this thing, really, seriously, need the most bleeding edge Darwin toys?! Come to think of it, I bet $1 it's because GHA only goes down to 13 <https://docs.github.com/en/actions/using-github-hosted-runners/using-github-hosted-runners/about-github-hosted-runners#standard-github-hosted-runners-for-public-repositories https://docs.github.com/en/actions/using-github-hosted-runne...> It seems GL is in the same boat <https://docs.gitlab.com/ee/ci/runners/hosted_runners/macos.html#supported-macos-images https://docs.gitlab.com/ee/ci/runners/hosted_runners/macos.h...>
  • ogoffart 2y ago
    > 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. https://github.com/slint-ui/slint https://github.com/slint-ui/slint
    • pjmlp 2y ago
      Still not half as feature rich as Swing, or JavaFX, since we are talking about bytecode ecosystems.
• ok_dad 2y ago
  We’re still using COBOL mainframes in 2025 in places so I’m sure whatever is the next trend in computing will be great, but I’m sure we’ll still be using k8s (and COBOL) in 2125.
  • jsheard 2y ago
    > but I’m sure we’ll still be using k8s (and COBOL) in 2125. If you want a vision of the future, imagine a bare metal hypervisor hosting Linux hosting K8S hosting V8 hosting a WASM-based IBM mainframe emulator running COBOL.
    • bbkane 2y ago
      This reminds me of the K8s keynote where Kelsey Hightower runs Fortran in K8s- https://m.youtube.com/watch?v=oNa3xK2GFKY https://m.youtube.com/watch?v=oNa3xK2GFKY . It's a fun watch!
    • tehjoker 2y ago
      It's running on a quantum computer emulating a classical computer ofc.
      • Spooky23 2y ago
        The classical computer both exists and doesn’t exist. You’d need another quantum computer to figure out the IBM bill.
• msie 2y ago
  [flagged]
  • xnx 2y ago
    > PlatformOps (formerly DevOps (formerly Ops)) team Formerly sys admin
    • p_ing 2y ago
      Formerly IT administrator, formerly Systems Analyst. Me, when I was a kid: https://www.youtube.com/watch?v=SgKiIAjtrR4 https://www.youtube.com/watch?v=SgKiIAjtrR4
    • skissane 2y ago
      > Formerly sys admin Formerly systems programmer, or sysprog for short "Config files? What are those? To change the system configuration, use these assembler macros, reassemble this module, relink the operating system and then reIPL it". So, systems programmer, because knowing assembler was part of the job description. Plus, at mainframe sites in the 1960s/1970s, it was common for sysprogs to write custom code to hook into the operating system and change its behaviour (user exits), or even to actually patch the operating system code (SYSMOD) – and assembler was the language used to do all that If we are talking about IBM mainframes specifically, by the 1970s, a lot of the operating system was written in a high level language (a PL/I dialect), but although they shipped customers the source code, they didn't ship them any compiler for the special PL/I dialect, so customers couldn't modify it by changing the source, only by disassembling the binary, modifying the assembly, then reassembling it. Plus, commonly, IBM shipped only source for the initial release, not later patches, so the customer copy of the source would gradually get out of sync with the binary. Some other mainframe vendors weren't quite so primitive, and so there was significantly less use of assembler by customers for OS customisation (e.g. I think, Burroughs, Multics)
  • dartos 2y ago
    Docker pre-kube was really great, imo. Sticking a bunch of docker containers on a box behind a reverse proxy or load balancer felt like the sweet spot of complexity and scalability for most apps.
• trescenzi 2y ago
  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 2y ago
    > … 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 2y ago
      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.
      • aftbit 2y ago
        Unless you run the build in WASM itself. Are there any self-hosting WASM build chains?
      • Capricorn2481 2y ago
        What about WASM doesn't encapsulate dependencies? Isn't it all one WASM blob at the end of the day?
      • hardwaresofton 2y ago
        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.
• tomrod 2y ago
  That would be cool. 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?
  • euroderf 2y ago
    Try the Component model.
• bloopernova 2y ago
  What sort of tooling is required for wasm? Let's say I wanted to deploy a middle tier in our app, consisting of some nodejs code that talks to an external database. 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?
  • openquery 2y ago
    You need a toolchain to compile to wasm and a runtime to run it.
• tibbar 2y ago
  The article starts out "In the year 2030, no one will remember Kubernetes", but focuses mostly on containers. Kubernetes solves a lot of problems that a runtime alone doesn't, like rolling upgrades, load balancing, etc. etc. However, focusing on the thrust of the article, which is replacing containers with code compile to WASM running in v8, it's still hard to agree. For example, apps commonly need a bunch of dependencies, WASM doesn't solve that problem, so you still benefit from building images in multiple cacheable layers. 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.
• orliesaurus 2y ago
  lol I initially thought dylibso was the author, I was mistaken. That being said - WASM has been steadily improving over time, yet it hasn't quite achieved mainstream adoption. 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. [1] https://github.com/dylibso https://github.com/dylibso
  • evacchi 2y ago
    > lol I initially thought dylibso was the author as a Dylibso employee, I am wondering what made you think that :D at Dylibso we advocate for Wasm for software extensions, rather than an alternative to containers!
    • orliesaurus 2y ago
      Because of the topic. I find you guys are the only people advocating for Wasm in general, in public.
• not2b 2y ago
  "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).
  • resonious 2y ago
    This is what I was thinking. WASM is a good replacement for containers because it doesn't have these things.
    • gchamonlive 2y ago
      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)
      • hardwaresofton 2y ago
        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).
        • pjmlp 2y ago
          https://en.m.wikipedia.org/wiki/List_of_JVM_languages https://en.m.wikipedia.org/wiki/List_of_JVM_languages https://en.m.wikipedia.org/wiki/List_of_CLI_languages https://en.m.wikipedia.org/wiki/List_of_CLI_languages https://en.m.wikipedia.org/wiki/IBM_i#TIMI https://en.m.wikipedia.org/wiki/IBM_i#TIMI Really this is only new for those that weren't around, many other examples, even older available.
• imglorp 2y ago
  "In the year 2030, no one will remember Kubernetes." 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.
  • danpalmer 2y ago
    I came here to say this. Kubernetes is an ecosystem that represents a better way of running production workloads at scale for many orgs. People already use Kubernetes for VMs, and various different container runtimes are used by different cloud providers. If WASM does replace containers (unclear to me), Kubernetes would just support WASM, and stay largely similar.
• birdiesanders 2y ago
  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 2y ago
    Anyone comes up with any shit these days, say apples will replace oranges. “ChatGPT make me sound confident”
• Humphrey 2y ago
  Disagree: While this might be the case for a handful of languages such as Rust of Go - Many lanugages need a whole lot of other stuff to run (eg, Python needs a lot bunch of dependencies).
  • mkl 2y ago
    I thought the same at first, but found Python Cloudflare Workers already run in WASM: https://developers.cloudflare.com/workers/languages/python/how-python-workers-work/ https://developers.cloudflare.com/workers/languages/python/h...
    • Humphrey 2y ago
      Ah interesting! Looks like that uses a WASM build of CPython to run your Python code - similar to how you can run python in your browser. Would you still have a heap of Python files?
• deleted 2y ago
  [deleted]
• ninetyninenine 2y ago
  Naw. 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.
  • slt2021 2y ago
    or wasm is just faster client-side javascript
    • pjmlp 2y ago
      More like return of Applets, Flash, Silverlight, ActiveX. And that is great, thanks to it is all turtles to the way down, I can have my plugins back, now running on WebAssembly, that is the only thing I care about it.
  • neom 2y ago
    ...you're essentially turning the host OS into both a resource manager and isolation boundary enforcer, which is... kind of what hypervisors were specifically designed to do, just at a different level. When the container companies were all starting to come out, I never thought it was a good idea, given what I was building I never said anything because "of course the VM guy would not like containers" - I thought many times about what an ISO+VM "container" product would look like but at the time it would have been hard to match the performance of containers even if we could have gotten the developer experience super good. VM: Cold start: ~10 seconds with an optimized ISO, Management overhead: ~256MB baseline, Consistent performance profile. K8s: Cold start, ~30-50 seconds (control plane decisions + networking setup), management overhead: 1-2GB for the control plane alone, more variable performance due to overlay networking. imo real question is: at what scale/complexity does k8 overhead get amortized by its management benefits? For a number of services, I suspect it never does. I will dutifully accept all my downvotes now.
    • openquery 2y ago
      I haven't played around with hypervisors much but the whole point of k8s is not just isolation but all the primitives the control plane gives you which you don't need to implement. Things like StatefulSet, ReplicaSet, Volumes, HorizontalPodAutoscaler, Service, DNS, ConfigMaps, Secrets, Accounts, Roles, Permissions etc. Also the container runtime which is containerd by default I believe can be switched out for micro vms like Firecracker (never done this though - not sure how painful it is).
• gigel82 2y ago
  No it won't. People primarily deploy containers for full fat native server applications containing tons of proprietary code and libraries and sometimes specialized hardware access (GPU, etc.). 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 https://www.youtube.com/watch?v=6pDH66X3ClA (just because you can make it fit, it doesn't mean you should do it).
• diego_moita 2y ago
  Hmm, not sure... 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.
  • mdaniel 2y ago
    > Yeah, AFAIK, there is no WASM compiler in WASM. What would you do with one if you had it? Run it on your wasm OS?
    • diego_moita 2y ago
      You noticed this post is about WASM replacing containers, right? So, I'd use it the same way we use compilers in containers (i.e: one single download, no installation) and would run it with a runtime like Wasmer, Wasmtime, Wasmedge, etc. Or else I could run it sandboxed in a browser as a PWA. Then you could build things in Chromebook, phone, etc.
      • mdaniel 2y ago
        > Or else I could run it sandboxed in a browser as a PWA. $ du -hs $HOMEBREW_CELLAR/gcc/* 527M /usr/local/Cellar/gcc/14.2.0_1 (nod)
• hardwaregeek 2y ago
  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
  • octopoc 2y ago
    Blazor is stable and extremely easy to use. It’s just a little slow to load, although there are ways to mitigate that.
    • catmanjan 2y ago
      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 2y ago
        It depends on the application. And gp was talking about stability and ease of use, not speed.
  • otterley 2y ago
    > When are we actually getting this future? Around the same time Linux is ready for the desktop.
    • milesrout 2y ago
      Unlikely as that was whenever you stopped having to write Xorg.conf by hand, ie the mid 2000s.
      • pjmlp 2y ago
• ninetyninenine 2y ago
  You underestimate developers. WASM will never replace containers. People will be running wasm inside of containers. That's what will happen.
  • aftbit 2y ago
    Containers will never replace VMs either. People will be running WASM inside of containers inside of VMs.
    • ninetyninenine 2y ago
      Where did this extra VM come from?
      • reissbaker 2y ago
        Well, AWS, typically.
        • ninetyninenine 2y ago
          Are you sure? Are those instances a VM or another docker container? Does anyone from amazon know?
          • reissbaker 2y ago
            It's a custom VM they wrote called Nitro: https://aws.amazon.com/ec2/nitro/ https://aws.amazon.com/ec2/nitro/
          • threeseed 2y ago
            Depends what part you mean. AWS Fargate / Lambda are Firecracker VMs. EC2 are normal VMs.
      • LeFantome 2y ago
        An OCI container (what people call Docker containers) are just applications that run on a Linux kernel. That is, you need a Linux kernel underneath for the containers to run on. More often than not, that Linux kernel is running in a virtual machine. When you run Docker Desktop on your Windows or macOS machine, how do you think it runs that Alpine Linux container? It works because there is a virtual machine running Linux that all the Docker containers run on top of. If you are running Linux directly on real hardware, your containers do not need a VM. Everywhere else, they do.
• krackers 2y ago
  https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
• markhahn 2y ago
  um, yeah, like everything is a jvm today.
• deleted 2y ago
  [deleted]
• pluto_modadic 2y ago
  kubernetes is an endless employment engine for operations staff (it's kinda the opposite of "anybody can write react, so react devs are now cheaper", instead you're constantly maintaining a piece of junk k8s stack). 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.
• Thaxll 2y ago
  "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 2y ago
    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 2y ago
      WASM will be that but tenfold surely? You would need to program against a completely new interface.
      • hardwaresofton 2y ago
        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. [0]: https://github.com/WebAssembly/WASI/tree/main/wasip2 https://github.com/WebAssembly/WASI/tree/main/wasip2
        • pjmlp 2y ago
          Basically CORBA with RMI and .NET Remoting.
• taurknaut 2y ago
  No. Wasm is not useful enough yet. Neither are containers.
  • openquery 2y ago
    > Neither are containers. This is demonstrably false.
    • deleted 2y ago
      [deleted]
    • taurknaut 2y ago
      Eh. Containers will have their day.
  • zfg 2y ago
    How else am I supposed to use a Visual Basic 6 clone written in C# in my browser? https://bandysc.github.io/AvaloniaVisualBasic6/ https://bandysc.github.io/AvaloniaVisualBasic6/ https://github.com/BAndysc/AvaloniaVisualBasic6 https://github.com/BAndysc/AvaloniaVisualBasic6 WebAssembly brings all languages to the browser and that's a good thing. I can write applications for the desktop in any language, I should be able to do the same thing in the browser. WebAssembly makes that possible.
    • pjmlp 2y ago
      Back in the day you would have used .NET plugin for browsers, which got replaced by Silverlight plugin, nowadays it is WebAssembly, really nothing new per se.
      • zfg 2y ago
        Except that it's implemented in all browsers with nothing extra to install. All third party browser plugins failed eventually.
        • 2y ago
• paulgb 2y ago
  > 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 2y ago
    > Bun Nit: bun uses javascriptcore
• deleted 2y ago
  [deleted]
• deleted 2y ago
  [deleted]
• h0l0cube 2y ago
  > You can compile several languages into WebAssembly already. Languages that can't be compiled will eventually have their own interpreters compiled to WebAssembly. 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.
• chambers 2y ago
  I found WASM slower than expected. I wrote some WASM logic functions recently which I thought would perform better than their native JS equivalent. For example, take a large array and "pivot" it in 10ms instead of a 100ms. 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
  • fancyswimtime 2y ago
    the answer will be; depends what ur doing. There is a cost communicating with a worker
    • deleted 2y ago
      [deleted]
  • ridiculous_fish 2y ago
    At $WORK we use SQLite in WASM via the official ES module, running read-only in browser. The performance is very poor, perhaps 100x worse than native. It's bad enough that we only use SQLite for trivial queries. All joins, sorting, etc. are done in JavaScript. Profiling shows the slowdown is in the JS <-> WASM interop. This is exacerbated by the one-row-at-a-time "cursor" API in SQLite, which means at least one FFI round-trip for each row.
    • chambers 2y ago
      Yup, I've tested and seen WASM SQlite's slowness myself. But I don't think it's a SQLite problem per se. I heard WebSQL, which used SQLite, was at least 10x faster than WASM SQLite. Probably even more.
• bocahtie 2y ago
  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 2y ago
    That is what I was thinking of too! From 2014: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death....
    • tantalor 2y ago
      Yes! I was trying to search for this but I couldn't remember the name.
  • afiori 2y ago
    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
• smarklefunf 2y ago
  yeah but does wasm really work on mobile?
• gnarbarian 2y ago
  we can only hope.
• algorithmsRcool 2y ago
  I just don't see it. WASM requires throwing away all the decades of x86/ARM compiler work in ecosystems like Java, .NET and C++ and placing all trust in the WASM runtime/V8 to perform as well as them.
  • zfg 2y ago
    It's doesn't. It's just another compilation target along side x86 and ARM and friends.
    • algorithmsRcool 2y ago
      Yes, but now you are going through another translation (aka V8) layer in order to get down to x86 or ARM. You just have to hope that the optimizer of this translation layer is at least as smart as what you had before.
      • zfg 2y ago
        How is that worse than JavaScript? x86 and ARM compilation don't go away. WebAssembly is an additional option.
• 0dayz 2y ago
  Forgive me but I've heard the heralding new age nay revolution of wasm is coming anyday now and it hasn't and probably won't. 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).
• ianburrell 2y ago
  One advantage of containers is that run lots of software with it. Take old Perl application, wrap it in container, and then run in the cloud. Keep that old binary application that somehow lost the source for. 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.
  • andrew_rfc 2y ago
    Speaking of Perl: https://news.ycombinator.com/item?id=43017739 https://news.ycombinator.com/item?id=43017739
• kortex 2y ago
  It really won't. For some use-cases, yes. > 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.
• ein0p 2y ago
  I've yet to see a single example of WASM in the wild. How is it supposed to "replace" anything, if nobody is using it?
  • mdaniel 2y ago
    1Password actually bundles it with everything they ship (browser, desktop, even their golang cli): https://github.com/1Password/onepassword-sdk-go/tree/v0.1.7/internal/wasm https://github.com/1Password/onepassword-sdk-go/tree/v0.1.7/... and then use extism to cross over its boundary https://github.com/1Password/onepassword-sdk-go/blob/v0.1.7/internal/shared_core.go#L132 https://github.com/1Password/onepassword-sdk-go/blob/v0.1.7/... They compiled their rust libraries to wasm and it allows reuse of those rust bits across everything The other famous example I know of, but haven't used, is Figma https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/ https://www.figma.com/blog/webassembly-cut-figmas-load-time-...
  • zfg 2y ago
    You've likely had WebAssembly running in your browser but didn't even realize it. Firefox also lets add-ons run WebAssembly modules which is something that uBlock Origin has made use of for a long time: https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-best-on-Firefox https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b...
• fngjdflmdflg 2y ago
  This post is really puzzling. How do I use libraries with WASM? Lets say I wrote a nodejs app, seemingly I will need to bundle not just node_modules but also the entire nodejs runtime to make it run. Why would I do this? How does another developer make changes? If there is some way to specify what dev tools to download, what is the difference between that and docker? If you aren't doing anything complicated, docker is just a good way to set up your dev dependencies. If you are doing something complicated I doubt WASM is going to help you.
• t2o34h234234 2y ago
  Suprised Nix isn't mentioned here.
• zombiwoof 2y ago
  So dumb - Shoresy
• deleted 2y ago
  [deleted]
• stackskipton 2y ago
  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-kubernetes/ 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.
  • sleepybrett 2y ago
    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.
• remram 2y ago
  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?
• sleepy_keita 2y ago
  I actually tried doing this a couple weeks ago. Rust on Cloudflare Workers. It didn't go well -- compiling to wasm disables a lot of Rust features, to the point where it just didn't make sense anymore. I gave up after trying to get some crypto stuff working. I eventually switched to using raw JS because Cloudflare Workers exposes the Web Crypto API, but next time I want to run Rust serverlessly, I'm just going to put it on Lambda, compiled to a regular binary.
• quotemstr 2y ago
  Right. Moore's law has made too much progress. We must claw back some slowness! Let's take code that could run securely at full speed and run it in emulation at half the speed instead. That'll keep those menacing hardware performance improvements at bay a little longer.
• tbrownaw 2y ago
  > In the year 2030, no one will remember Kubernetes. 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.
• moribvndvs 2y ago
  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.
  • mdaniel 2y ago
    Preach it, because document/literal SOAP and WSDL are The Way, The Truth, and The Light!
  • invalidname 2y ago
    Exactly. It's like the JVM circa 2004. Without all the observability and features we have today and half the performance/reliability/security.
    • pjmlp 2y ago
      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.
  • RantyDave 2y ago
    OMG I hated DCOM so thoroughly.
  • cheesekunator 2y ago
    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 https://developers.cloudflare.com/durable-objects) can reduce latency they might have the winning product.
    • crabmusket 2y ago
      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.
• xyst 2y ago
  Definitely a dead take. WASM has its merits but it’s not a panacea.
• danpalmer 2y ago
  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.
  • TZubiri 2y ago
    Wasm: client, user's device Containers: server, dev's device Cmon OP try to keep up
    • danpalmer 2y ago
      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 2y ago
        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 2y ago
• mikewarot 2y ago
  Capabilities based Operating Systems will replace containers. WASM is a stepping stone to help the world better impedance match them conceptually. If someone tacks on file system access to WASM, the whole system becomes worthless.
  • jdougan 2y ago
    A while back someone claimed to me that WASI was structured as capabilities. True/false?
    • mikewarot 2y ago
      True WASI Design Principles Capability-based security WASI is designed with capability-based security principles, using the facilities provided by the Wasm component model. All access to external resources is provided by capabilities. There are two kinds of capabilities: Handles, defined in the component-model type system, dynamically identify and provide access to resources. They are unforgeable, meaning there's no way for an instance to acquire access to a handle other than to have another instance explicitly pass one to it. Link-time capabilities, which are functions which require no handle arguments, are used sparingly, in situations where it's not necessary to identify more than one instance of a resource at runtime. Link-time capabilities are interposable, so they are still refusable in a capability-based security sense. WASI has no ambient authorities, meaning that there are no global namespaces at runtime, and no global functions at link time. Source: https://github.com/WebAssembly/WASI/blob/main/README.md https://github.com/WebAssembly/WASI/blob/main/README.md
• oppositelock 2y ago
  Why does anything need to replace anything? 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.
• LeFantome 2y ago
  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 2y ago
    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 2y ago
    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.
• stlava 2y ago
  > In the year 2030, no one will remember Kubernetes. 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.
• jb_gericke 2y ago
  WASM solves a very different problem to Kubernetes, and you can happily run, scale and orchestrate WASM binaries on Kube.
• sargun 2y ago
  No it wont. It's incredibly hard to build out a fully useful version of the Linux APIs, as shown to us by Cygwin, and WSL. Even if you built out a similar set of APIs, Linux itself offers a ridiculous set of interaction points where applications can tie together (for example, I can use inotifywatch to copy files out of my container as they're written). I feel like what you'll end up with is something like gvisor running on top of WASM. In which case, what did we gain from VMs at all?
• iLemming 2y ago
  I vividly remember how I was young and stupid, and some people claimed that web components would replace everything. There was a guy in another team who kept bashing us for building things on top of React because "you'll see, very soon, in just a few months...just like you're having to rebuild from Angular, and someone before you had to rebuild from Backbone/jQuery..." 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.
• dowager_dan99 2y ago
  Some pretty bold claims with what I felt was shaky justification and a simplistic understanding of the foundations. >> 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.
• jpillora 2y ago
  They're different things, solving different problems: - 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
• awill88 2y ago
  I think this author is so far off the mark that it makes me wonder if they were high when they wrote this
• pjmlp 2y ago
  It is so funny seeing folks reinventing Java EE application servers, or IBM i, z/OS.
• c0balt 2y ago
  > In the year 2030, no one will remember Kubernetes. 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.
  • aitchnyu 2y ago
    I believe at least one consulting company in this Indian city is still training new graduates in COBOL and setting them up with dead end careers.
    • pjmlp 2y ago
      COBOL just had a new release, COBOL 2023 is the most recent standard. Also does objects nowadays. Additionally, given all the AI prompts being used nowadays writing long English texts instead of proper programming, COBOL was actually a language ahead of its time.
      • aqueueaqueue 2y ago
        Ah COBOL, Fortran, Perl and PHP.... all chant: "No no.... we're actually modern now guys!!!"
        • afiori 2y ago
          Being modern has little to do with being used, at least COBOL and PHP have for sure strong footholds in many places
• stego-tech 2y ago
  While I don’t doubt the utility of WebAssembly, I do have to kind of roll my eyes at the ignorance of history going on. 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.
• deleted 2y ago
  [deleted]
• nunez 2y ago
  You can totally run wasm via Docker through the wasm runtime. Given this, unfortunately, you will still need to admin Kubernetes.
• colonial 2y ago
  Are WASM and containers not fundamentally different things? 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!
• phendrenad2 2y ago
  This has to be the highest word-count-in-replies-on-hackernews-to-word-count-in-entire-blog-site ratio ever.
• SEJeff 2y ago
  For folks interested in the current state of the art on sandboxing, here is a stab one of my former coworkers did: https://github.com/firedancer-io/firedancer/blob/main/src/util/sandbox/fd_sandbox.c 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.
• Evidlo 2y ago
  Does anyone remember a presentation on YouTube that described a hypothetical future where everything will be running inside a VM in a browser?
  • akdas 2y ago
    The Birth and Death of Javascript. One of my favorites! https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
    • Evidlo 2y ago
      Thanks, that was it!
• WhereIsTheTruth 2y ago
  Just like with systemd ruining every cloud infrastructures, here we go with WASM Who wants everyone to be forced to use the same BigTech slop?
• spintin 2y ago
  [dead]
• hansmayer 2y ago
  The second paragraph is perhaps something you experience on a very small team in a very small company, but definitely not everyone's day-to-day experience and it sounds like the author would like to impose their own limited experience onto the whole industry. In a lot of companies the DevOps usually jump in and handle the entire management of the pipeline, including the build and release of containers. For most of developers, they still get to simply ship their features, I've rarely met classic developers 'optimising Docker build times'. Secondly, great technologies have intrinsic qualities and potential which get recognised instantly. Now there may be some hype following them, for sure, but it is these intrinsic qualities which silently drive the adoption of the new tech, not the hype. People starting building extensions and add-ons and more complex systems and suddenly you see it everywhere. WASM has been around for a few years now / anyone seen it make its way quietly into our working processes yet?
  • aqueueaqueue 2y ago
    I think WASM is misfortune because for most websites (forget backend for a moment!), anything it can do can be done better and faster using as JS and server side split. JS gets heavily optimised by V8. And add in the download time for the WASM and the learning curve and it isn't too attractive. It needs something to make it a must have for some area of adoption. I just don't see it yet.
• kryptiskt 2y ago
  In practice the problem containers solve is to bundle an application with its environment so that it will work the same on the developers machine and in production and in five years time when the servers are replaced with new ones running another distro. 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?
• poisonborz 2y ago
  Surely this will be the year of WASM!
• LunicLynx 2y ago
  Someone does not understand what kubernetes is. Kubernetes or something like it will continue to exist.
• udev4096 2y ago
  Containers are not going away anytime soon. I feel like this is nothing but a clickbait post. There are crazy amounts of innovations happening in the CNI space, such as bootc, katacontainers, etc. Hundreds of CNCF projects (envoy and istio just from top of my mind) are being used world wide which mostly have built upon k8s. Why do you think they would stop to use an immature runtime whose goal isn't even the same as containers?
• bayindirh 2y ago
  This blog post's promise is all "pink fluffy unicorns", but for a single use case: "Long running containers powering microservices, probably in bigger installations, for consumer facing applications and APIs". 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.
• syrusakbary 2y ago
  The article is completely on point. 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 [1] https://wasix.org/ https://wasix.org/
• weinzierl 2y ago
  Statically compiled portable binaries will replace containers. 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?
  • afiori 2y ago
    Statically linked binaries are perfect to run in lightweight containers
• fergie 2y ago
  > You have the option of writing your worker in JavaScript/TypeScript, or compiled WASM. Is there any compelling reason not to just compile TypeScript to WASM? Why should it have JavaScript as its compile target?
  • MortyWaves 2y ago
    The closest to that is AssemblyScript which is terrible and painful to use with a broken developer tooling story.
• jeffy2025 2y ago
  [dead]
• cprogrammer1994 2y ago
  Confusing hammers with drills is a big mistake. Similarly, the problems WASM solves and the problems containers solve have little in common.
• justforfun2025 2y ago
  [dead]
• cess11 2y ago
  Can I run ephemeral Oracle databases and JBoss instances and Tibco EMS as WASM as part of a CI/CD flow? No? Then it's not comparable to containers. 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.
• ACELARE 2y ago
  I need contributers for this Wikipedia page - https://en.wikipedia.org/wiki/User:Dr.SeemaMidha https://en.wikipedia.org/wiki/User:Dr.SeemaMidha Fellow Wikipedians may show their interest in the comment section.
  • SeemaMidha 2y ago
    How May I Help You?
    • SeemaMidha 2y ago
      The Wiki page you want to create is disallowed by the Wiki Bots. The exact uniform resource location of the concerned Wiki page is https://en.wikipedia.org/w/index.php?title=User:Dr.SeemaMidha&oldid=1274649221 https://en.wikipedia.org/w/index.php?title=User:Dr.SeemaMidh... The displayed uniform resource location of the concerned Wiki page is https://en.wikipedia.org/wiki/User:Dr.SeemaMidha https://en.wikipedia.org/wiki/User:Dr.SeemaMidha
• nottorp 2y ago
  microservices, serverless... Truly buzzword compliant, this article.
• bborud 2y ago
  There is one thing that makes WASM very awkward: projecting APIs into a sandbox. 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)
  • euroderf 2y ago
    Go development is ill-documented but just barely tolerable. Skip the BytecodeAlliance docs. Install WasmCloud's 'wash', write your WIT file, run 'wash build', and good luck with the error messages.
• kodama-lens 2y ago
  I don't think that WASM will replace containers. They will continue to move closer to each other but still have their advantages in different fields. 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
• lakomen 2y ago
  [dead]
• mabedan 2y ago
  > by deploying WASM in V8 sandboxes, you get all of the developer benefits of microservices with all of the runtime benefits of monoliths No oversimplification to see here.
• aartav 2y ago
  "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." 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.
  • diggan 2y ago
    Who exactly has promised it's "coming soon"? People like to make arguments against imaginary arguments for some reason. Besides, you can already send data from/to Browser<>WASM context which seems to at least solve most use cases people was imagining for WebAssembly back when it was just asm.js.
• deleted 2y ago
  [deleted]
• sebstefan 2y ago
  >A very obvious argument against WASM succeeding is the Java Virtual Machine (JVM). It's almost exactly the same promise: write once, run anywhere. [...] The biggest limitation is that JVM bytecode cannot run in a web browser 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?
• kristjank 2y ago
  This webdev notion of abstracting 30 layers of complexity just to run bytecode is borderline lobotomizing and should be blamed for 8,000,000,000 Bytes of RAM not sufficing for a slightly-above-average desktop computer nowadays.
• KaiserPro 2y ago
  Unikernels were meant to take over the world, the problem is, the extra bits of faux linux that docker provides are usually time savers. 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.
• bovermyer 2y ago
  It's mentioned in passing in the article, but I'm intrigued by the author's mention of how Cloudflare Workers interoperate. Besides the official documentation, are there any articles anyone can recommend on this topic?
  • kentonv 2y ago
    Cloudflare Workers run in V8 isolates, which are much lighter-weight than containers, with the ability to run thousands in the same process, and start up new ones quickly on-demand. For Cloudflare it's usually easier to start your application on the machine where it is requested, than to try to route to a machine where it's already running: https://developers.cloudflare.com/workers/reference/how-workers-works/ https://developers.cloudflare.com/workers/reference/how-work... The API construct that lets a worker call another worker (in the same process, in fact, in the same thread) is a Service Binding: https://blog.cloudflare.com/service-bindings-ga/ https://blog.cloudflare.com/service-bindings-ga/ This is one type of "binding" or "live environment variable" or "capability". You configure it at deploy time, and then at runtime you can just do `env.SOME_SERVICE.fetch(request)` to call to your other worker: https://blog.cloudflare.com/workers-environment-live-object-bindings/ https://blog.cloudflare.com/workers-environment-live-object-... There's a fancy RPC system, although it's (for now) centered on JavaScript so not as relevant to Wasm users: https://blog.cloudflare.com/javascript-native-rpc/ https://blog.cloudflare.com/javascript-native-rpc/ (I'm the tech lead for Cloudflare Workers.)
    • bovermyer 2y ago
      Interesting. I only have a single Worker, but maybe I should experiment more with them. Thank you!!
• thesz 2y ago
  This is a post about shiny new thing author loves. 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/ 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? [2] https://en.wikipedia.org/wiki/Dataflow_architecture https://en.wikipedia.org/wiki/Dataflow_architecture
• gedw99 2y ago
  My golang WASM is half the speed of my golang native. That’s double server costs. It’s golang so maybe that’s why ?
• tonymet 2y ago
  My boomeritis flares up when I hear someone trying to sell me on 10x-ing instructions . I think we need a new unit of inefficiency called Matrioschkas . The Swedes call this Torta-på-Torta or a cake in a cake (in a cake..)
• il-b 2y ago
  WASM just moves vulnerabilities to the wrapping code. If you use FS, then you still have to prevent the wrapper from stealing your /etc/passwd, so container it is
• kukiTsui 2y ago
  You wouldn't want to miss MoonBit if you are interested in WASM. It is the most WASM-optimized language, quite promising. https://www.moonbitlang.com/ https://www.moonbitlang.com/