WebAssembly (Wasm)

Image/Video Processing

FFmpeg.wasm, OpenCV.js, Squoosh (Google)

Języki: C++ / Rust

10-50x szybciej vs. pure JS

Gry i Silniki 3D

Unity WebGL, Godot, Unreal Engine

Języki: C++ / C#

Natywna wydajność grafiki w przeglądarce

Kryptografia

libsodium.js, WebCrypto supplementary

Języki: Rust / C

Constant-time operations, side-channel safety

CAD i Design Tools

Figma, Autodesk, Shapr3D

Języki: C++ / Rust

Ciężkie obliczenia geometryczne

AI / ML Inference

ONNX Runtime Wasm, TensorFlow.js Wasm backend

Języki: C++ / Rust

Szybszy inference vs. pure JS

SQLite w przeglądarce

sql.js, wa-sqlite, PGlite

Języki: C

Pełna baza danych offline po stronie klienta

Co to jest WebAssembly (Wasm) i jak działa w przeglądarce?

WebAssembly (Wasm) to binarny format instrukcji uruchamiany w przeglądarce jako cel kompilacji dla języków takich jak C, C++, Rust, Go. Jest to niski poziom wirtualnej maszyny — szybszy niż JavaScript dla obliczeń intensywnych. Jak działa: kod w C++/Rust jest kompilowany do .wasm (binarny). Przeglądarka ładuje .wasm i uruchamia go w sandboxie (izolowanym środowisku). JavaScript i Wasm mogą wywoływać się wzajemnie przez interfejs JS API. Wasm vs. JavaScript: JavaScript — dynamicznie typowany, interpretowany/JIT-compiled. Dobry dla logiki UI, DOM manipulacji. Wasm — statycznie typowany, kompilowany ahead-of-time. Nawet 10-100x szybszy dla obliczeń numerycznych, siłowe operacje na danych. Przykłady zastosowań: Figma — rendering w Wasm. Google Earth — mapy 3D. Autodesk — CAD w przeglądarce. Zoom — video processing. FFmpeg.wasm — konwersja video w przeglądarce. SQLite.wasm — baza danych po stronie klienta. Obsługa przeglądarek: wszystkie nowoczesne przeglądarki. Chrome, Firefox, Safari, Edge — pełne wsparcie. Ekosystem: Emscripten — toolchain C/C++ do Wasm. wasm-pack — Rust do Wasm. TinyGo — Go do Wasm.

Rust i Wasm — jak kompilować Rust do WebAssembly?

Rust jest uważany za najlepszy język do WebAssembly — memory safety bez garbage collectora (brak GC pauses), świetna wydajność i doskonałe tooling. Setup: install wasm-pack (narzędzie budowania Rust+Wasm). Rust target: wasm32-unknown-unknown. wasm-pack build — kompiluje Rust do .wasm + generuje JS bindings. wasm-bindgen: biblioteka do generowania automatycznych JS bindings. Definiujesz które funkcje Rust są eksportowane do JavaScript. Typy automatycznie konwertowane (String, Vec, structs). Przykład: #[wasm_bindgen] pub fn add(a: i32, b: i32) -> i32 { a + b }. Po kompilacji wywołujesz z JS: import { add } from './pkg/mylib'; console.log(add(2, 3));. web-sys i js-sys: bindingi do Web APIs (DOM, fetch, canvas) z Rust. Możesz manipulować DOM bezpośrednio z Rust. Performance tips: minimize JS-Wasm boundary crossings (każde wywołanie między JS i Wasm ma overhead). Bulk data transfer przez SharedArrayBuffer lub wasm-bindgen's memory. WASI (WebAssembly System Interface): standard do uruchamiania Wasm poza przeglądarką (server-side). Runtime: Wasmtime, Wasmer, WasmEdge. Use case: portable plugins, edge computing, sandboxed execution.

WebAssembly poza przeglądarką — WASI, edge computing i runtime?

WASI (WebAssembly System Interface): standardowy interface dla Wasm poza przeglądarką — dostęp do systemu plików, sieci, zmiennych środowiskowych. Cel: Wasm jako portable, sandboxed runtime wszędzie. Runtimes WASI: Wasmtime (Bytecode Alliance) — produkcyjny runtime, używany w Fastly. Wasmer — runtime z package manager (wapm). WasmEdge — zoptymalizowany dla edge i cloud. Edge Computing z Wasm: Fastly Compute — Wasm runtime na ich edge (nie V8 Isolates jak Cloudflare). Cloudflare Workers również mają Wasm support. Ultra-fast cold starts (Wasm startuje w mikrosekudnach). Sandboxing natywny — każdy request w izolowanym Wasm sandbox. Plugin systems: Extism — framework dla plugin systems opartych na Wasm. Wasm plugins w aplikacjach Go, Rust, Python, JS. Envoy Proxy — Wasm jako filter plugins (bez kompilacji proxy). Open Policy Agent (OPA) — polityki jako Wasm. Kubernetes: kruntimes kontenerów wspierają Wasm workloads (runwasi). Containerd + Wasm = lżejsza alternatywa dla Docker w niektórych scenariuszach. Component Model (Wasm Components): nowy standard (2024) — komponenty z silnie typowanymi interfejsami. wit-bindgen — generowanie bindings ze specyfikacji WIT (Wasm Interface Types). Interoperabilność między językami przez komponenty.

C++ i Emscripten — portowanie istniejącego kodu do przeglądarki?

Emscripten to toolchain do kompilowania kodu C/C++ do WebAssembly (lub legacy asm.js). Instalacja: emsdk (Emscripten SDK). Kompilacja: emcc mycode.cpp -o output.html (lub .js, .wasm). Automatycznie generuje HTML/JS wrapper lub samodzielny .wasm. Obsługiwane biblioteki: SDL2 — grafika 2D. OpenGL ES — grafika 3D (przez WebGL). POSIX API — sys/file, sockets (przez emulated). zlib, libpng, libjpeg, freetype — standardowe lib. Porty: Emscripten Ports — pre-compiled wersje popularnych bibliotek. Portowanie gier: gry C++ (silniki: Godot eksportuje do Wasm, Unity WebGL to Wasm). Doom, Quake — portowane do przeglądarki przez Emscripten. Unreal Engine — Wasm export. Memory model: Emscripten emuluje stos i heap C w Wasm Linear Memory. Malloc/free działa jak w natywnym C++. Wyzwania portowania: blocking API (pthreads emulowane przez SharedArrayBuffer + Atomics). File I/O emulowane (VFS). C++ exceptions obsługiwane ale z overhead. Performance: skompilowany C++ do Wasm jest zwykle 70-90% szybkości natywnego kodu. Debugowanie: source maps + DWARF info = debugowanie oryginalnego C++ kodu przez DevTools. Alternatywy dla Emscripten: wasi-sdk (minimalistyczny, brak emulacji POSIX), tinycc+wasm.

Jak wdrożyć WebAssembly w projekcie webowym — praktyczny przewodnik?

Kiedy używać Wasm: obliczenia intensywne (image processing, video, audio, kryptografia, AI inference). Portowanie istniejących bibliotek C/C++ do przeglądarki. Gry i wizualizacje wymagające wysokiej wydajności. Kod który musi być szybszy niż JavaScript może osiągnąć. Kiedy NIE używać Wasm: prostą logikę UI i DOM — JavaScript jest wystarczający. Overhead komunikacji JS-Wasm może niwelować zyski wydajności przy małych operacjach. Przeglądarki muszą pobierać i kompilować .wasm (choć streaming compilation pomaga). Integracja z bundlerami: Vite — natywne wsparcie .wasm imports (import wasmUrl from './module.wasm?url'). Webpack — wasm-loader lub native asset modules. Rollup — @rollup/plugin-wasm. Next.js — eksperymentalne wsparcie w next.config.js. Wasm+JS wzorce: Compute-heavy logic w Wasm, UI w JS. Wasm jako WebWorker (nie blokuje main thread). SharedArrayBuffer dla zero-copy data transfer między JS i Wasm. Narzędzia i ekosystem: wasm-opt — optymalizuje .wasm pliki (Binaryen). twiggy — profiler rozmiaru .wasm. wasm-snip — usuwa nieużywane funkcje. Metryki: rozmiar .wasm, czas inicjalizacji (streaming compilation vs. synchronous), memory footprint.

Wyślij zapytanie