WebAssembly components model and composability
Wasm and composable scenarios
V8, for example, and that it runs fast, because of its binary format. And we know that some cloud execution contexts run on
V8, particularly on CDN, at the edge of the network.
But we also know that one of the characteristics of WebAssembly, is portability, and that we have shims that allow to run Wasm (WASI enabled) server-side or in devices. That multiplies opportunities to have super-performant execution contexts, literally anywhere where you may have the necessary infrastructure -a virtual or physical machine, or other forms of virtualization like containers- in the form of functions.
For example, as the code in this page illustrates, you may have to import definitions that your specify in your code, like I do to use
env, in the .wat file above. Even when Wasm code’s format makes it lighter and faster, we still need to learn to optimize it, and that is specially true when Wasm is a compilation target for other languages, since they will inject dependencies necessary via the toolchain. That may suppose a resource strain for the system running Wasm, when it’s clientside, deteriorating the user experience by straining resources like memory.
However, when it comes to innovative forms of composition, a lot of the frameworks we discussed in the corresponding section of the site, are designed to build applications that may be either rendered or composed on this super fast and performant runtimes in the cloud, and use wasmruntime and other mechanisms to improve client-side performance.