What WebContainers doesn't do is provide container tech. WebAssembly is similar to a Docker container, so much so that Docker now supports WebAssembly. WebContainers also uses a subdomain and the browser's security model. In fact the browser is the main thing that limits what stuff inside the WebContainer can do in WebAssembly. WebContainer runs whatever JavaScript the WebAssembly code spits out. Like DotCloud one of the great things about WebAssembly is that it can run a wider variety of code performantly than a JavaScript engine can - not just code that can compile to JS but anything that can be compiled to its bytecode. This is what WebContainer takes advantage of - not the sandboxing of a WebContainer, which is also excellent but isn't the right fit for a code sandbox like jsbin/CodePen/CodeSandbox/etc, which needs to be able to run whatever can be run in a browser tab.
What WebContainers does is use some hacks to sort of run node apps in the browser, so instead of using something like the browser version of rollup, you can use something like vite. You can also see the console output that vite would provide.
When vite installs esbuild I think it probably specifies the non-WASM esbuild. So it's likely running patched vite and running WASM esbuild.
It uses a fake npm and yarn and shows npm and yarn in the output. This explained in this FAQ under "Do you support yarn or only npm?": https://github.com/stackblitz/webcontainer-core#faqs
It has an iframe sandbox with same-origin which means in order for it to be contained, you need a subdomain. This is something other major sandboxes do like jsbin and CodeSandbox. This is why IMO it doesn't provide container tech.
That's lucky, because custom container tech on the web winds up being like Google Caja which was a marvelous accomplishment but not nearly as robust as Docker, MicroVMs, WASM, or the browser security model (<iframe sandbox>, CSPs, and more): https://en.wikipedia.org/wiki/Caja_project https://devd.me/papers/LeastPrivileges.pdf
