Wasm नया CGI है

 (roborooter.com)
3 पॉइंट द्वारा GN⁺ 2024-10-11 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Wasm कोई CGI प्रोटोकॉल नहीं है, बल्कि इसे अगले application model के रूप में देखा जा सकता है जो वेब ऐप्स की execution unit और deployment method को बदल देगा, ठीक वैसे ही जैसे cgi-bin ने किया था
  • CGI, FastCGI, Rack/WSGI और serverless—इन सभी ने request handling और server management को नए सिरे से design किया है, और इनका साझा लक्ष्य high-performance applications को बनाना और maintain करना आसान बनाना था
  • Wasm modules host runtime में चलते हैं, और isolated memory व snapshots के जरिए clean execution state बनाए रखते हुए startup cost घटा सकते हैं
  • native threads का अभाव, JIT की असंभवता, data copy cost, और Interface Types व module linking की अपरिपक्वता Wasm-आधारित server execution model की मुख्य सीमाएँ हैं
  • जब serverless functions और edge functions Wasm execution environment के साथ जुड़ते हैं, तो cold start और isolation cost घट सकती है, और कई भाषाओं के modules को अधिक हल्के तरीके से compose किया जा सकता है

CGI से serverless तक चला आ रहा web application model

  • CGI का मूल महत्व Common Gateway Interface protocol से ज्यादा उस application model में था जिसमें cgi-bin folder में रखे scripts या executables को URL से call किया जाता था
  • यह शुरुआती web application model था जिसने web को document archive से interactive applications के network में बदल दिया
  • हर request पर नया process चलाने वाली संरचना होने के कारण, आज के मानकों से process startup और script parsing की लागत बड़ा bottleneck बन जाती है

FastCGI और भाषा-विशिष्ट web servers में बदलाव

  • FastCGI ने CGI की performance समस्या कम करने के लिए ऐसा model पेश किया जिसमें लंबे समय तक चलने वाला process CGI requests को handle करता है
    • web server हर request पर नया process launch नहीं करता, बल्कि एक या अधिक long-running processes से communicate करता है
    • मौजूदा CGI applications इस assumption पर बनी थीं कि request के बाद process समाप्त हो जाएगा, इसलिए long-running environment में resource leaks होना आसान था
  • इसके बाद language-based web servers एक convention बन गए, और applications request/response model के केंद्र में बनाईं जाने लगीं
    • Apache या nginx जैसे feature-rich और proven web servers के पीछे deploy करके application को slow requests और HTTP details से अलग रखना आम तरीका था
    • server implementations हर request पर fork, OS या language threads, event या reactor model जैसी अलग-अलग process management strategies का उपयोग करती हैं
  • Ruby community के Rack interface ने Python के Flask application server और WSGI specification को भी प्रभावित किया
    • सरल रूप में, request HTTP method, headers hashmap, input byte string या stream से बनी होती है
    • response status code, headers object, response byte string या stream से बना होता है

cloud autoscaling और serverless का trade-off

  • physical server या virtual server आधारित model में चल रहे servers की संख्या सीधे manage करनी पड़ती थी
    • traffic ज्यादा हो तो application server धीमा हो सकता है
    • traffic कम हो तो कई computers idle रह सकते हैं
  • cloud की autoscaling CPU, memory load और time of day के अनुसार application servers की संख्या adjust करने देती है
    • नए computer को scale out करने में application और configuration के आधार पर 2–20 मिनट लग सकते हैं
    • scaling cloud hosting region में उपलब्ध resources पर भी निर्भर करती है
  • Amazon Lambda और API Gateway को जोड़ने वाली serverless compute ने servers के बजाय functions manage करने वाला model बनाया
    • हर request के लिए single process, isolated CPU और isolated memory की गारंटी देता है
    • process अधिकतम कुछ घंटों तक reuse हो सकता है, लेकिन use न होने पर pause या remove कर दिया जाता है
    • AWS request volume के अनुसार कुछ seconds के स्तर पर scale up और scale down कर सकता है
  • serverless में स्पष्ट trade-offs हैं
    • नए process की लागत के कारण concurrent request scaling के दौरान कुछ requests cold start का सामना करती हैं
    • response के बाद process pause हो सकता है, इसलिए requests के बीच persistent TCP connections manage करना कठिन होता है
    • HTTP-based database APIs serverless model में लोकप्रिय हैं, क्योंकि वे कई connections झेल सकती हैं और functions के साथ scale up/down करना आसान होता है
  • हर request के लिए dedicated CPU और memory देने की विशेषता workload के आधार पर फायदा भी हो सकती है और नुकसान भी
    • कुछ workloads resource management घटाकर cost और scaling की चिंताएँ कम कर सकते हैं
    • अन्य workloads तब अधिक efficient हो सकते हैं जब single process कई requests handle करे या shared memory से batching/caching का उपयोग करे
    • CMS-based web application को serverless पर ले जाकर cost 90% घटाने का उदाहरण और event analytics service को server-based model पर ले जाकर cost 90% घटाने का उदाहरण, दोनों पेश किए गए हैं

server पर Wasm execution model

  • Wasm शुरुआत में browser में high-performance code चलाने के लिए develop हुआ था, और asm.js जैसी कोशिशों से भी जुड़ा है
  • WebAssembly stack-based virtual machine के लिए binary instruction format है, और इसे कई programming languages के portable compilation target के रूप में design किया गया है
    • यह web के client और server applications की deployment को संभव बनाता है
    • इसे size और load time के लिहाज से efficient binary format में encode होने के लिए design किया गया है
    • अलग-अलग platforms की common hardware capabilities का उपयोग करके near-native speed पर execution इसका लक्ष्य है
  • फिलहाल कई भाषाओं को Wasm instructions में compile करके browser और server दोनों पर चलाया जा सकता है
  • browser द्वारा मांगा गया isolation और security model server applications के लिए भी उपयोगी है
    • untrusted code को VM या Docker container की तुलना में कहीं हल्के रूप में isolate किया जा सकता है
  • Node.js, Cloudflare Workers, Deno जैसे V8-based serverless environments browser में संचित Wasm execution capabilities का उपयोग करते हैं
  • Fastly, Shopify, Suborbital जैसे Wasm-native environments भी मौजूद हैं

modules, host, memory, snapshots

  • Wasm modules virtual machine के लिए instructions होते हैं, इसलिए execution के लिए runtime की जरूरत होती है
    • runtime सामान्य Wasm को local architecture के अनुसार compile करता है और execution environment देता है
    • कुछ environments Linux system के POSIX API जैसी interfaces देते हैं
    • कुछ environments host system के केवल specific functions देते हैं और module के export functions को execute करवाते हैं
  • WebAssembly programs modules units में संगठित होते हैं, और module चलाने वाली VM को host कहा जाता है
    • module deployment, loading और compilation की unit है
    • यह types, functions, tables, memory और global values की definitions का collection होता है
    • import और export declare कर सकता है, और data segments, element segments व start function के रूप में initialization दे सकता है
  • Wasm की “memories” को बिना टूटे contiguous byte arrays के रूप में दर्शाया जाता है, जिन्हें host instantiation के समय allocate करता है
    • हर guest module को memory isolation मिलता है
    • यह memory virtual machine की RAM की तरह काम करती है
    • इसे खाली दिया जा सकता है या data segments से पहले से भरा जा सकता है
  • module isolation के तरीके की वजह से module को pause करके memory को data segment के रूप में store किया जा सकता है
    • यह virtual machine snapshot जैसा concept है
    • paused module की कई copies start की जा सकती हैं
  • Wizer Wasm module को instantiate करता है, initialization function चलाता है, फिर instance state record करके Wasm binary को फिर से लिखता है
    • global values की state को सीधे initialize करता है
    • non-zero memory regions को record करता है
    • मौजूदा data segments हटाकर recorded memory regions के data segments से replace करता है
  • यह तरीका नए process जैसा clean execution देता है, लेकिन नए process की startup cost से बचाता है
    • यह CGI के नुकसानों के बिना CGI के करीब है
    • आधुनिक शब्दों में, यह cold start के बिना serverless के करीब है

Wasm की सीमाएँ और फायदे

  • Wasm में native configuration में threads नहीं होते
    • blocking operations को host methods में ले जाना पड़ता है
    • host file या network interface read/write wrappers दे सकता है, module को pause कर सकता है, या callback handlers दे सकता है
    • reactor model या blocking model बनाया जा सकता है, लेकिन thread proposal लागू होने तक execution environment design का बड़ा महत्व रहेगा
  • security कारणों से dynamic Wasm code generation की अनुमति नहीं है, इसलिए JIT compilation संभव नहीं है
    • runtime में code को address की तरह handle नहीं किया जा सकता
    • V8, CRuby जैसे execution environments जो performance के लिए JIT पर निर्भर हैं, Wasm VM में नहीं चल सकते या उन्हें JIT छोड़ना होगा
    • scripts के लिए optimized runtime को build stage पर output करने वाला “pre-jit” approach प्रस्तावित हुआ था, लेकिन व्यापक रूप से इस्तेमाल नहीं होता
  • Wasm module और host का basic interface memory है, इसलिए data movement में copying की जरूरत पड़ सकती है
    • memory chunks share करना संभव है, लेकिन runtime के memory model के अनुसार इसकी संभावना या recommendation बदलती है
    • अधिकांश runtimes में module और I/O operation के बीच zero-copy communication कठिन माना जाता है
    • streaming data को Wasm module के अंदर-बाहर ले जाना host में handle करने की तुलना में धीमा हो सकता है
  • Wasm VM usage control के मामले में बहुत high control देता है
    • कुछ runtimes Wasmtime fuel concept की तरह CPU instructions की संख्या गिनकर CPU limits enforce कर सकते हैं
    • VM memory और wall clock time को limit कर सकता है
  • Interface Types और module linking module size घटा सकते हैं और I/O speed व usability सुधार सकते हैं
    • Interface Types इस्तेमाल किए जा सकते हैं, लेकिन अभी ratified standard नहीं हैं
    • module linking के working prototypes हैं, लेकिन standard approach अभी नहीं है
    • Wizer फिलहाल module linking से conflict कर सकता है, और इसे हल करने के custom approaches हैं, लेकिन कोई स्पष्ट winner नहीं है
    • Interface Types का direction यह है कि language-neutral objects महंगी encoding/decoding के बिना Wasm memory boundary पार कर सकें
    • अभी आम तरीका JSON को memory में copy करके अंदर-बाहर ले जाना है
  • Wasm modules मूल रूप से केवल दिए गए resources तक access कर सकते हैं, इसलिए security model छोटा और स्पष्ट है
    • untrusted Wasm code चलाना आम तौर पर काफी safe है
    • VM का attack surface Docker या अन्य isolation models से छोटा है
    • host hardware पर translated instructions चलने के कारण timing attacks संभव हैं, लेकिन mitigations मौजूद हैं
    • Wasm को native binary में भी compile किया जा सकता है, लेकिन attack surface बढ़ जाता है

edge functions और Wasm-based function execution

  • Wasm execution environments और development tools व्यापक रूप से इस्तेमाल होने लगें, तो scripting languages पर भी Wasm runtime और Wizer जैसी preboot approach अपनाने का दबाव आ सकता है
  • सिद्धांत रूप में, application हर request पर snapshotted copy से resume होकर मौजूदा अन्य models की तुलना में तेज चल सकता है
  • local CLI को Ruby में लिखकर snapshotted Wasm module के रूप में deploy किया जाए और Wasm Ruby runtime से link किया जाए, तो C++ utility जैसे startup times मिल सकते हैं और उसे project directory के भीतर ही काम करने तक सीमित किया जा सकता है
  • पहला बड़ा बदलाव functions को user के करीब edge पर ले जाना है
    • compute database के पास नहीं, बल्कि user के पास perform होता है
    • Vercel Edge Functions V8-based हैं, लेकिन समान principles share करने वाले उदाहरण के रूप में पेश किए गए हैं
    • next-auth JWT login token के आधार पर pre-rendered pages तक access control कर सकता है
    • CDN में cached data से बने dynamic personalized content serve किए जा सकते हैं
  • दूसरा बदलाव serverless applications में process-based functions को Wasm-based functions से replace करना है
    • Suborbital Wasm-based function execution environment सीधे बनाने देता है, और Wasm functions को workflow में chain करने का तरीका भी देता है
    • कई execution platforms request per single module की recommendation करते हैं और memory sharing या कई modules की fast invocation की संभावनाओं का पर्याप्त उपयोग नहीं करते, ऐसा माना जाता है
    • Interface Types standardize होने पर Rack जैसा middleware data model उभर सकता है
  • Wasm Lambda function के अंदर भी चल सकता है
    • मौजूदा infrastructure में snapshotted application version इस्तेमाल किया जा सकता है
    • यह combination दिलचस्प है, लेकिन अंततः गायब हो सकने वाला तकनीकी मिश्रण माना जाता है

अगले web application model की दिशा

  • Wasm को ऐसी technology के रूप में पेश किया गया है जो performance बढ़ा सकती है, process-level security को आसान बना सकती है, और serverless functions की build व execution cost घटा सकती है
  • यह लगभग किसी भी language को चला सकता है, और module linking व Interface Types के जरिए functions के बीच latency को काफी घटा सकता है
  • system की constraints बदलें तो वे काम संभव हो जाते हैं जो पहले संभव नहीं थे—Wasm को नया CGI मानने का मुख्य आधार यही है

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

1 टिप्पणियां

 
GN⁺ 2024-10-11
Hacker News की राय

  • मुझे ठीक से समझ नहीं आता कि WASM, Java Applet, ActiveX, Silverlight, Macromedia Flash जैसी पुरानी तकनीकों से अलग कैसे है
    ब्राउज़र में अविश्वसनीय third-party compiled code चलाने से हम पहले ही सबक सीख चुके हैं, ऐसा लगता था, और यह ग्राहक अनुभव सुधारने के नाम पर server की compute cost को client पर डालने जैसी संरचना लगती है

    • Java और Flash “कुछ भी सुरक्षित रूप से चला सकने वाले अटूट sandbox” का वादा निभा नहीं पाए
      implementations में बहुत vulnerabilities थीं और आखिरकार वे ब्राउज़र में practically इस्तेमाल लायक नहीं रहे, और लगता है बाकी तकनीकों ने तो शुरू से ऐसा वादा भी नहीं किया था
      JavaScript ने यह वादा सच में निभाया, और आज के ब्राउज़र किसी भी domain से डाउनलोड की गई JavaScript को user से trust पूछे बिना चलाते हैं
      WASM, JavaScript engine के ऊपर चलता है और मिलती-जुलती security guarantees देता है, इसलिए JVM bytecode से इसका मूलभूत फर्क नहीं है; असली फर्क यह है कि WASM ने अपनी safety साबित की, JVM ऐसा नहीं कर पाया
      अब Google Chrome इतना सुरक्षित है कि अरबों लोग malicious WASM चलाएँ तब भी उनके phones compromise न हों, और इस engine को server पर लाकर कई users के scripts को मजबूत sandbox में चलाते हुए resources share कराए जा सकते हैं
      विकल्प virtualization है: code को WASM के ढेर में compile करके बड़े WASM server पर चलाया जा सकता है, या amd64 binary और कटा-छँटा Linux kernel बाँधकर VM में चलाया जा सकता है
      अभी साफ तौर पर किसी एक को विजेता कहना मुश्किल है और हर approach के अपने फायदे-नुकसान हैं
    • ActiveX, Silverlight, Flash के विपरीत WASM कई industry participants द्वारा बनाया जा रहा open standard है और इसकी कई implementations भी हैं, इसलिए केवल यही बात इसे विकल्पों से काफी बेहतर बनाती है
      JVM के विपरीत WASM linear memory देता है और default रूप से garbage collection नहीं होता, इसलिए C/C++ को Emscripten से compile करने या Rust को target करने जैसी स्थिति में यह languages की व्यापक range के लिए compile target बनने के लिए अच्छा है
      WASM bytecode है, और मेरा मानना है कि अधिकतर implementations host JavaScript engine और runtime के साथ बहुत कुछ share करती हैं
      client और server के बीच compute cost का इधर-उधर होना industry में लंबे समय से thick clients और thin clients के बीच चलती आ रही आवाजाही का हिस्सा है, और यह pendulum आगे भी चलता रहेगा
    • Wasm के पुराने technologies की तुलना में बड़े फायदे हैं
      Wasm bytecode को जिस validation specification का पालन करना होता है, वह मौजूद है, और इस validated subset की वजह से पुरानी technologies में दिखने वाली कई security vulnerabilities शुरुआत से ही असंभव हो जाती हैं
      Heartbleed या Rowhammer जैसे hardware malfunction पर निर्भर attacks संभव हो सकते हैं, लेकिन उदाहरण के लिए VM को धोखा देकर किसी number को pointer की तरह interpret कराना और अपनी Wasm memory के बाहर reference करना संभव नहीं है
      Wasm bytecode को machine code में बदलना काफी सरल है, इसलिए VM इस्तेमाल करने की तुलना में implementation छोटी और तेज हो सकती है
      यह किसी खास company की property नहीं है, बल्कि सबके इस्तेमाल के लिए अच्छी तरह लिखी public specification है, और web standard के रूप में अपनाई गई है, इसलिए browser extension की जरूरत नहीं
      client-side computation तो JavaScript में भी पहले से होती है, और Wasm code JavaScript से असंभव तरीकों में efficient हो सकता है, इसलिए यह बात और भी लागू होती है
    • Java Applet और ActiveX में नीचे के operating system तक access कम mediated था
      Applet में कुछ हद तक, ActiveX में लगभग बिल्कुल भी mediation नहीं थी, और WASM का “बाहरी platform” मोटे तौर पर JavaScript runtime है, जबकि Applet का बाहरी platform execve(2) के करीब है
    • यह लेख server-side WASM पर है, इसलिए server की compute cost client पर डालने वाली बात इससे अलग है
      WASM ऐसा कर सकता है, लेकिन हमेशा ऐसा नहीं होता, और बेहतर sandboxing व isolation जैसे फर्कों को दूसरे जवाबों ने पहले ही अच्छी तरह कवर किया है

  • “Amazon ने Lambda के साथ serverless computing का दौर शुरू किया” कहना ठीक नहीं, क्योंकि Google App Engine 2008 में आया था और Lambda से 6 साल पहले था

    • Heroku और उसी दौर के PaaS भी थे
      ऐसे products पहले से कई सालों से मौजूद थे और उनका नाम भी था, फिर “serverless” नाम क्यों पड़ा और कहाँ से आया, मुझे ठीक से समझ नहीं आता
      App Engine में भी batch workers और web workers थे, और Heroku में भी यही था
      दोनों Docker से पहले के products थे, इसलिए शायद लोगों को वे अलग लगते हों, लेकिन मुझे नहीं लगता कि Lambda भी शुरुआत से Docker पर launch हुआ था

  • “सुरक्षा कारणों से dynamic Wasm code generation की अनुमति नहीं है, इसलिए JIT compilation संभव नहीं है” — यह बात सही नहीं लगती
    साफ-सुथरे code hot reloading जैसे कामों की अनुमति देनी हो तो यह लगभग मूलभूत capability है
    मुझे security वाली दलील कमजोर लगती है
    JS रनटाइम के दौरान hot reload या उससे भी ज्यादा आक्रामक code generation, security तोड़े बिना कर सकता है, और Wasm runtime को पूरा dynamic तरीके से फिर से load करते हुए memory बचाए रखी जाए तो code generation या hot reload की नकल भी की जा सकती है, लेकिन user experience भद्दा हो जाएगा
    तकनीकी रूप से यह असंभव क्यों होना चाहिए, इसकी कोई वजह नहीं दिखती; और अगर यह security measure है, तो इसे बहुत आसानी से bypass किया जा सकने वाला लगता है
    WASM bytecode conceptually .NET IL या Java bytecode जैसे JIT compilation को ध्यान में रखकर बने formats से बहुत मिलता-जुलता है
    मुझे WASM ज्यादा पसंद नहीं, क्योंकि यह strong direction और सही समय पर सफल बनाने की इच्छा से रहित project जैसा लगता है
    नाम “web के लिए assembly”, यानी virtual CPU के लिए machine language का संकेत देता है, लेकिन असल में यह compiler backend के लिए intermediate representation है; और garbage collection support जैसे high-level features भी planned हैं, इसलिए concept अस्पष्ट है
    पहले बताए गए hot reload, hack जैसा न लगने वाला threading, JavaScript के बिना DOM से direct integration, low-overhead graphics/compute API, low-level audio access जैसी basic capabilities भी अभी कम हैं
    बड़े multimedia apps को बड़े compromises के बिना चलाना मुश्किल है

    • वह वाक्य सही है
      Wasm memory को executable के रूप में mark नहीं कर सकता और व्यवहार में code और memory अलग-अलग हैं, लगभग Harvard architecture की तरह
      इसके अलावा code की arbitrary location पर jump भी नहीं किया जा सकता, और jump instruction खुद भी नहीं है
      यहां JIT का मतलब runtime में native code compile करके execute करना है, और browser या Wasm sandbox में यह बड़ी security weakness बन जाता है
      यह design और instruction set में ही embedded है, इसलिए आसानी से bypass होने वाली चीज नहीं है; ज्यादा जानकारी https://webassembly.org/docs/security/ पर मिल सकती है
      Wasm भी इस मायने में .NET IL या Java bytecode जैसा है कि engine JIT संभालता है, लेकिन user को runtime से बाहर निकलकर native code बनाने और वहां jump करने का अधिकार देना खतरनाक है
    • Browser WASM के लिए निश्चित रूप से किसी न किसी रूप में JIT इस्तेमाल करते हैं
      इसलिए JIT की तरह, WASM code पहली बार चलाते समय थोड़ी “warm-up stutter” दिख सकती है, हालांकि पिछले कुछ वर्षों में यह काफी बेहतर हो गया है
      साथ ही, मेरी जानकारी में browser में WASM के chunks को dynamic रूप से बनाया, instantiate किया और चलाया जा सकता है
      दूसरे WASM runtimes में यह संभव है या नहीं, पता नहीं; और browser में भी JavaScript के जरिए जाना पड़ता है, लेकिन किसी भी “web API” तक पहुंचने की कोशिश करें, तो वैसे भी वही चाहिए

  • WASM का मतलब JavaScript VM जैसे किसी खास भाषा के लिए बने VM को, जहां भी JavaScript VM इस्तेमाल होता है वहां चल सकने वाले general-purpose VM में बदलना है
    बेशक यह सिर्फ वहीं तक सीमित नहीं है
    general-purpose का मतलब है कि compiler या interpreter हो तो लगभग कुछ भी चलाया जा सकता है, JavaScript भी शामिल है
    यह आम तौर पर JavaScript engine के हिस्से के रूप में implement होता है, इसलिए sandboxing और संबंधित API access जैसी कई विशेषताएं inherit करता है
    उस access को standardize करने का काम अभी जारी है, लेकिन आखिरकार जो काम अभी केवल JavaScript से संभव हैं वे WASM में भी संभव होंगे, और JavaScript से मुश्किल या असंभव और भी कई काम संभव हो जाएंगे
    यह ज्यादा तेज और smooth भी चल सकता है
    WASM का मूल उद्देश्य JavaScript के लोकप्रिय environments में मौजूद कई restrictions को हटाना है
    JavaScript ऐसी language है जिसे लेकर पसंद-नापसंद बहुत बंटी हुई है, इसलिए यह एकमात्र विकल्प से बदलकर कई विकल्पों में से एक बन जाती है
    WASM को JavaScript replacement, Docker replacement, Java replacement, CGI replacement के रूप में भी बताया गया है; संक्षेप में कहें तो यह ये सब है और इससे भी ज्यादा

    • मुझे JavaScript से खुद कोई शिकायत नहीं, लेकिन web पर JS deploy करने वाला ecosystem समस्या लगता है
      एक जैसे काम करने वाले tools बहुत ज्यादा हैं और उनकी boundaries साफ नहीं हैं
      आखिर में सब कुछ चला भी दें, तब भी मुझे निजी तौर पर यह fragile लगता है, और जो लोग इसे professionally नहीं करते उनके लिए डराने वाला काम है
      आजकल web के लिए कुछ बनाना हो तो मैं leptos इस्तेमाल करता हूं; developer experience कहीं बेहतर है, और यह अभी 1.x भी नहीं है, फिर भी JS bundle को transpile, obfuscate, minify और pack करने के लिए 5 tools जोड़ने की तुलना में ज्यादा stable लगता है

  • यह लेख देखकर मुझे software का वह नियम याद आया जिसका पहले अक्सर जिक्र होता था
    कोई application अगर पर्याप्त बड़ी हो और लंबे समय तक जीवित रहे, तो अंततः वह जिस पूरे software stack पर चलती है, operating system तक को भी फिर से implement कर देती है, और उसे खराब तरीके से reimplement करती है
    स्रोत तो ठीक से नहीं पता, लेकिन अक्सर यह बात काफी सही बैठती है

    • मजेदार version Greenspun का 10वां नियम कहलाता है
      “कोई भी पर्याप्त जटिल C या Fortran program ad hoc तरीके से, informal specification के अनुसार, bugs से भरा और धीमा Common Lisp का आधा हिस्सा implement कर देता है”
      अधिक सामान्य pattern को Inner-Platform Effect कहते हैं

  • शीर्षक के premise को व्यापक करें तो, WASM को उस वंश का सच्चा उत्तराधिकारी बनने के लिए उतना ही आसान होना चाहिए जितना किसी भी hosting provider के LAMP stack पर PHP app डालकर deploy करना था
    अभी यह PHP deployment experience जितना आसान नहीं लगता

    • WASM browser में चलता है
      hosting में आपको क्या बदलने की उम्मीद है, मुझे समझ नहीं आता

  • मैं इसे अलग तरह से देखता/देखती हूँ
    मुझे लगता है भविष्य local-first है
    यानी ऐप server की मदद बहुत कम लेकर ज्यादातर user के browser के अंदर ही चलते हैं
    Figma, Linear, Superhuman जैसे ऐप इस मॉडल का बहुत सफल इस्तेमाल कर रहे हैं और Stackblitz भी कुछ हद तक ऐसा ही है
    अगर Figma जितना जटिल ऐप user के browser के अंदर लगभग पूरी तरह चल सकता है, तो मेरे हिसाब से ज्यादातर ऐप भी चल सकते हैं
    server-side की भूमिका मुख्यतः तब अलग-अलग instances के बीच data sync करने की होती है, जब user कई locations से ऐप इस्तेमाल करता है
    Electric-SQL जैसे tools बन रहे हैं, लेकिन अभी mature नहीं हुए हैं; जब ऐसी libraries mature होंगी, तो यह क्षेत्र बहुत तेजी से बढ़ेगा
    serverless आम तौर पर Amazon और Azure जैसी कंपनियों के पैसे कमाने के लिए है और आखिरकार CGI जैसा हो जाएगा
    WASM भी सफल हो सकता है, लेकिन इसकी संभावना ज्यादा है कि वह मुख्य रूप से user के browser के अंदर होगा
    Microsoft C#/Blazor में WASM इस्तेमाल कर रहा है, लेकिन मुझे नहीं लगता कि browser के अंदर dotnet JavaScript जितना तेज हो पाएगा, इसलिए मेरे हिसाब से यह सही approach नहीं है

    • CGI ने users और छोटी sites को ताकत दी
      बस कोई इसके बारे में बात नहीं करता क्योंकि यह प्रति सेकंड 1 trillion ad impressions तक scale नहीं कर सकता
      serverless function जब भी कोई लिखता है, Bezos की yacht में 10 feet और जुड़ जाते हैं
    • Figma को local-first कहना थोड़ा मुश्किल है
      अगर आप offline हैं या Wi‑Fi unstable है, तो design load नहीं कर सकते, और अगर हाल में कुछ बदला नहीं है तो edit करने के बाद Wi‑Fi कट जाने पर browser बंद कर दें तो वह save नहीं होता
    • यानी बात यह है कि भविष्य उसी तरीके पर लौटना है जिससे web युग से पहले apps चलाए जाते थे
    • मैं client-side applications के विकास का समर्थन करता/करती हूँ, लेकिन यह जरूरी नहीं मानता/मानती कि वे browser या sandbox के अंदर ही चलें, या app store के जरिए ही खरीदी जाएँ
      और यह कोई बिल्कुल नया विचार भी नहीं है
    • browser के अंदर dotnet शायद JavaScript जितना तेज न हो, लेकिन दोनों ही पर्याप्त तेज होंगे
      हम Blazor WASM develop कर रहे हैं, और performance के लिहाज से dotnet कोई समस्या नहीं है

  • क्या मूल रूप से JVM और उसके ecosystem को फिर से बनाया जा रहा है?

    • कुछ हद तक हाँ, लेकिन WASM उन अलग constraints को ध्यान में रखकर design किया गया है, जो तब ज्यादा सही बैठती हैं जब आप runtime को कहीं भी डालना चाहते हैं
      अतीत की सीखों को शामिल करके X को फिर से बनाना कई बार सच में बहुत अच्छा idea होता है
    • कुछ मायनों में हाँ, लेकिन WASM बहुत ज्यादा languages को support करता है
      उदाहरण के लिए, जब 2010 के आसपास मैंने browser में C/C++ code चलाने के बारे में देखना शुरू किया, तब C/C++ को JVM में compile करना व्यावहारिक रूप से असंभव था
      उस समय Java Applet अभी भी मायने रखता था, इसलिए अगर यह संभव होता तो अच्छा होता, लेकिन WASM भी अभी नहीं था और Emscripten था, जिसने asm.js के रास्ते आखिरकार WASM के जन्म तक पहुँचाया
    • JVM शानदार है, लेकिन इसका मतलब यह नहीं कि यह इस category का अंतिम जवाब है
      2000s में programming language class में class loaders से छेड़छाड़ करने और JVM assembly खुद लिखने के अनुभव के बाद भी मुझे पक्का नहीं कि JVM इस क्षेत्र की peak है
      यह सही है कि उसने एक बड़े ecosystem को संभव बनाया, लेकिन बाहरी दुनिया से JVM का interface सचमुच भद्दा और उलझा हुआ है
      20 साल से ज्यादा समय से जब भी JVM से जुड़ी कोई चीज सामने आई है, मेरे मुँह से कराह निकली है
      Rust की packaging और ecosystem की तुलना Python से, या इससे भी बदतर C++ से करें, तो दिखता है कि पिछले दशकों की सीखों को शामिल करके reinvent करना बहुत अच्छा हो सकता है
    • हालांकि WASM में बड़ा class loader/linker problem है
      दो wasm files को एक में मिलाना और memory merging को सही तरीके से align करना अभी भी बहुत मुश्किल है
      component model शायद इसे ठीक कर सके, लेकिन इसमें बेवजह भारी elements बहुत ज्यादा हैं, इसलिए Safari adoption तक काफी समय लग सकता है
    • सही, और .Net CLR आदि के साथ भी यही बात है

  • मैं काफी समय से सोचता/सोचती आया/आई हूँ कि WASM ऐसी दुनिया की ओर जाएगा जहाँ वह cloud के Lambda function code की जगह लेगा
    WASM को पारंपरिक रूप से host platform के ऊपर चलने वाली चीज माना जाता है, लेकिन ऐसा होना जरूरी नहीं है
    WASM के sandbox nature की वजह से, तकनीकी रूप से इसे operating system के बाहर या ring0 में चलाकर operating system overhead का बड़ा हिस्सा bypass किया जा सकता है
    WASM में compile करने से user के नजरिए से कई deployment problems काफी सरल हो जाती हैं, और hosting environment के पास optimization की ज्यादा गुंजाइश होती है
    WASM को और तेज चलाने के लिए custom hardware भी संभव हो सकता है

  • किसी भी arbitrary untrusted source से आए arbitrary untrusted code को auto-run करना खराब है, और इसे server-side CGI जैसी भूमिका भरने वाला भी नहीं माना जा सकता