वेब पर WebAssembly को first-class language बनाना

 (hacks.mozilla.org)
21 पॉइंट द्वारा GN⁺ 2026-03-12 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • WebAssembly 2017 में पहली रिलीज़ के बाद से C/C++ जैसी low-level languages के execution को support करते हुए विकसित हुआ है, लेकिन अब भी वेब प्लेटफ़ॉर्म पर इसे second-class language की तरह माना जाता है
  • सिर्फ JavaScript ही Web API के साथ सीधे interact कर सकता है, और WebAssembly को इसके लिए जटिल JS binding code (glue code) लिखना पड़ता है
  • यह संरचना loading process की complexity, performance overhead, language-specific toolchain fragmentation जैसी समस्याएँ पैदा करती है, जिससे developer experience खराब होता है
  • Mozilla ने इसे हल करने के लिए WebAssembly Component Model प्रस्तावित किया है, जो JS के बिना भी standardized तरीके से Web API calls और module loading संभव बनाता है
  • अगर यह मॉडल स्थापित हो जाता है, तो WebAssembly browser के भीतर first-class runtime environment के रूप में जगह बना सकता है, जिससे आम developers भी इसे आसानी से इस्तेमाल कर सकेंगे

WebAssembly को second-class language क्यों माना जाता है

  • WebAssembly को web platform access सिर्फ JavaScript के ज़रिए ही मिल सकता है, और उसे सीधे Web API call करने की अनुमति नहीं है
    • JavaScript को <script> टैग से आसानी से load किया जा सकता है, लेकिन WebAssembly के लिए JS API के ज़रिए manual loading process की ज़रूरत होती है
    • WebAssembly.instantiateStreaming() जैसे जटिल API calls करने पड़ते हैं, जिन्हें developers को याद रखना पड़ता है या tools से automate करना पड़ता है
  • esm-integration proposal JS module system के ज़रिए .wasm files को सीधे import करने की सुविधा देता है, जिससे loading process सरल होती है
    • <script type="module" src="/module.wasm"></script> के रूप में सीधे load किया जा सकता है

Web API access की सीमाएँ

  • JavaScript में console.log("hello, world") की एक लाइन से होने वाला काम, WebAssembly में JS memory access, string decoding, function wrapping जैसी जटिल प्रक्रिया मांगता है
    • WebAssembly console object या DOM को access नहीं कर सकता, इसलिए JS में memory sharing और function import/export के ज़रिए indirect calls करनी पड़ती हैं
  • इस प्रक्रिया में बनने वाला binding code (glue code) हर language में अलग होता है, और embind, wasm-bindgen जैसे tools से auto-generate किया जाता है
    • लेकिन इससे build complexity बढ़ती है, runtime overhead आता है, और language-specific incompatibility जैसी समस्याएँ पैदा होती हैं

WebAssembly के first-class language न बन पाने के तकनीकी कारण

  • compiler integration की कठिनाई: हर language के compiler को JS और web platform integration code अलग से generate करना पड़ता है, और यह reusable नहीं होता
  • standard compiler incompatibility: rustc --target=wasm से बनी file browser में सीधे run नहीं होती
    • platform integration implement करने वाले unofficial toolchains अलग से install करने पड़ते हैं
  • documentation ecosystem का bias: MDN जैसे वेब दस्तावेज़ अधिकतर JavaScript-केंद्रित होते हैं, जिससे दूसरी languages के users के लिए entry barrier ऊँचा रहता है
  • performance issue: JS binding से होकर जाने वाले DOM calls, direct calls की तुलना में 45% performance drop दिखाते हैं
    • Dodrio framework के प्रयोग में JS glue हटाने पर DOM changes लागू करने का समय आधा हो गया
  • JavaScript dependency: WebAssembly को production में इस्तेमाल करने के लिए अंततः JS समझना पड़ता है, जो leaky abstraction की समस्या पैदा करता है

WebAssembly Component Model का आगमन

  • WebAssembly Component Model कई languages और runtimes में साझा रूप से इस्तेमाल किए जा सकने वाले standardized execution unit को परिभाषित करता है
    • Web API access, module loading, और linking process को JS के बिना सीधे किया जा सकता है
    • इसे विभिन्न languages से generate किया जा सकता है, और browser या Wasmtime जैसे कई runtimes में run किया जा सकता है
  • WIT (Interface Description Language) के ज़रिए ज़रूरी API declare की जा सकती हैं, और उन्हें component के भीतर से सीधे call किया जा सकता है
    • उदाहरण: 
      component {
  import std:web/console;
}
      → Rust code में console::log("hello, world") call किया जा सकता है
  • Browser <script type="module" src="component.wasm"></script> से component को सीधे load कर सकता है, और JS के बिना Web API binding को अपने आप handle कर सकता है

JavaScript के साथ interoperability

  • Component Model hybrid app architecture को भी support करता है
    • उदाहरण: image decoder को WebAssembly में लिखकर, JS में import { Image } from "image-lib.wasm"; के रूप में call किया जा सकता है
    • JS, WebAssembly component को सामान्य module की तरह import/export करके इस्तेमाल कर सकता है

आगे की दिशा और भागीदारी

  • Mozilla, WebAssembly CG के साथ मिलकर Component Model standardization पर काम कर रहा है, और Google भी इसकी समीक्षा के चरण में है
  • Developers Jco या Wasmtime के माध्यम से browser या CLI में इसका प्रयोग कर सकते हैं
  • अगर यह मॉडल स्थापित हो जाता है, तो WebAssembly “power users के फीचर” से आगे बढ़कर ऐसा web technology बन सकता है जिसे आम developers भी इस्तेमाल कर सकें

संबंधित पढ़ाई

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.