Show HN: WebAssembly में Firefox
WebAssembly के अंदर Firefox को ही चलाना—व्यावहारिक रूप से एक browser के अंदर browser—कई लोगों को इसकी मौजूदा usability और performance के कारण प्रभावित करता है, यहाँ तक कि YouTube जैसी जटिल sites भी संभाल लेता है। टिप्पणीकार technical choices (single‑process Gecko, JSPI requirements, एक custom WASM→JS JIT, TCP-over-WebSocket networking) पर चर्चा करते हैं और security implications पर बहस करते हैं, जहाँ कुछ लोगों को isolation की मजबूत परतें दिखती हैं तो कुछ को नए attack surfaces या sandbox regressions। दूसरे लोग वास्तविक उपयोग मामलों, लागतों (जिसमें port में मदद के लिए AI tokens पर $25k के दावे शामिल हैं), और remote relays पर निर्भरता पर सवाल उठाते हैं, जबकि locked‑down TVs पर ad-blocking से लेकर user extensions को bypass करने वाले भविष्य के “inner browser” tricks तक की कल्पना करते हैं।
समग्र प्रतिक्रिया
- कई लोगों को यह डेमो “rad”/“amazing” लगता है और आश्चर्यजनक रूप से performant भी, खासकर इस बात को देखते हुए कि यह ब्राउज़र के अंदर एक पूरा Firefox engine चलाता है।
- अन्य लोग व्यावहारिक उपयोग के मामलों पर सवाल उठाते हैं और इसे मुख्यतः WebAssembly के लिए एक आकर्षक proof-of-concept मानते हैं।
तकनीकी कार्यान्वयन
- Firefox single‑process build का उपयोग करता है, जिसमें GPU/WebRender passthrough से canvas तक और वैकल्पिक software fallback शामिल है।
- WebAssembly JSPI (wasm_js_promise_integration) पर निर्भर करता है ताकि event loop को yield किया जा सके और OffscreenCanvas को sync किया जा सके; Firefox उपयोगकर्ताओं को एक hidden flag सक्षम करना होगा, और पूर्ण support भविष्य के Firefox/Safari versions में अपेक्षित है।
- इसमें एक experimental WASM→JS JIT और कुछ WebAssembly interpreter backend work शामिल है, तथा performance और stability पर काफी मेहनत की गई है।
- संदर्भित prior art: WebKit-in-Wasm ports और पहले का WebKit.js।
प्रदर्शन और संगतता
- यह कई desktop उपयोगकर्ताओं के लिए अच्छी तरह काम करता है (ARM Macs और Steam Deck सहित), यहाँ तक कि YouTube भी चलाता है।
- mobile पर (Firefox और Chrome/Android) memory limits, missing features, या पहले frame के बाद freezing के कारण यह fail होता है या आंशिक रूप से काम करता है।
- nested “Firefox-in-Wasm inside Firefox-in-Wasm” कभी-कभी काम करता है, लेकिन अस्थिर है।
- कुछ उपयोगकर्ता wasm browser के अंदर network speeds 10× धीमी और विभिन्न bugs (GPU driver issues, unsupported syscalls) की रिपोर्ट करते हैं।
सुरक्षा और नेटवर्किंग
- कुछ लोग तर्क देते हैं कि यह sandboxing को बहुत मज़बूत करता है (browser inside browser, plus wasm runtime), जबकि अन्य ध्यान दिलाते हैं कि यह Firefox की सामान्य multiprocess isolation को निष्क्रिय करता है और भारी रूप से संशोधित, AI-edited build पर निर्भर करता है।
- सभी TCP traffic एक WebSocket-based relay (WISP protocol) के माध्यम से proxied होता है, जो Cloudflare पर चलता है; TLS ब्राउज़र के अंदर OpenSSL को Wasm में compile करके संभाला जाता है।
- wasm browser के अंदर IP proxy का होता है, जिससे trust और abuse संबंधी चिंताएँ उठती हैं (cloaking, संभावित mischief)।
- “end-to-end encryption” के दावों की आलोचना की जाती है क्योंकि site wasm code serve करती है और नियंत्रित करती है कि क्या चले।
उपयोग के मामले और प्रभाव
- सुझाए गए उपयोगों में locked‑down smart TVs में ad blocking और extensions जोड़ना, तथा एक general-purpose browser sandbox के रूप में उपयोग शामिल है।
- अन्य लोगों को आशंका है कि publishers user ad blockers को bypass करने के लिए obfuscated “inner browsers” ship करेंगे, संभवतः भारी RAM और complexity cost के साथ।
लागत और AI की भागीदारी
- इस port ने debugging और JIT research में लगभग $25k मूल्य के AI tokens खर्च किए, जिससे cost, feasibility बनाम human work, और यह “fun experiment” है या serious research—इन पर चर्चा शुरू हुई।