Soffio Admin
Dashboard
Posts
Pages
Tags
Navigation
Uploads
Jobs
Audit
API keys
Site settings
View site
Edit Post: WebAssembly: The Future of Web Performance
Title
Excerpt
WebAssembly brings near-native performance to the browser, enabling applications once impossible on the web. From gaming engines to video editors, explore how WASM rewrites the rules of web development and its role in the post-JavaScript era.
Body Markdown
# WebAssembly: The Future of Web Performance  ## Introduction: Breaking the JavaScript Monopoly For over two decades, JavaScript has been the **only** language with first-class citizenship in web browsers. While JavaScript evolved from a simple scripting language to a powerful runtime capable of building complex applications, its fundamental constraints remained: - **Single-threaded execution model** (until Web Workers) - **Dynamic typing** with runtime overhead - **Interpreted/JIT compilation** with warmup time - **Garbage collection** pauses - **Performance ceiling** for compute-intensive tasks Enter **WebAssembly (WASM)**: a binary instruction format for a stack-based virtual machine, designed as a portable compilation target for high-level languages. WebAssembly doesn't replace JavaScript—it complements it, unlocking performance-critical use cases previously impossible on the web. **The Promise**: - **Near-native speed**: 10-100x faster than JavaScript for CPU-intensive workloads - **Language diversity**: Compile C, C++, Rust, Go, AssemblyScript, and more to WASM - **Compact binary format**: Smaller downloads, faster parsing - **Secure sandbox**: Same security model as JavaScript - **Portable**: Write once, run anywhere (browsers, Node.js, edge computing, embedded systems) This article explores WebAssembly's design, its practical applications, and its philosophical implications for the future of computing. ## The Historical Context ### The JavaScript Performance Journey ```javascript // Early 2000s: Slow interpreted JavaScript function fibonacci(n) { if (n <= 1) return n; return fibonacci(n - 1) + fibonacci(n - 2); } console.time('fib'); fibonacci(40); // Could take several seconds console.timeEnd('fib'); // Modern V8 with JIT optimization: Much faster, but still limited // The JIT needs time to "warm up" and optimize hot paths ``` JavaScript engines evolved dramatically: 1. **2008**: Chrome V8 introduced aggressive JIT compilation 2. **2010s**: asm.js emerged as a strict subset of JavaScript for performance 3. **2015**: WebAssembly project began as the successor to asm.js 4. **2017**: WebAssembly MVP shipped in all major browsers 5. **2019**: WASI (WebAssembly System Interface) for non-web environments ### Why Not Just Optimize JavaScript Further? ```typescript // The fundamental problem: Dynamic typing function add(a, b) { return a + b; } // What does this do? The engine must check at runtime: add(1, 2); // Number addition add("hello", "!"); // String concatenation add([1], [2]); // Array to string coercion, then concat add({}, {}); // "[object Object][object Object]" // WebAssembly has static types, eliminating this overhead ``` JavaScript's dynamic nature is both its strength (flexibility) and its weakness (performance). No matter how sophisticated the JIT compiler, it must handle the inherent dynamism. WebAssembly takes a different approach: **static types, ahead-of-time compilation, and explicit memory management**. ## WebAssembly Architecture ### The Stack Machine Model WebAssembly uses a **stack-based virtual machine**, similar to the JVM but optimized for compilation speed and small binary size. ```wat ;; WebAssembly Text Format (WAT) ;; Simple addition function (module (func $add (param $a i32) (param $b i32) (result i32) local.get $a ;; Push $a onto stack local.get $b ;; Push $b onto stack i32.add) ;; Pop two values, push sum (export "add" (func $add))) ``` **Why Stack-Based?** ```python # Stack-based vs Register-based VMs class StackVM: """ Pros: - Compact bytecode (no register allocation) - Simple to compile to - Easy validation Cons: - More instructions for complex operations """ def add(self): b = self.stack.pop() a = self.stack.pop() self.stack.push(a + b) class RegisterVM: """ Pros: - Fewer instructions - More efficient execution Cons: - Larger bytecode - Complex compilation """ def add(self, dest, src1, src2): self.registers[dest] = self.registers[src1] + self.registers[src2] # WebAssembly chose stack-based for: # 1. Smaller binary size (critical for web delivery) # 2. Faster validation # 3. Easier to JIT compile to native register-based code ``` ### Type System WebAssembly has a simple, efficient type system: ```wat ;; Basic value types i32 ;; 32-bit integer i64 ;; 64-bit integer f32 ;; 32-bit float f64 ;; 64-bit float ;; Reference types (post-MVP) funcref ;; Reference to a function externref ;; Reference to host object ;; Example: Strongly typed function (func $complex (param i32 f64) (result i32) local.get 0 ;; All operations type-checked at compile time! ) ``` ### Linear Memory Model ```javascript // WebAssembly memory is a resizable ArrayBuffer const memory = new WebAssembly.Memory({ initial: 1, // 1 page = 64KB maximum: 100 // 100 pages = 6.4MB }); // Memory is shared between WASM and JavaScript const buffer = memory.buffer; const bytes = new Uint8Array(buffer); // WASM code can read/write this memory // JavaScript can too - enabling efficient data sharing ``` **Memory Safety**: ```rust // In Rust (compiled to WASM) #[no_mangle] pub fn process_array(ptr: *mut u8, len: usize) { unsafe { let slice = std::slice::from_raw_parts_mut(ptr, len); // Process slice... } } // Memory safety is enforced: // 1. WASM can only access its own linear memory // 2. Bounds checked by the VM // 3. No access to host memory outside sandbox ```  ## From Source to WASM: The Compilation Pipeline ### Compiling C to WebAssembly ```c // fibonacci.c int fibonacci(int n) { if (n <= 1) return n; return fibonacci(n - 1) + fibonacci(n - 2); } ``` ```bash # Compile with Emscripten emcc fibonacci.c -o fibonacci.html \ -s WASM=1 \ -s EXPORTED_FUNCTIONS='["_fibonacci"]' \ -s EXPORTED_RUNTIME_METHODS='["ccall"]' \ -O3 # Or use clang directly for just WASM (no JS glue) clang --target=wasm32 -nostdlib -Wl,--no-entry \ -Wl,--export-all -o fibonacci.wasm fibonacci.c ``` ### Compiling Rust to WebAssembly ```rust // lib.rs use wasm_bindgen::prelude::*; #[wasm_bindgen] pub fn fibonacci(n: i32) -> i32 { match n { 0 => 0, 1 => 1, _ => fibonacci(n - 1) + fibonacci(n - 2) } } // More complex: Interacting with JavaScript #[wasm_bindgen] pub fn process_image(data: &[u8]) -> Vec<u8> { // Image processing logic data.iter().map(|&x| 255 - x).collect() } ``` ```bash # Build with wasm-pack wasm-pack build --target web # Generates: # - pkg/my_lib_bg.wasm (the WASM binary) # - pkg/my_lib.js (JavaScript bindings) # - pkg/my_lib.d.ts (TypeScript types) ``` ### Loading and Running WASM ```javascript // Method 1: Fetch and instantiate async function loadWASM() { const response = await fetch('fibonacci.wasm'); const buffer = await response.arrayBuffer(); const module = await WebAssembly.instantiate(buffer); const result = module.instance.exports.fibonacci(10); console.log(result); // 55 } // Method 2: Streaming instantiation (faster!) async function loadWASMStreaming() { const module = await WebAssembly.instantiateStreaming( fetch('fibonacci.wasm') ); return module.instance.exports; } // Method 3: With imports (memory, functions) async function loadWithImports() { const memory = new WebAssembly.Memory({ initial: 256 }); const importObject = { js: { mem: memory, log: (arg) => console.log(arg) } }; const module = await WebAssembly.instantiateStreaming( fetch('app.wasm'), importObject ); return module.instance.exports; } ``` ## Performance Analysis ### JavaScript vs WebAssembly Benchmark ```javascript // JavaScript implementation function jsSum(n) { let sum = 0; for (let i = 0; i < n; i++) { sum += Math.sqrt(i); } return sum; } // WebAssembly (from C) /* double wasm_sum(int n) { double sum = 0; for (int i = 0; i < n; i++) { sum += sqrt(i); } return sum; } */ // Benchmark const N = 10_000_000; console.time('JavaScript'); jsSum(N); console.timeEnd('JavaScript'); // ~150ms console.time('WebAssembly'); wasmExports.wasm_sum(N); console.timeEnd('WebAssembly'); // ~30ms // WASM is 5x faster! ``` **When is WASM Faster?** ```python class PerformanceProfile: """WASM excels when:""" compute_intensive = [ "Heavy numerical calculations", "Image/video processing", "Audio synthesis", "Physics simulations", "Cryptography", "Compression/decompression", "Scientific computing" ] memory_intensive = [ "Large data structure manipulation", "Binary data processing", "Custom memory management" ] """WASM may be SLOWER for:""" not_ideal = [ "DOM manipulation (JS is native)", "Simple string operations", "Calling JS APIs frequently (boundary crossing overhead)", "Small, short-lived computations (instantiation overhead)" ] # The golden rule: Use WASM for CPU-bound work, # JavaScript for I/O-bound and DOM work ``` ### Real-World Performance ```typescript // Example: Image filtering interface PerformanceComparison { task: string; jsTime: number; wasmTime: number; speedup: number; } const benchmarks: PerformanceComparison[] = [ { task: "Gaussian blur (1920x1080)", jsTime: 450, wasmTime: 85, speedup: 5.3 }, { task: "SHA-256 hashing (10MB)", jsTime: 680, wasmTime: 95, speedup: 7.2 }, { task: "JSON parsing (1MB)", jsTime: 45, wasmTime: 48, speedup: 0.94 // WASM slower due to boundary overhead }, { task: "FFT (16384 points)", jsTime: 180, wasmTime: 22, speedup: 8.2 } ]; ```  ## Real-World Applications ### 1. Gaming Engines ```javascript // Unity games running in browser via WASM // Example: "Dead Trigger 2" ported to web class UnityWASMLoader { async load() { const unityInstance = await createUnityInstance(canvas, { dataUrl: "Build/game.data", frameworkUrl: "Build/game.framework.js", codeUrl: "Build/game.wasm", // Entire C++ engine in WASM streamingAssetsUrl: "StreamingAssets", companyName: "MyCompany", productName: "MyGame", }); // Full 3D game engine running at 60fps in browser! } } ``` ### 2. Video Editing: Figma Figma's rendering engine is written in C++ and compiled to WASM, enabling: - Real-time collaborative editing - Complex vector operations - No plugin installation required ```cpp // Simplified Figma rendering pseudo-code extern "C" { void render_scene(Canvas* canvas, Scene* scene) { // Complex rendering pipeline in C++ // Compiled to WASM for browser for (auto& layer : scene->layers) { apply_effects(layer); rasterize(canvas, layer); } } } ``` ### 3. AutoCAD Web Autodesk ported 35+ years of C++ code to WebAssembly: ```javascript // AutoCAD's core engine (~1M LOC C++) runs in browser const autocad = await AutoCAD.load({ wasmUrl: 'autocad.wasm', memoryInitializer: 'autocad.mem' }); // Full CAD functionality without installation autocad.drawLine(start, end); autocad.apply3DTransform(matrix); ``` ### 4. TensorFlow.js with WASM Backend ```javascript import * as tf from '@tensorflow/tfjs'; import '@tensorflow/tfjs-backend-wasm'; // Use WASM backend for better CPU performance await tf.setBackend('wasm'); const model = await tf.loadLayersModel('model.json'); // Inference 2-3x faster than pure JS backend const prediction = model.predict(inputTensor); ``` ### 5. SQLite in the Browser ```javascript // Full SQLite database engine in WASM import initSqlJs from 'sql.js'; const SQL = await initSqlJs({ locateFile: file => `https://sql.js.org/dist/${file}` }); const db = new SQL.Database(); // SQL queries in browser, no server needed db.run(` CREATE TABLE users (id INTEGER, name TEXT); INSERT INTO users VALUES (1, 'Alice'), (2, 'Bob'); `); const result = db.exec("SELECT * FROM users"); ``` ## JavaScript ↔ WebAssembly Interop ### Calling WASM from JavaScript ```javascript // Simple value passing const result = wasmExports.add(5, 3); // Passing arrays (via memory) function callWasmWithArray(arr) { // Allocate memory in WASM const ptr = wasmExports.malloc(arr.length * 4); // Copy data to WASM memory const heap = new Int32Array(wasmExports.memory.buffer); heap.set(arr, ptr / 4); // Call WASM function wasmExports.process_array(ptr, arr.length); // Read result from memory const result = heap.slice(ptr / 4, ptr / 4 + arr.length); // Free memory wasmExports.free(ptr); return Array.from(result); } ``` ### Calling JavaScript from WASM ```rust // Rust with wasm-bindgen use wasm_bindgen::prelude::*; #[wasm_bindgen] extern "C" { // Import JavaScript functions #[wasm_bindgen(js_namespace = console)] fn log(s: &str); #[wasm_bindgen(js_namespace = Math)] fn random() -> f64; } #[wasm_bindgen] pub fn do_something() { log("Hello from WASM!"); let r = random(); log(&format!("Random: {}", r)); } ``` ### Best Practices for Interop ```typescript class WASMInterop { // Anti-pattern: Frequent boundary crossing badExample() { for (let i = 0; i < 1000; i++) { wasmExports.process_item(i); // 1000 JS→WASM calls! } } // Good: Batch operations goodExample() { const items = new Int32Array(1000); for (let i = 0; i < 1000; i++) { items[i] = i; } wasmExports.process_items(items); // Single call! } // Principle: Minimize boundary crossings // Each call has overhead (~10-50ns, but adds up) } ```  ## Security Model WebAssembly runs in the same sandbox as JavaScript: ```javascript // What WASM CAN'T do: const wasmLimitations = { filesystem: "No direct file system access", network: "No direct network access (must call JS fetch)", dom: "No DOM manipulation (must call through JS)", memory: "Can't access host memory outside its linear memory", system_calls: "No system calls (in browser)", // In other words: Same security as JavaScript }; // What WASM CAN do: const wasmCapabilities = { computation: "Arbitrary computation within memory bounds", memory: "Access its own linear memory", imports: "Call imported JavaScript functions", exports: "Expose functions to JavaScript" }; ``` ### WASI: WebAssembly System Interface For non-browser environments (Node.js, Deno, edge computing), WASI provides controlled access to system resources: ```rust // Rust with WASI use std::fs::File; use std::io::Write; fn main() { let mut file = File::create("output.txt").unwrap(); file.write_all(b"Hello from WASM+WASI!").unwrap(); } ``` ```bash # Compile to WASI cargo build --target wasm32-wasi # Run with Wasmtime wasmtime run target/wasm32-wasi/release/app.wasm \ --dir=. \ # Grant access to current directory --env KEY=VALUE # Pass environment variable ``` ## WebAssembly Threads Multi-threading support unlocks parallelism: ```c // C code with pthreads #include <pthread.h> #include <emscripten/threading.h> void* worker(void* arg) { int* data = (int*)arg; // Process data in parallel return NULL; } int main() { pthread_t threads[4]; int data[4] = {0, 1, 2, 3}; for (int i = 0; i < 4; i++) { pthread_create(&threads[i], NULL, worker, &data[i]); } for (int i = 0; i < 4; i++) { pthread_join(threads[i], NULL); } return 0; } ``` ```bash # Compile with threading support emcc app.c -o app.js -pthread -s PTHREAD_POOL_SIZE=4 ``` ```javascript // JavaScript side: SharedArrayBuffer required const memory = new WebAssembly.Memory({ initial: 256, maximum: 512, shared: true // Enable shared memory }); // Requires proper CORS headers: // Cross-Origin-Opener-Policy: same-origin // Cross-Origin-Embedder-Policy: require-corp ``` ## SIMD (Single Instruction, Multiple Data) Process multiple values with one instruction: ```wat ;; WebAssembly SIMD (func $add_vectors (param $a v128) (param $b v128) (result v128) local.get $a local.get $b i32x4.add) ;; Add 4 i32 values in parallel ;; Performance boost for: ;; - Image processing (process 4+ pixels at once) ;; - Audio DSP ;; - Scientific computing ;; - Machine learning ``` ```rust // Rust with SIMD use std::arch::wasm32::*; #[target_feature(enable = "simd128")] unsafe fn add_arrays(a: &[i32], b: &[i32], result: &mut [i32]) { for i in (0..a.len()).step_by(4) { let va = v128_load(a.as_ptr().add(i) as *const v128); let vb = v128_load(b.as_ptr().add(i) as *const v128); let vr = i32x4_add(va, vb); v128_store(result.as_mut_ptr().add(i) as *mut v128, vr); } } // 4x speedup for vectorizable operations! ```  ## The Ecosystem ### Languages Compiling to WASM ```yaml Production-Ready: - C/C++: Emscripten, clang - Rust: wasm-bindgen, wasm-pack - Go: TinyGo - AssemblyScript: TypeScript-like syntax Experimental: - Python: Pyodide - Swift: SwiftWasm - Kotlin: Kotlin/Wasm - .NET: Blazor Specialized: - Zig: Native WASM support - Grain: Functional language for WASM ``` ### Runtimes ```javascript const runtimes = { browsers: ['Chrome/V8', 'Firefox/SpiderMonkey', 'Safari/JSC', 'Edge'], serverSide: { 'Node.js': 'V8-based, same as Chrome', 'Deno': 'V8-based, WASI support', 'Wasmtime': 'Standalone WASM runtime', 'Wasmer': 'Universal WASM runtime', 'WasmEdge': 'Edge computing focused' }, embedded: { 'WAMR': 'WebAssembly Micro Runtime', 'wasm3': 'Fast interpreter for constrained devices' }, cloud: { 'Cloudflare Workers': 'V8 isolates with WASM', 'Fastly Compute@Edge': 'WASM at the edge', 'AWS Lambda': 'Limited WASM support' } }; ``` ## Debugging WebAssembly ```bash # Generate debug info emcc app.c -g -o app.js # Or with source maps emcc app.c -g4 -o app.js # Full source maps ``` Chrome DevTools supports WASM debugging: - Set breakpoints in WASM code - Step through execution - Inspect memory - View variables (when debug info present) ```javascript // Console debugging from WASM #include <emscripten.h> EM_JS(void, console_log, (const char* msg), { console.log(UTF8ToString(msg)); }); void debug_print() { console_log("Debug message from WASM"); } ``` ## Philosophical Implications ### The Democratization of the Web Platform ```python class WebPlatformEvolution: """ 1990s: HTML/CSS (documents) 2000s: + JavaScript (interactivity) 2010s: + Rich APIs (Web apps) 2020s: + WebAssembly (any language, any workload) """ def philosophical_shift(self): return { 'from': 'JavaScript as gatekeeper', 'to': 'Polyglot web platform', 'impact': [ 'Decades of C/C++ code can run on web', 'Developers choose language for the job', 'Performance no longer compromised', 'Desktop apps move to web without rewrite' ] } ``` ### Write Once, Run Anywhere (For Real This Time) ```typescript // The universal binary format interface WASMPromise { targets: string[]; reality: boolean; } const wasmPortability: WASMPromise = { targets: [ 'All major browsers', 'Node.js/Deno', 'Cloudflare Workers', 'Embedded devices', 'Mobile apps (via wrappers)', 'Desktop apps (Tauri, etc.)', 'Game consoles (future)', 'IoT devices' ], reality: true // Actually achievable! }; // Contrast with Java's promise: // "Write once, run anywhere... if JVM is installed" // WASM's promise: // "Write once, run anywhere with a WASM runtime" // (which is everywhere) ``` ### The Future: WebAssembly Outside the Web ```rust // WASM as universal plugin system // Example: Extending applications with WASM plugins pub trait Plugin { fn on_load(&self); fn process(&self, data: &[u8]) -> Vec<u8>; } // Users can write plugins in any language // Host app loads them as WASM modules // Sandboxed, safe, performant // Real examples: // - Shopify Functions (WASM-based) // - Envoy proxy filters (WASM) // - Figma plugins (WASM) // - VSCode extensions (could be WASM) ``` ## Challenges and Limitations ```javascript const challenges = { binary_size: { problem: "WASM binaries can be large", solution: "Code splitting, tree shaking, compression", reality: "Often smaller than equivalent JS bundle" }, startup_time: { problem: "Compilation/instantiation overhead", solution: "Streaming compilation, caching", reality: "Improving with each browser release" }, gc_languages: { problem: "Languages with GC need runtime in WASM", solution: "GC proposal for native GC in WASM", reality: "In progress, experimental support" }, debugging: { problem: "Harder to debug than JavaScript", solution: "Better tooling, source maps, DWARF", reality: "Improving but not there yet" }, exceptions: { problem: "Exception handling inefficient", solution: "Exception handling proposal", reality: "Recently standardized" } }; ``` ## Performance Tips ```c // 1. Use SIMD when possible void process_simd(float* data, size_t len) { #pragma clang loop vectorize(enable) for (size_t i = 0; i < len; i++) { data[i] = data[i] * 2.0f; } } // 2. Minimize allocations // Use arena allocators, object pools // 3. Batch JS↔WASM calls void process_batch(int* data, size_t len) { // Process all at once, not one by one } // 4. Use appropriate optimization levels // -O3 for production // -Os for size-critical code // 5. Profile and benchmark // Use Chrome DevTools Performance tab ``` ## The Road Ahead ```yaml Upcoming Features: Tail Call Optimization: status: Standardized benefit: Efficient recursion, functional programming Garbage Collection: status: In progress benefit: Better support for GC languages Component Model: status: In development benefit: Composable WASM modules, interface types Multiple Memories: status: Standardized benefit: Better memory management Exception Handling: status: Standardized benefit: Efficient exceptions ``` ## Conclusion: A New Computing Paradigm WebAssembly represents more than just "faster web apps." It's a **universal compilation target** that transcends its web origins: 1. **Language Freedom**: Choose the right tool for the job, not the only tool JavaScript offers 2. **Performance Without Compromise**: Near-native speed, predictable execution 3. **Portability**: One binary, countless platforms 4. **Security**: Sandboxed execution by default 5. **Ecosystem**: Leverage decades of existing code **The Vision**: ```rust // The future of software distribution? fn future_vision() { // Instead of: // - Windows .exe // - macOS .app // - Linux .deb/.rpm // - Android .apk // - iOS .ipa // We have: // - Universal .wasm // Run it: // - In browser // - On server // - At edge // - On mobile // - On desktop // - On embedded device // One artifact, universal execution } ``` WebAssembly isn't the future—it's the **present**. Millions of users interact with WASM daily without knowing it (Figma, Google Earth, AutoCAD Web, games, etc.). As the ecosystem matures, WASM will become as ubiquitous as JavaScript, not as a replacement, but as a powerful companion. The web platform evolved from documents to applications. WebAssembly completes this evolution, making the web a truly universal computing platform. **The future is compiled, portable, and fast.** --- *"WebAssembly proves that the web platform can evolve without breaking backward compatibility. By adding a new execution model alongside JavaScript, rather than replacing it, we've unlocked performance while preserving the web's greatest strength: universal accessibility. This is how platforms should evolve—by addition, not substitution."*
Summary Markdown
## 核心要点 **WebAssembly (WASM)** 是一种二进制指令格式,为Web平台带来了近乎原生的性能,打破了JavaScript的垄断,开启了多语言Web时代。 ### 技术特性 - **性能优势**:CPU密集型任务比JavaScript快10-100倍 - **语言多样性**:支持C/C++、Rust、Go、AssemblyScript等多种语言编译到WASM - **二进制格式**:体积更小、解析更快的栈式虚拟机指令 - **安全沙箱**:与JavaScript相同的安全模型,无法访问宿主内存 - **广泛支持**:所有主流浏览器、Node.js、边缘计算平台 ### 架构设计 - **栈式虚拟机**:紧凑的字节码,快速验证和编译 - **静态类型系统**:i32/i64/f32/f64,编译时类型检查 - **线性内存模型**:可扩展的ArrayBuffer,JS和WASM共享 - **模块化设计**:导入/导出机制实现与JavaScript互操作 ### 实际应用 - **游戏引擎**:Unity、Unreal移植到Web - **图形编辑**:Figma、AutoCAD Web的渲染引擎 - **科学计算**:TensorFlow.js WASM后端 - **数据库**:浏览器中的SQLite - **多媒体处理**:视频编码、图像处理、音频合成 ### 性能最佳实践 使用WASM处理CPU密集型任务,JavaScript处理DOM和I/O;批量处理减少边界跨越开销;利用SIMD并行化;合理设置编译优化级别。 ### 生态系统 编译工具链(Emscripten、wasm-pack)、运行时(V8、Wasmtime、Wasmer)、WASI标准(系统接口)、调试支持(Chrome DevTools)。 ### 未来展望 垃圾回收提案、组件模型、尾调用优化、多内存支持。WebAssembly不仅是Web性能的未来,更是通用计算平台的未来——一次编译,到处运行。
Status
Draft
Published
Tags
Selected
Compilation
#compilation
Performance
#performance
Standards
#standards
Web
#web
WebAssembly
#webassembly
Available
AI
#ai
2
AI Systems
#ai-systems
0
Performance
#performance
5
Programming Languages
#programming-languages
4
Architecture
#architecture
2
Compilation
#compilation
2
Database
#database
2
Distributed Systems
#distributed-systems
2
Raft
#raft
2
Standards
#standards
2
Type Systems
#type-systems
2
B-Tree
#b-tree
1
Consensus
#consensus
1
CQRS
#cqrs
1
Deep Learning
#deep-learning
1
Design Patterns
#design-patterns
1
Edge Computing
#edge-computing
1
Embeddings
#embeddings
1
Event Sourcing
#event-sourcing
1
Event-Driven
#event-driven
1
Functional Programming
#functional-programming
1
Kubernetes
#kubernetes
1
Mathematics
#mathematics
1
Optimization
#optimization
1
Paradigms
#paradigms
1
Paxos
#paxos
1
Scalability
#scalability
1
Search
#search
1
Security
#security
1
Storage Engine
#storage-engine
1
Transformer
#transformer
1
Web
#web
1
WebAssembly
#webassembly
1
Zero Trust
#zero-trust
1
ACID
#acid
0
Async
#async
0
Blockchain
#blockchain
0
Build Tools
#build-tools
0
Bundlers
#bundlers
0
Cache
#cache
0
CAP Theorem
#cap-theorem
0
Compilers
#compilers
0
Computer Vision
#computer-vision
0
Concurrency
#concurrency
0
Consistency
#consistency
0
CPU
#cpu
0
Cryptography
#cryptography
0
Distributed Database
#distributed-database
0
Domain-Driven Design
#domain-driven-design
0
Emergence
#emergence
0
FP
#fp
0
Frontend
#frontend
0
Hardware
#hardware
0
Interoperability
#interoperability
0
IO Multiplexing
#io-multiplexing
0
IoT
#iot
0
Istio
#istio
0
Language Design
#language-design
0
LLM
#llm
0
LLVM
#llvm
0
LSM-Tree
#lsm-tree
0
Machine Learning
#machine-learning
0
Memory Safety
#memory-safety
0
Microservices
#microservices
0
Monitoring
#monitoring
0
Multimodal
#multimodal
0
Network
#network
0
Networking
#networking
0
Neural Networks
#neural-networks
0
NLP
#nlp
0
Observability
#observability
0
Patterns
#patterns
0
Production
#production
0
Programming Models
#programming-models
0
React
#react
0
Reactivity
#reactivity
0
Redis
#redis
0
RL
#rl
0
Rust
#rust
0
Service Mesh
#service-mesh
0
Signals
#signals
0
Static Analysis
#static-analysis
0
Systems Programming
#systems-programming
0
Time-Series
#time-series
0
Tracing
#tracing
0
Transactions
#transactions
0
Type Theory
#type-theory
0
Vector Database
#vector-database
0
Vite
#vite
0
Vue
#vue
0
Web Components
#web-components
0
Webpack
#webpack
0
Pin to top of feeds
Publication
Last Published:
2025/11/02 17:18:29
Save Changes