Michael Irwin from Docker here (and author of the blog post too). Happy to answer your questions, hear feedback, and more!
Why would I want to compile my app to WASM if it's not running in a browser?
The Docker+WASM Technical Preview
21–30 of 178 posts
Re: The Docker+WASM Technical Preview
#22Earlier quoted context omitted.
maybe a naive question: is there a way to run some form of docker in the browser? It could be a great education / demo tool
Great question! There isn't a way to run Docker directly in the browser. But, there are tools (like Play with Docker at play-with-docker.com) that lets you interact with a CLI in the browser to run commands against a remote cloud instance. I personally use this a lot for demos and workshops! But... certainly a neat idea to think about what Wasm-based applications could possibly look like/run in the browser!
Hey! Peter from Snaplet here. This is really exciting stuff. We created the OSS postgres-wasm (https://github.com/snaplet/postgres-wasm) example a few weeks ago. An idea I'm playing around with is something like:
1. Visit https://postgresql.com/try?version=14.x
2. Visit https://nodejs.com/try?version=16.15.1
3. Visit https://edit.com
Re: The Docker+WASM Technical Preview
#23Great work, WASM is the future! But on the other hand I'm not really happy with the fact that I'm waiting for GC and DOM access since 2019 or something like that and it doesn't seem like we're getting close
What compromises does WASM have relative to plain old native code?
There are a few things we're excited about, many of which we fully recognize are used in marketing/buzzword bingo. But, they really are around portability (compile to a Wasm module and run on any architecture), isolated sandboxing (leveraging much of the research and investment used to protect web browsers), and super fast startups (obviously depends on the app too).
There are a few limitations right now, some of which lack of built-in garbage collection and multi-threading. You also have to use a language that can completely compile to Wasm, making it hard (sometimes impossible) to leverage already built libraries/binaries.
But... the tech is growing rapidly and we're excited for it! Happy to dive in or answer more questions if you'd like!
Re: The Docker+WASM Technical Preview
#24Michael 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’m curious about this too.
I wonder if it could make testing frontend code that uses WASM (but not DOM) fast and easy since you wouldn’t need to fire up a complete browser environment.
I’m not sure that it’s possible at the moment. In the past when I needed to test a WASM integration, I ended up using that approach and it was kind of a pain not to get immediate feedback on the WASM code’s API tests since it was essentially only testable through the complete integration environment.
I like integration tests, but I like smaller and faster test suites for easing development in some conditions as well.
You can currently test a WASM-targeted API if you use unit tests or other language-level testing approaches, but you won’t get the constraints of the WASM runtime as far as I know. Maybe the lack of garbage collection could be a critical constraint to test against.
I suppose you could even test dynamically linked binaries without a browser as well.
I’m sure there’s far more to it that I’m not aware of, and maybe testing really isn’t that useful of a feature here — I’m just guessing based on my own experience.
Re: The Docker+WASM Technical Preview
#25Earlier quoted context omitted.
Great question! There isn't a way to run Docker directly in the browser. But, there are tools (like Play with Docker at play-with-docker.com) that lets you interact with a CLI in the browser to run commands against a remote cloud instance. I personally use this a lot for demos and workshops! But... certainly a neat idea to think about what Wasm-based applications could possibly look like/run in the browser!
Hey! Peter from Snaplet here. This is really exciting stuff. We created the OSS postgres-wasm ( https://github.com/snaplet/postgres-wasm ) example a few weeks ago. An idea I'm playing around with is something like: 1. Visit https://postgresql.com/try?version=14.x 2. Visit https://nodejs.com/try?version=16.15.1 3. Visit https://edit.com Edit.com opens a text-editor and terminal where I have access to the NodeJS binary…
I used https://wasm.supabase.com/ to make sure some SQL commands I was writing for a blog were correct. It was super useful and faster than starting docker desktop, looking for the postgres image name, starting it etc..
I miss a feature where I can share a link with some data/schema pre-seeded (maybe from a gist?)
Re: The Docker+WASM Technical Preview
#26Earlier quoted context omitted.
maybe a naive question: is there a way to run some form of docker in the browser? It could be a great education / demo tool
Great question! There isn't a way to run Docker directly in the browser. But, there are tools (like Play with Docker at play-with-docker.com) that lets you interact with a CLI in the browser to run commands against a remote cloud instance. I personally use this a lot for demos and workshops! But... certainly a neat idea to think about what Wasm-based applications could possibly look like/run in the browser!
Is it possible to sandbox the host system from the guests in WASM?
Are there namespaces and cgroups and SECCOMP and blocking for concurrent hardware access in WASM, or would those kernel protections be effective within a WASM runtime? Do WASM runtimes have subprocess isolation?
Re: The Docker+WASM Technical Preview
#27Earlier quoted context omitted.
What compromises does WASM have relative to plain old native code?
There are a few things we're excited about, many of which we fully recognize are used in marketing/buzzword bingo. But, they really are around portability (compile to a Wasm module and run on any architecture), isolated sandboxing (leveraging much of the research and investment used to protect web browsers), and super fast startups (obviously depends on the app too). There are a few limitations right now, some of whi…
Yeah it's a super interesting topic, thanks for sharing!
A couple questions:
1. What use cases are you targeting, or which ones do you think have the most benefits from wasm?
2. What tools/stack are you currently using, or which ones do you think are the most promising?
Re: The Docker+WASM Technical Preview
#28Earlier quoted context omitted.
Hey! Peter from Snaplet here. This is really exciting stuff. We created the OSS postgres-wasm ( https://github.com/snaplet/postgres-wasm ) example a few weeks ago. An idea I'm playing around with is something like: 1. Visit https://postgresql.com/try?version=14.x 2. Visit https://nodejs.com/try?version=16.15.1 3. Visit https://edit.com Edit.com opens a text-editor and terminal where I have access to the NodeJS binary…
I used https://wasm.supabase.com/ to make sure some SQL commands I was writing for a blog were correct. It was super useful and faster than starting docker desktop, looking for the postgres image name, starting it etc.. I miss a feature where I can share a link with some data/schema pre-seeded (maybe from a gist?)
We're working on it. We'll allow you to export (via SQLite) and import (via SQLite), and even promote to a preview database: https://docs.snaplet.dev/references/preview-databases
Snaplet.dev is a tool that copies, minimizes and transforms your production database into a shareable file.
Re: The Docker+WASM Technical Preview
#29Very nice. More lightweight virtualisation is a thing to celebrate :)
Re: The Docker+WASM Technical Preview
#30Great work, WASM is the future! But on the other hand I'm not really happy with the fact that I'm waiting for GC and DOM access since 2019 or something like that and it doesn't seem like we're getting close
What compromises does WASM have relative to plain old native code?
One thing I've seen come up a lot is that people got used to treating containers as a portable unit of code, and then Apple Silicon threw a wrench in that assumption. A WASM module is the same regardless of whether you're running it on arm, amd, or anything. (Alas, the cost of this portability is that it's 32-bit)