WASM will replace containers

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

> I understand your point but sadly I think it's too idealistic (not that we shouldn't strive for these goals). We already have those sorts of tests for browsers, and browser compatibility is still a problem. We have acceptance tests for other areas, like Android's CTS tests, but there are still incompatibilities. >

I think the browser problem is a marketshare/market power problem, and Wasm doesn't have that problem.

Also, I'd argue that compat tests for JS engines and browsers are an overall positive thing -- at least compared to the world where there is no attempt to standardize at all.

> That also assumes that everyone involved wants compatibility, and that's unlikely. Imagine a world where every WASM implementation is identical. If one implementation decides to change something to implement an improvement to differentiate themselves in the market, they'll likely win marketshare from the others.

This is a good thing though -- as long as it happens without breaking compatibility. Users are very sensitive to changes that introduce lock-in/break standards, and the value would have to be outsized for someone to forgo having other options.

> Most companies implementing WASM will tend to want to a) control the spec in their own favour, and b) gain advantages over other implementations. And this is why we can't have nice things.

I think you can see this playing out right now in the Wasm ecosystem, and it isn't working out like you might expect. There are great benefits in building standards because of friction reduction for users -- as long as there is a "standards first" approach, people overwhelmingly pick it if functionality is close enough.

Places that make sense to differentiate are differentiated, but those that do not start to get eaten by standards.

I think organizations that are aware of this problem and attempt to address is directly like the Bytecode Alliance are also one of the only forms of bulwark against this.

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.

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

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!