WASI 0.2.0 और यह क्यों महत्वपूर्ण है
WebAssembly का नया WASI Preview 2 release, browser के बाहर Wasm को एक व्यावहारिक, portable runtime बनाने की दिशा में एक बड़ा कदम माना जा रहा है, क्योंकि यह capability-based system interface और polyglot interoperability के लिए उभरते component model/Canonical ABI पर आधारित है। टिप्पणीकार इस पर बहस करते हैं कि क्या यह दृष्टिकोण एक अत्यधिक जटिल “second system” है या secure, serverless-style workloads और plugin systems के लिए एक आवश्यक नींव, और इसकी तुलना JVM/CLR, Java applets, और NaCl जैसे पुराने प्रयासों से करते हैं। वास्तविक-world उपयोगों (Figma से लेकर VS Code extensions तक) और भविष्य की संभावनाओं (GUI APIs, async, और Preview 3 में GC) को लेकर उत्साह है, साथ ही standardized graphics, threading, और C जैसी भाषाओं के लिए smooth tooling जैसी कमी पर निराशा भी है.
ग्राफ़िक्स और GUI APIs
- कई टिप्पणीकार WASI के लिए एक मानक framebuffer-शैली का GUI API चाहते हैं, ताकि WASM ऐप्स ब्राउज़र के बाहर भी स्क्रीन पर ड्रॉ कर सकें।
- कुछ अन्य लोग तर्क देते हैं कि framebuffers पुराने हो चुके हैं और WebGPU जैसे उच्च-स्तरीय API बेहतर हैं; प्रतिवाद: WebGPU अभी सर्वत्र उपलब्ध नहीं है और WASM केवल ब्राउज़र तक सीमित नहीं है।
- WASI से जुड़े योगदानकर्ता कहते हैं कि graphics को vendors ने रोका नहीं है; बस contributor focus नहीं मिला, क्योंकि वह मुख्यतः serverless और foundational हिस्सों पर रहा है।
- भविष्य के GUI/IO-device प्रस्तावों में रुचि है, लेकिन अभी कोई ठोस मानक नहीं है।
Component Model, Preview 2, और Compatibility
- WASI Preview 2, WebAssembly Component Model पर आधारित है, जो “core WASM” को उच्च-स्तरीय APIs से अलग करता है।
- मौजूदा WASI modules सीधे compatible नहीं हैं; adapters की ज़रूरत होती है, जिसे कुछ लोग messy और एक “second-system effect” मानते हैं।
- दूसरे लोग तर्क देते हैं कि component model साफ़ interop और एक canonical ABI (कोई shared memory exports नहीं, handle-based resources) के बारे में है, जो अलग-अलग भाषाओं और memory models को साथ काम करने देता है।
- Component model को WASI के बिना भी इस्तेमाल किया जा सकता है और यह standardization path पर है, हालांकि अभी पूरी तरह formalized नहीं हुआ है।
WASI कौन-सी समस्या हल करता है
- कई व्याख्याएँ दी गईं: core WASM अकेले I/O नहीं कर सकता; WASI एक capability-based system interface (files, networking, आदि) परिभाषित करता है, खासकर non-browser runtimes के लिए।
- इसकी तुलना “WASM के लिए POSIX” से की जाती है, हालांकि कुछ लोग नोट करते हैं कि WASIX अधिक सीधे POSIX semantics के लक्ष्य पर है।
- Capability-based security (न्यूनतम, स्पष्ट permissions) को एक प्रमुख design goal के रूप में रेखांकित किया गया है।
Use Cases बनाम संदेह
- संदेह करने वाले कहते हैं कि लगभग 10 साल के WASM-संबंधित काम के बाद भी उन्हें ज़्यादातर demos, जटिल tooling, और अस्पष्ट आर्थिक मूल्य दिखता है, खासकर native builds की तुलना में।
- दूसरे लोग व्यावहारिक उपयोग बताते हैं: browser apps (design tools, games, video, Flash emulation), embedded systems, polyglot plugins, VS Code extensions, और game mod scripting।
- Server-side WASM को promising माना जाता है, लेकिन यह अभी immature है; performance और cloud-provider support अभी खुले प्रश्न हैं।
JVM/CLR और Applets से तुलना
- कुछ लोग WASI को CLR, JVM, और पहले के bytecode प्रयासों के विचारों को फिर से करने जैसा मानते हैं; बहस इस बात पर केंद्रित है कि क्या “redoing” बुरा है, अगर यह संस्करण वास्तविक adoption हासिल करे और अधिक open हो।
- Applets बनाम WASM: टिप्पणीकार WASM के छोटे exposed surface, बेहतर startup performance, multi-language focus, और vendor coalition backing पर ज़ोर देते हैं।
Polyglot, FFI, और भविष्य की विशेषताएँ
- आसान polyglot FFI में गहरी रुचि है; Preview 2, component model, और canonical ABI को इसकी नींव माना जा रहा है।
- Tools और frameworks (जैसे plugin systems) उभर रहे हैं, लेकिन data types और ergonomics में अभी भी सीमित हैं।
- GC और async (Preview 3) जैसी भविष्य की जोड़ियों से उम्मीद है कि WASM JavaScript और Dart जैसी भाषाओं के लिए बेहतर runtime बनेगा, और WASM में compiled JS engines के साथ integration सुधरेगा।