सबसे अच्छा WebAssembly रनटाइम शायद कोई रनटाइम ही न हो

Wasm→C के रूप में “VM-less” सैंडबॉक्सिंग

• विचार: C (या अन्य भाषाओं) को WebAssembly में कम्पाइल करें, फिर wasm को C में ट्रांसपाइल करके नेटिव रूप से कम्पाइल करें, ताकि भारी रनटाइम के बिना wasm की सुरक्षा गारंटियाँ मिलें।
• Firefox पहले से इसका एक रूप (RLBox) करता है: अलगाव सीमा के रूप में wasm, फिर गति के लिए वापस कम्पाइल किया गया।
• w2c2 वर्तमान में सैंडबॉक्सिंग के बजाय पोर्टेबिलिटी पर केंद्रित है; wasm2c bounds checks, type-safe indirect calls जैसी spec-conforming सुरक्षा का लक्ष्य रखता है।

सुरक्षा, bounds checking, और OS isolation

• कुछ लोगों का तर्क है कि यह दोहराव है: processes को पहले से MMU-आधारित isolation मिलती है; पारंपरिक seccomp-शैली के sandboxes और containers उतने ही या उससे अधिक सुरक्षित हो सकते हैं, और syscall surface भी संकरा होता है।
• दूसरों का कहना है कि embedded wasm वहाँ आकर्षक है जहाँ आप processes/containers नहीं बना सकते, और plugin-जैसे use-cases में।
• Wasm linear memory पर enforced bounds के साथ निर्भर करता है; production engines लगभग zero-cost checks के लिए guard pages + mprotect/fault handlers का उपयोग करते हैं।
• एक महत्वपूर्ण सीमा: wasm logic bugs या intra-module memory corruption को ठीक नहीं करता; untrusted modules host से isolated होते हैं, लेकिन internal unsafe C फिर भी unsafe रहता है।

NaCl, PNaCl, और wasm तक हम कैसे पहुँचे

• Native Client ने समान समस्याएँ हल कीं, लेकिन CPU-specific था; PNaCl का LLVM-bitcode wire format और glibc entanglement गड़बड़ थे।
• asm.js एक सरल विकल्प के रूप में उभरा; wasm उन सीखों का multi-vendor standardization था।
• कुछ लोग NaCl की विफलता को मुख्यतः तकनीकी मानते हैं; अन्य राजनीतिक / ecosystem कारणों पर ज़ोर देते हैं।

C बनाम LLVM IR बनाम अन्य IRs

• Pro-C: C स्थिर है, व्यापक रूप से समर्थित है, और portable IR के रूप में काम करता है, जिसमें obscure OSes (जैसे Mac OS 9, अजीब CPUs) भी शामिल हैं।
• Anti-C: C richer aliasing, sum types, या detailed UB handling को व्यक्त नहीं कर सकता; LLVM IR अधिक expressive होगा, लेकिन वह moving target है और version-tied है।
• दृष्टिकोण: wasm को एक universal mid-layer (→wasm→C/anything) के रूप में देखें, न कि हर C compiler में bounds checks जोड़ने के रूप में।

Bytecode design और performance debates

• कुछ लोग wasm के stack-based design की आलोचना करते हैं कि यह register-based IRs की तुलना में जटिलता बढ़ाता है; अन्य इसे पर्याप्त और battle-tested मानते हैं।
• इस बात पर असहमति है कि wasm कितना “universal” बना रहेगा जैसे-जैसे यह बढ़ेगा (GC, threads, richer features) बनाम JVM/CLR की तरह opinionated हो जाएगा।

Use cases, hype, और skepticism

• Enthusiasts: wasm sandboxed plugins, serverless, embedded, cross-language libraries, और software preservation के लिए एक portable ISA है; network effects technical warts से भारी हैं।
• Skeptics: hype novelty और security को बढ़ा-चढ़ाकर पेश करता है; existing bytecodes और VMs दशकों से समान लक्ष्यों को संभालते आए हैं; wasm web UI की परेशानियों (HTML/CSS/JS complexity) को inherently हल नहीं करता।
• कुछ लोग browser के बाहर wasm (WASI, plugin systems, Cosmopolitan-style packaging) को browser apps से अधिक प्रभावशाली मानते हैं।

GC, उच्च-स्तरीय भाषाएँ, और DOM

• उम्मीद है कि Wasm GC managed languages की मदद करेगा, लेकिन Go/Java जैसे runtimes के साथ mismatch और efficient stack switching जैसी चीज़ों की कमी को लेकर चिंताएँ हैं।
• Wasm सीधे DOM/WebGPU को छू नहीं सकता; JS shims की आवश्यकता होती है। कुछ लोग पूरी तरह JS-free web apps चाहते हैं; अन्य तर्क देते हैं कि DOM/Web APIs मूलतः JS-shaped हैं और overhead, DOM costs की तुलना में, नगण्य है।