[mikesir87]

Depends on which "this" you're referring to. We (Docker) are trying to make it easier for developers to use the tools and capabilities they know and love to build, share, and run Wasm applications.

As far as Wasm itself, it's designed to provide a fast, lightweight, secure, and portable binary format. While it was originally designed to help bring native code to the browser, it's quickly spreading to the server side. Many folks are using it for edge/IoT, but it's growing into other areas (saw demos today of even using it in databases as psuedo stored procedures). Happy to dive in more if you have more questions!

[Twirrim]

I'm honestly really confused about the specific role docker is playing here.

What, exactly, is Docker doing? Is it compiling the application? Is it making a runtime for the wasm binary? Is it being the runtime for the wasm binary, so the end user builds through whatever usual build processes and gets a binary they can then easily run?

If the wasm binary is lightweight and portable, why is docker useful?

edit: Given the other comments about "what problem does this solve" I think maybe the blog post has missed its mark slightly

[VWWHFSfQ]

Yeah. Not trying to be cynical, but this feels like someone at Docker said "we need to have a WASM story" and this is what they came up with. I really don't see the point.

[petilon]

I didn't get anything from that. My question was not about WASM but Docker+WASM project. Why problem does it solve?

[mikesir87]

Sorry for the delayed response, but the problem we're trying to help solve is how to help lower the barrier of entry to using Wasm apps leveraging the tool many developers are already using. As an example example, with Docker+Wasm you can use a Dockerfile to build the app in a container image, distribute the Wasm bundle as an OCI artifact, and test it locally using the Wasm runtime. While the ability to build using containers has existed all along, the ability to actually run the Wasm app locally side-by-side your other containers (and leverage the same container network) is new. Hope that helps!

[pmontra]

This should be the copy of the announcement. Finally it's clear what it does. The announcement doesn't explain at all what docker + WASM is.

Summary of summary: Dockerfile -> docker build -> docker container with the WASM app and runtime inside -> docker push/pull -> docker run container.

However, even if I never compiled anything to WASM I think that it was already possible to build an image with a WASM container and runtime inside (as for any other language/runtime.) So what's the friction this is removing from the process?

[politelemon]

That does help thanks. It's still all a bit abstract to me because I (like many others) are still not familiar with WASM itself so this next step is probably going to go unappreciated for a while.

I'm a bit surprised by several comments in this post talking about how WASM could replace containers but I don't have the context around it

[saidinesh5]

Easy orchestration and deployment is the only thing I can think of. Because of docker's infrastructure.

But tbh if orchestration is really the concern, Docker + wasm seems less efficient than having a dedicated app that can orchestrate multiple wasm modules within the same process. But maybe that's something docker can solve later as the actual requirements emerge.

[synergy20]

the only thing I see is that after wrapping wasm inside a docker you can leverage all those docker tools(k8n,etc)? the docker solves portability and scalability issues with a reasonable overhead, so wasm hides inside docker can benefit from some?