# Webassembly auf der Serverseite
- Ansprache in Sächsisch
- Webassembly: Geschichte
	- 1996: JavaScript 1.0: Oh oh
	- 2009: NodeJS: Frontend, Backend, Desktop
	- JS pros: Man hat überall einen Browser, läuft überall
	- JS cons: Langsam, es ist JavaScript.
	- 2017: WASM 1.0, Browser als Compiletarget
	- WASM pros: gleiche Vorteile, ist schneller, kein JavaScript.
- Wie funktioniert Webassembly?
	- Code in beliebiger Sprache schreiben.
	- Bester Support: C, C++, Rust, C#
	- Compilen zu wasm32-x target
	- Frontend bauen ohne JavaScript: DOM mit wasm-bindgen importieren
	- Strings werden in gemeinsam allozierten Speicher raw reingeschrieben, um zwischen Sprachen auszutauschen.
	- Yew, Sicamore, Leptos für Rust wasm Frontend
- Backend mit Webassembly? Warum?
	- WASM 4 cloud: Sandboxing, portabel (JITC Bytecode), schnell
	- WASM Laufzeit außerhalb des Brpwsers: Wasmtime, Wasmer, WasmEdge
	- Kann man für Plugin Systeme nutzen
- Component Modell: wie definiert man Interfaces und wie tauscht man Daten aus?
	- Eigenes Spec Format für Interfaces: WIT
	- WIT definiert alle Interfaces und man implementiert dann das WIT in der Sprache
- Was ist Wasi?
	- nutze WIT, um Host Interaktionen zu definieren.
- Es gibt wie gesagt fertige Runtimes aber auch CLIs, um Programme einmal aufzurufen
- Es gibt spin http component. Man kann damit webservice mit WASM Runtime bauen. Ungefähr wie Java Springboot
- Kann man als containerd-shim deployen.