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

• 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 भी इस्तेमाल कर सकें

[jeeeyul]

यह तो बस Mozilla-स्टाइल wishful thinking के काफ़ी करीब है। फ्रंटएंड बाज़ार की प्रतिक्रिया वाली limbic system जैसी प्रकृति से संरचनात्मक रूप से बाहर नहीं निकल सकता। WebAssembly आते ही Doom 3 को port कर दिया गया था। DOM आधुनिक ब्राउज़रों में बहुत पहले ही lightweight proxy object में बदल चुका है, और आधुनिक CPU के JavaScript-विशेष instruction set तथा single-core की quantum सीमाओं को देखते हुए, ऐसा कभी नहीं होगा कि यह तरीका बाज़ार-मूल्य के लिहाज़ से बढ़त हासिल करे.

Electron के अंदर चलने वाले WebAssembly binary का क्या मतलब है? यह तो बस किसी और GitKraken CLI या rust porting की शोहरत बटोरने जैसा लगता है।

[carnoxen]

बाकी बातें छोड़ भी दें, तो <script type="module" src="/module.wasm"></script> की तरह wasm मॉड्यूल को फ़ाइल के रूप में शामिल करने का तरीका काफ़ी आकर्षक लगता है।

[jeeeyul]

और मुझे यह ज़रूर कहना होगा कि WebAssembly की entry barrier बहुत ऊँची होने के दावे बेतुके हैं। बस इतना है कि इसकी ज़रूरत, इसके लिए भुगतान करने की इच्छा से कम है। आपको तेज़ और कम footprint चाहिए, लेकिन साथ में DOM और CSS भी इस्तेमाल करना है? यह कैसी black comedy है।

[GN⁺]

Hacker News टिप्पणियाँ

• लगता है यह सब करीब पाँच साल पहले ही संभव हो सकता था
  WebAssembly में WebIDL सपोर्ट करने के शुरुआती लक्ष्य को छोड़कर एक और IDL बनाने की बात करना, और DOM access की कमी को समस्या न मानना, अफसोसजनक लगा
  बेशक मैं बाज़ार की वास्तविकताओं को समझता हूँ, लेकिन खोया हुआ समय खटकता रहता है
  संबंधित संदर्भ लिंक: commit रिकॉर्ड, stringref पुनरावलोकन, ACM लेख
  • मैंने पहले interface-types proposal पर काम करने में हिस्सा लिया था
    बाद में दो और लक्ष्य जोड़े गए: एक non-web API support, दूसरा language interoperability
    WebIDL, JS और Web API का union है, इसलिए उसकी expressiveness तो अधिक है, लेकिन उसमें ऐसे कई concept थे जो इन लक्ष्यों से टकराते थे
    इसलिए component interface ने expressiveness कम होने के बावजूद कहीं अधिक portable intersection approach चुना
    निजी तौर पर मुझे लगता है कि DOM access महत्वपूर्ण है, लेकिन Wasm CG ज़्यादा प्राथमिकता वाले कामों में व्यस्त था
    मैंने यह लेख इसलिए लिखा कि लोग जानें, यह समस्या अब भी याद है और इस पर काम जारी रखने की योजना है
  • मैं सचमुच चाहता हूँ कि stringref फिर वापस आए
• WASM की entry barrier वास्तव में बड़ी है
  toolchain और build process इतने जटिल हैं कि हर बार इस्तेमाल करते समय cognitive load महसूस होता है
  performance glue के बिना काफ़ी बेहतर है, लेकिन उतने ही ज़्यादा जोखिम भी हैं
  उम्मीद है component model नई complexity नहीं लाएगा, लेकिन कई language examples देखकर लगता है कि काफ़ी भ्रम पहले से ही मौजूद है
  खासकर Go उदाहरण में generated files बहुत ज़्यादा हैं, और developer के नज़रिये से tooling simplification बेहद ज़रूरी है
  अभी ऐसा लगता है कि complexity हट नहीं रही, बस एक जगह से दूसरी जगह जा रही है
  • मैं मानता हूँ कि tooling अभी शुरुआती चरण में है
    wasm component specification लगातार बदलती रही है, इसलिए churn बहुत रहा है
    लक्ष्य यह है कि web developer खुद WIT न लिखें, बल्कि Web API को library की तरह इस्तेमाल कर सकें
    लेकिन वहाँ तक पहुँचने में अभी काफ़ी समय लगेगा
• WebAssembly component की प्रगति शानदार है, लेकिन लगता है कि web API को छोटे standard units में विभाजित करने का मौका छूट रहा है
  उदाहरण के लिए text sharing, media sharing, application sharing जैसी इकाइयों में बाँटा जाए तो security भी बेहतर होगी और छोटी टीमें browser alternatives भी बना सकेंगी
  लेकिन विशाल web API और CSS का पैमाना ही browser monopoly को टिकाए रखने वाला तत्व है, इसलिए ऐसी कोशिशें कठिन लगती हैं
  अच्छा होगा अगर WebAssembly registry को standardize किया जाए ताकि components को आसानी से compose किया जा सके
  आखिरकार web, distributed operating system definition बनाने की प्रक्रिया है
• अगर आप आधुनिक WebAssembly सीखना चाहते हैं, तो Component Model Book की सिफारिश है
  concepts से लेकर code examples तक सब अच्छा व्यवस्थित है
  JS ecosystem में StarlingMonkey, ComponentizeJS, jco ये तीन project मुख्य हैं
  फिलहाल सबसे mature toolchain Rust की है, लेकिन LLVM-आधारित भाषाओं (C/C++, Go, Python आदि) का support भी लगातार बेहतर हो रहा है
  WebAssembly का लक्ष्य local toolchain में स्वाभाविक रूप से घुल-मिल जाने वाला compile target बनना है
• “first-class” अभिव्यक्ति इसलिए महत्वपूर्ण है क्योंकि अधिकांश developer performance से ज़्यादा friction की वजह से platform छोड़ देते हैं
  अगर अभी भी language-specific glue code या दो runtime models समझने पड़ें, तो WebAssembly अभी भी “सिर्फ चरम परिस्थितियों में इस्तेमाल होने वाला टूल” बना रहेगा
  असली बदलाव लाने के लिए सामान्य build path को सरल बनाना होगा
• web, dynamic feature detection के बिना काम नहीं करता
  Component Model में यह हिस्सा कैसे संभाला जाता है, यह स्पष्ट नहीं है
  DOM हर browser में अलग है, और हर page load पर feature अलग हो सकते हैं
  JS bridge layer में polyfill आसानी से लगाया जा सकता है, लेकिन WIT interface में runtime method detection या polyfill कठिन है
  performance के अलावा ecosystem की flexibility भी महत्वपूर्ण है
• यह लेख “WebAssembly wall” की घुटन को अच्छी तरह व्यक्त करता है
  JS glue code को सीधे manage करना या auto-generation tools पर निर्भर रहना, बड़ा पीछे जाना लगता है
  Dodrio experiment में glue हटाकर 45% overhead reduction हासिल करना प्रभावशाली था
  लेकिन यह जानने की जिज्ञासा है कि WebAssembly Component Model जब Web API के साथ सीधे interact करता है, तब memory management कैसे होता है
  क्या Wasm GC proposal का इस्तेमाल DOM references को बनाए रखने में होता है, या अब भी JS GC पर निर्भर रहना पड़ता है?
  उम्मीद है Wasm सचमुच एक first-class citizen बन पाएगा
  • हाल में v8 और Bun के sendMessage improvements क्या इस समस्या को कम कर सकते हैं, यह जानने की जिज्ञासा है
    लेकिन अभी IPC फिर भी अप्रभावी है, और मुझे लगता है memory page unit transfer जैसी किसी विधि की ज़रूरत है
  • यह भी कहा गया कि ऊपर की टिप्पणियाँ LLM द्वारा लिखी हुई लगती हैं, इसलिए HN नियमों के उल्लंघन की संभावना बताई गई (guidelines)
• web दिलचस्प प्रयोगों की एक लंबी श्रृंखला रहा है
  किसी को भी मेरे कंप्यूटर पर जटिल प्रोग्राम चलाने देना security के लिहाज़ से पागलपन भरा विचार था, लेकिन हमने वास्तव में ऐसा ही किया
  JS की वजह से 20 साल तक countless browser security bugs झेलने पड़े, लेकिन अब design principles और mitigations स्थापित हो चुके हैं
  और अब फिर एक और खतरनाक execution paradigm की ओर बढ़ना, विडंबनापूर्ण भी है और सुंदर भी
  • असल में यह भूमिका operating system (OS) को निभानी चाहिए
    mobile OS यह काम desktop की तुलना में कहीं बेहतर करते हैं
  • सुरक्षा समस्याओं का मुख्य कारण JS नहीं बल्कि browser API थे
  • “replacement” जैसा कुछ नहीं हो रहा, बस विस्तार हो रहा है
  • मुझे जानना है कि WASM, JS से अधिक खतरनाक क्यों माना जा रहा है
  • समस्या WebUSB जैसी sandbox तोड़ने वाली सुविधाओं में है, wasm में नहीं
• आजकल के नए standards, सरलता से ज़्यादा जटिल JS boilerplate को प्राथमिकता देते हैं
  वे engineer-केंद्रित हैं, और author-friendly default workflow मौजूद नहीं है
  फिर भी अच्छा है कि अब भी कुछ लोग इन समस्याओं की परवाह करते हैं
• व्यक्तिगत रूप से, मैं अब भी इसे अच्छा विचार नहीं मानता (पिछली चर्चा)
  ऐसा लगता है जैसे DOM API को 1:1 map करने के लिए सिर्फ 2x तेज़ string processing हेतु ज़रूरत से ज़्यादा engineering की जा रही है
  WebGL2, WebGPU, WebAudio जैसे API में JS shim की लागत पहले ही बहुत मामूली है
  असली समस्या GPU buffer copy जैसी जगहों पर है, और component model वहाँ मदद नहीं करता
  मैं WebGL2 या WebGPU में दसियों हज़ार draw calls टेस्ट करने वाले benchmarks देखना चाहूँगा
  • कुछ cases में बड़ा सुधार नहीं होगा, लेकिन DOM performance अब भी कई apps की bottleneck है
    performance के अलावा developer experience (DX) में सुधार भी महत्वपूर्ण है
    अभी शुरुआत करना बहुत कठिन है, और लाभ पाने के लिए हर किसी को विशेषज्ञ बनना पड़ता है
  • सिर्फ 2x तेज़ string processing ही नहीं, बल्कि glue code की ज़रूरत न होना सबसे बड़ा लाभ है
  • WebAssembly mobile OS की closed nature के विकल्प के रूप में उभर सकता है
    अगर यह native app स्तर की efficiency के साथ प्रतिस्पर्धा कर सके, तो web के भविष्य के लिए यह दूरदर्शी बदलाव होगा
  • केवल DOM access तेज़ हो जाना भी अपने आप में काफ़ी मायने रखता है
  • component model अनावश्यक self-imposed work जैसा लगता है
    coding agent के युग में वे जिस DX सुधार की बात करते हैं, उसका महत्व शायद अब नहीं रहा