Wasmer is an application-based container while Docker is a OS-based container.
Because of that some of the things that you posted are a bit hard to compare.
We believe that by having a VM (based on a industry adopted specification such as WebAssembly) we can control much more granularly both execution (CPU, memory) and the runtime interoperability with the system (networking, file system, ...), solving most of the issues that Docker containers have
I don't think we're using container system similarly. I'm using the term "Container" in the way Docker describes:
>A container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another. A Docker container image is a lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries and settings.[0]
If you cannot package system tooling, system libraries, and configuration with your software I don't think what you're building is a container system. If you also loose the sorcery benefits docker's network namespaces and volume drivers you're loosing a lot of functionality that docker provides.
I wouldn't call the JVM, RVM, V8/SpiderMonkey, cPython, and any other language VM a "container system" even though many of them allow you to set up platform isolation, restriction, and sandboxing.
I use "container" to reference a technology that allows me to build, package, ship, and orchestrate the execution of these units.
With all respect- Docker packages a known code stack in a box. WASM creates a whole new code stack.
Docker, with all its problems, solves a huge problem for the enterprise. WASM, cool as it is, creates a new one.
I would love to see a WASM + unikernel builder, and some lightweight node scheduler that could plug into kubernetes, so you could run thousands of WASM packages on a node within a k8s cluster, rather than 10s of containers. That increase in leverage would justify the new code stack risk.
JVM requires almost all your stack to be rewritten for it.
Because WebAssembly permits languages to be usable in the web, almost any other language (C, C++, Rust, Go and even Java) is now working to be compiled to WebAssembly.
Therefore you don’t need to adapt your stack to run it in Wasmer :)
Although your point is completely right, once your application is in wasm perhaps you can use directly a wasm vm (wasmer) instead of another transpiler and the jvm :)
Because of that some of the things that you posted are a bit hard to compare.
We believe that by having a VM (based on a industry adopted specification such as WebAssembly) we can control much more granularly both execution (CPU, memory) and the runtime interoperability with the system (networking, file system, ...), solving most of the issues that Docker containers have