I've been following a similar WASM-first language, Moonbit (https://www.moonbitlang.com/), which was created by the creator of Rescript.
Well that's compelling! Would love to see such a promising effort work to cross the chasm from interesting esoteric language to something participating in the broader Webassembly Interface Types world, but not holding my breath on this. Still, one to look at!
PHP would serve WordPress when it's run as a standalone Wasm application.
php.wasm can essentially run in:
1. Wasm application (runtime)
2. Docker+Wasm container
3. Any app that embeds a Wasm runtime (e.g. Apache HTTPD)
4. Web browser
WebAssembly brings true portability to the picture. You can build a binary once and run it everywhere.
Wasm container images are much smaller than the traditional ones. Even the alpine version of the php container is bigger than the Wasm one.
php (166MB), php-alpine (30.1MB), php-wasm (5.35 MB)
With WASI SDK we can build a Wasm module out of PHP's codebase, written in C. After that, it takes a very simple Dockerfile based on scratch for us to make an OCI image that can be run with Docker+Wasm.
Building a WASM container that can be run with Docker+Wasm
Docker Desktop now includes support for WebAssembly. It is implemented with a containerd shim that can run Wasm applications using a Wasm runtime called WasmEdge. This means that instead of the typical Windows or Linux containers which would run a separate process from a binary in the container image, you can now run a Wasm application in the WasmEdge runtime, mimicking a container. As a result, the container image does not need to contain OS or runtime context for the running application - a single Wasm binary suffices.
Docker Desktop can run Wasm applications (binaries) instead of OS (Linux/Windows)
We now have WebAssembly. Its technical features and portability make it possible to distribute the application, without requiring shipping OS-level dependencies and can run with strict security constraints.
Wasm, as a next step in the evolution of server-side software infrastructure
If WASM+WASI existed in 2008, we wouldn't have needed to create Docker. That's how important it is. WebAssembly on the server is the future of computing.
Quote from one of the co-founders of Docker
There are Wasm runtimes that can run outside of the browser, including traditional operating systems such as Linux, Windows and macOS. Because they cannot rely on a JavaScript engine being available they communicate with the outside world using different interfaces, such as WASI, the WebAssembly System Interface. These runtimes allow Wasm applications to interact with their host system in a similar (but not quite the same) way as POSIX. Projects like WASI SDK and wasi-libc help people compile existing POSIX-compliant applications to WebAssembly.
Explanation on how Wasm runs on servers
Browser engines integrate a Wasm virtual machine, usually called a Wasm runtime, which can run the Wasm binary instructions. There are compiler toolchains (like Emscripten) that can compile source code to the Wasm target. This allows for legacy applications to be ported to a browser and directly communicate with the JS code that runs in client-side Web applications.
Explanation on how Wasm runs in browsers
the new Docker+Wasm integration allows you to run a Wasm application alongside your Linux containers at much faster speed.
```bash time docker run hello-world ... 0.07s user 0.05s system 1% cpu 8.912 total time docker run --runtime=io.containerd.wasmedge.v1 --platform=wasi/wasm32 ajeetraina/hello-wasm-docker
0.05s user 0.03s system 19% cpu 0.393 total ```
Docker Desktop and CLI can now manage both Linux containers and Wasm containers side by side.
infrastructure
基础设施
除了上面介绍的，.wasm 文件还有其他部分，通常把它们叫做部件。一些部件对于模块来讲是必须的，一些是可选的。
wasm的结构start
Web Assembly (WASM) is an official W3C standard * Running apps on the web with close performance to native apps (i.e. Figma) * Compile target for other languages to run on modern Browsers (.wat -> .wasm) * Code can also be written using AssemblyScript
Since it can only load and store numbers, it needs to call out to JavaScript code to do anything interesting (create DOM nodes, make network connections, etc.). WebAssembly code is still inside the browser sandbox and can only use the browser APIs that JavaScript has access to.
WASM needs to call out to JavaScript code to do anything interesting (create DOM nodes, make network connections, etc.). WebAssembly code is still inside the browser sandbox and can only use the browser APIs that JavaScript has access to.
asm.js subset is basically JavaScript where you can only use numbers (no strings, objects, etc.). This is all you need to run C++ code since everything in C++ is either a number or a pointer to a number, and pointers are also numbers. The C++ address space is just a giant JavaScript array of numbers and pointers are just indices into that array.
everything in C++ is either a number or a pointer to a number, and pointers are also numbers.
Because our product is written in C++, which can easily be compiled into WebAssembly, Figma is a perfect demonstration of this new format’s power.
Figma is written in C++, which can easily be compiled into WebAssembly
WebAssembly allows developers to create desktop-quality experiences on the web without compromising on performance.
The problem is that it’s slow. WebAssembly doesn’t allow you to dynamically generate new machine code and run it from within pure Wasm code. This means you can’t use the JIT. You can only use the interpreter.
I believe wasm can run off a SharedArrayBuffer, which is mutable. I'm not sure how that interacts with the running engine, how dynamically modifiable it is. Trying to runtime rewrite wasm & figure out exports would be... complicated. But this blanket statement still comes as quite a surprise to me, even though I know that within WASM no one is able to re-write the code.
When running this small application with Wizer, it only takes .36 milliseconds (or 360 microseconds). This is more than 13 times faster than what we’d expect with the JS isolate approach. We get this fast start-up using something called a snapshot. Nick Fitzgerald explained all this in more detail in his WebAssembly Summit talk about Wizer.
Deno has been doing a lot of work to make sure V8 Isolate's snapshots are well supported & easy to build & manage & launch. I'm very excited to see Deno, someday, post similar orders-of-magnitude wins. I expect folks like CloudFlare Workers already do this.
most popular smart contract
Official basic solidity explanation. Notice the warnings about new versions breaking old coding methods. This is very common in solidity as it is still viewed as an in development language. Solidity is expected to remain a blockchain smart contract programming standard for quite sometime while other competing languages such as Rust, Java, C++, etc are expected to gain more ground particularly due to the introduction of the WASM low level language and the toolkit that supports it which is well established and well integrated. Here's a link to some more WASM goodness. https://hackernoon.com/the-three-eggs-in-a-distributed-basket-wasm-blockchain-and-reputation-296892cdd77c
This is especially true for online gaming
WASM is being used to run many demanding applications directly in the browser. Autocad is one important example where architects can use this application without installing a usually very heavy piece of software on their computers. They can access the Autocad suite from almost any computer only by logging into to a website. It is expected that a large part of the gaming industry will shift this way as well as many other services. One of the main advantages of this approach aside from a lack of a local installation is real-time software updates for any number of users. A new model of software building and execution will be based on WASM. WASM is also very good for blockchains. Search for the WASM section to learn more.