WebAssembly
Fleeting- Référence externe : https://hacks.mozilla.org/2017/02/creating-and-working-with-webassembly-modules/
— https://hacks.mozilla.org/2017/02/creating-and-working-with-webassembly-modules/
web platform can be thought of as having two parts:
- A virtual machine (VM) that runs the Web app’s code, e.g. the JavaScript code that powers your apps.
- A set of Web APIs that the Web app can call to control web browser/device functionality and make things happen (DOM, CSSOM, WebGL, IndexedDB, Web Audio API, etc.).
— https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts
Historically, the VM has been able to load only JavaScript.
— https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts
WebAssembly is a different language from JavaScript, but it is not intended as a replacement. Instead, it is designed to complement and work alongside JavaScript,
— https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts
JavaScript is a high-level language, flexible and expressive enough to write web applications.
— https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts
WebAssembly is a low-level assembly-like language with a compact binary format that runs with near-native performance and provides languages with low-level memory models
— https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts
virtual machine that we talked about earlier will now load and run two types of code — JavaScript AND WebAssembly.
— https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts
different code types can call each other as required
— https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts
WebAssembly cannot currently directly access the DOM; it can only call JavaScript,
— https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts
to access any Web API, WebAssembly needs to call out to JavaScript, which then makes the Web API call.
— https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts
Emscripten therefore creates the HTML and JavaScript glue code needed to achieve this.
— https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts
Emscripten implements popular C/C++ libraries like SDL, OpenGL, OpenAL, and parts of POSIX. These libraries are implemented in terms of Web APIs and thus each one requires some JavaScript glue code to connect WebAssembly to the underlying Web API.
— https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts
part of the glue code is implementing the functionality of each respective library used by the C/C++ code
— https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts
glue code also contains the logic for calling the above-mentioned WebAssembly JavaScript APIs to fetch, load and run the .wasm file.
— https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts
WebAssembly System Interface
-
Référence externe : https://wasmlabs.dev/articles/docker-without-containers/
-
Référence externe : https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/ Standardizing WASI: A system interface to run WebAssembly outside the web – Mozilla Hacks - the Web developer blog
— https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/
WebAssembly beyond the browser, because it provides a fast, scalable, secure way to run the same code across all machines
— https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/
WebAssembly needs a system interface for a conceptual operating system
— https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/
This is what WASI is — a system interface for the WebAssembly platform.
— https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/
need a way to control which programs and users can access which resources.
— https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/
When a program needs to ask the kernel to do one of these things, it asks using a system call
— https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/
only way that your code can access the system’s resources — through system calls
— https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/
operating system makes the system calls available.
— https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/
each operating system has its own system calls
— https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/
Most languages provide a standard library. While coding, the programmer doesn’t need to know what system they are targeting. They just use the interface
— https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/
system interface comes in. For example, printf being compiled for a Windows machine could use the Windows API to interact with the machine. If it’s being compiled for Mac or Linux, it will use POSIX instead
— https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/
WebAssembly needs a system interface for a conceptual operating system, not a real operating system
— https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/
Emscripten created its own implementation of libc. This implementation was split in two — part was compiled into the WebAssembly module, and the other part was implemented in JS glue code. This JS glue would then call into the browser, which would then talk to the OS.
— https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/
when people started wanting to run WebAssembly without a browser, they started by making Emscripten-compiled code run. So these runtimes needed to create their own implementations for all of these functions that were in the JS glue code.
— https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/
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.
WebAssembly as the ‘successor’ to containers and the next logical step in infrastructure deployment
WebAssembly is as an alternative ‘backend’ for Docker tooling. You can use the same command line tools and workflows, but instead of using Linux containers, it is implemented using WebAssembly-based container equivalents.
runtimes
wasmer
-
Référence externe : https://wasmer.io/
- see,
- wasm,
Run any code on any client. With WebAssembly and Wasmer
- see,
wasmtime
pronunciation
WebAssembly (abbreviated WASM, pronounced waz-um)
(Wasm should be pronounced like awesome starting with a W ).
WebAssembly, when you read Wasm. Is it wah-sum, w-a-s-m, or do you just read ‘web assembly’?
wah-sum
— https://users.rust-lang.org/t/pronunciation-of-things-from-rust/54744?page=2
we expect that developers are going to use both WebAssembly and JavaScript in the same application
— https://hacks.mozilla.org/2017/02/creating-and-working-with-webassembly-modules/
WebAssembly is a little bit different than other kinds of assembly. It’s a machine language for a conceptual machine, not an actual, physical machine.
— https://hacks.mozilla.org/2017/02/creating-and-working-with-webassembly-modules/
another tool called Emscripten which is a bit easier to use at the moment. It has its own back-end that can produce WebAssembly by compiling to another target (called asm.js) and then converting that to WebAssembly. It uses LLVM under the hood, though, so you can switch between the two back-ends from Emscripten.
— https://hacks.mozilla.org/2017/02/creating-and-working-with-webassembly-modules/
Notes pointant ici
- GoogleChromeLabs/wasi-fs-access: access host filesystem from browser using wasi
- pyodide
- pyscript
- Running Python in the Browser with WebAssembly | TestDriven.io
- simulate http server using service workers
- trying rust in webassembly
- wabt
- wasm and export in golang
- wasm in rust