Live data from Hacker News

The Docker+WASM Technical Preview

docker.com

141–150 of 178 posts

Re: The Docker+WASM Technical Preview

#141
post #109

Earlier quoted context omitted.

"Docker+Wasm" is just a shorthand for the Technical Preview build, which allows you to build both traditional container apps, as well as Wasm apps. Behind the scenes, we try to let Wasm apps be developed largely without interference from any container technology — just giving you a good local environment you can use to code against. That said, if you want, we do offer the ability to run Wasm apps within a Docker Comp…

It might be easier if you simplify it to, "We're trying not to be just the app you choose to run containers with. You can now use non-container runtimes like WASM."

So docker+WASM does not build a Linux container image with the WASM application inside but it builds a WASM application packaged as a docker image and started with docker run instead of (say) an ELF or Windows or Mac binary started with the OS exec, whatever it is?

If this is the case I'd leave docker outside the name of the technology. I imagine the confusion. At least one customer of mine doesn't fully get the difference between a docker image and a VM yet, after years they are using docker in production.

Re: The Docker+WASM Technical Preview

#142
post #117

Earlier quoted context omitted.

Seems promising. I think, based on what I read in this, that most folks don't know how challenging working with WASM is.

That’s our experience as well… This Technical Preview is an early downpayment, and we’re definitely looking for feedback on how one may could make the Wasm development experience better!

It's still not clear to me, so can you bundle source code into your Dockerfile and just have compilation being part of the docker compose step?

Re: The Docker+WASM Technical Preview

#143
post #38

Earlier quoted context omitted.

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

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 c…

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?

Re: The Docker+WASM Technical Preview

#145

Does anyone have a good explanation for what Docker+WASM actually is? This announcement explains what WASM is and what Docker is, but I already knew both of those and am still confused about what Docker+WASM is. Is it just wrapping a WASM binary in a Docker container?

"Docker+Wasm" is just a shorthand for the Technical Preview build, which allows you to build both traditional container apps, as well as Wasm apps. Behind the scenes, we try to let Wasm apps be developed largely without interference from any container technology — just giving you a good local environment you can use to code against. That said, if you want, we do offer the ability to run Wasm apps within a Docker Comp…

I’ve been able to do this with VS Code Dev containers already. What issue is Docker trying to solve?

Re: The Docker+WASM Technical Preview

#146

Earlier quoted context omitted.

I guess it's a wasm runtime. Basically a way to execute a wasm binary just like you use docker to execute a x64 binary

Except that would've been too easy to understand, and instead seems like they're using wasmedge anyway. Needlessly confusing, why do companies do this?

A reason could be standardised build/deployment/testing.

Re: The Docker+WASM Technical Preview

#147
post #129

Earlier quoted context omitted.

Wasm = just a bunch of bytecode executing in a VM / a sandbox. Even with JIT, it will still be slower than the native code. And since it is a sandbox.. either you, or your friendly wasm interpreter (via. wasi etc...) needs to provide the system access APIs for various things like storage/filesystem access, hardware acceleration via. GPU, TPU etc.. And some of the standard APIs we take for granted.

Is WASM typically interpreted? I would have assumed one of the advantages of an assembly language is it would be easy to JIT compile down to machine code.

That depends on the runtime. Some runtimes like wasmtime support both JIT and AOT compilation.

And for places where you can't use JIT compilation (like iOS... - which is where most of the users/developers of our app were) there are interpreters like wasm3.

Re: The Docker+WASM Technical Preview

#149
post #132

Does anyone have a good explanation for what Docker+WASM actually is? This announcement explains what WASM is and what Docker is, but I already knew both of those and am still confused about what Docker+WASM is. Is it just wrapping a WASM binary in a Docker container?

The missing piece. WASM, specificially WASM run time environments, have the potential to replace containers in the future. If you can target WASM with Go, Rust, Python, C, C++ ... then you don't need containers at all. BTW, the two WASM runtimes jockeying for position are wasmtime and wasmer. It looks like Docker is getting behind wasmtime.

The article states that they're using the wasmedge[0] runtime actually.

[0]: https://github.com/WasmEdge/WasmEdge/

Re: The Docker+WASM Technical Preview

#150
post #7

Michael Irwin from Docker here (and author of the blog post too). Happy to answer your questions, hear feedback, and more!

What problem is this solving?

I am thinking isomorphic (share libraries between frontend and backend) but in a language of your choice instead of JS.
Post reply on HN