JavaScript Containers पर Ryan Dahl के विचार
(tinyclouds.org)- Docker ने Linux containers को लोकप्रिय बनाया: OS-स्तर की virtualization के ज़रिए software deployment को आसान किया
- Cloudflare Workers और Deno Deploy ने JS Container की अवधारणा को लागू किया है (अलग-अलग environments में)
- आने वाले कुछ वर्षों में JS containers किस दिशा में आगे बढ़ेंगे?
Universal Scripting Language
- वेब के आधार पर जुड़ने वाली चीज़ें लगातार बढ़ रही हैं: The web is eating the world
- वेब मानव जानकारी का बुनियादी माध्यम है, और JS वेब infrastructure में गहराई से जुड़ा हुआ है, इसलिए यह दूसरी भाषाओं से अलग है
- scripting languages सर्वर-साइड की कई समस्याएँ हल करती हैं, और business logic को अधिक तेज़ी और कम लागत में लिखना संभव बनाती हैं
- scripting languages उपयोगी हैं, एक-दूसरे से काफी मिलती-जुलती हैं, और JavaScript सबसे व्यापक रूप से इस्तेमाल की जा रही है तथा भविष्य में भी इस्तेमाल की जा सकती है
- यानी JavaScript को universal scripting language माना जा सकता है
Shell : Executables :: JavaScript : WebAssembly
-
सर्वर के लिए एक नया high-level container, JavaScript Sandbox, उभर रहा है
-
यह Linux containers जिन समस्याओं को target करते हैं, उन्हें हल करने के लिए नहीं है
-
यह सरलीकरण के परिणामस्वरूप उभरा है
→ web service business logic के boilerplate को न्यूनतम करना
→ browser के साथ अवधारणाएँ साझा करना, और programmer को जानने वाली अवधारणाओं को न्यूनतम रखना -
सभी web engineers पहले से JavaScript browser APIs जानते हैं
→ JS container abstraction भी उन्हीं browser APIs पर आधारित होने के कारण सीखने वाली बातें कम हो जाती हैं
→ JS की universality जटिलता को कम करती है -
Shell, Unix programs चलाने के लिए एक interpreting scripting language है
→ इसमें conditionals, loops और variables होते हैं, लेकिन यह सीमित है, इसलिए इसमें programming करना कठिन है। वास्तविक कार्य executables करते हैं -
इस नई server abstraction layer में JS, Shell की जगह लेता है
→ यह Bash/Zsh की तुलना में scripting के लिए अधिक उपयुक्त है, लेकिन जैसे Shell executables को call करता है, वैसे ही JS Sandbox WASM को call करता है
→ अगर image resizing जैसे जटिल काम की ज़रूरत हो, तो उसे JS में लिखने की बजाय WASM का उपयोग करना बेहतर है
→ जैसे bash में image resizing नहीं करते, बल्कि Imagemagick को call करते हैं
The North Star
- scripts का भविष्य browser JavaScript है
- Node.js की सबसे बुनियादी गलती यह थी कि नए APIs के standardize होने के दौरान उसने browser से बहुत दूर जाकर बहुत सी चीज़ें खुद बना डालीं
→ 2010 में हमारे पास ES modules भी नहीं थे, लेकिन standardize होने के बाद उन्हें Node में लाना पड़ा
→ Promise, Async/Await, Fetch, Streams आदि कई चीज़ों के साथ ऐसा हुआ
→ non-standard CommonJSrequire,package.json,node_modules,npm, globalprocessobject आखिरकार या तो standardize होकर browser में जोड़े जाएँगे, या वेब-आधारित किसी दूसरे विकल्प से बदले जाएँगे - high-level containers अभी standardize नहीं हुए हैं, और यह सब कैसे आगे बढ़ेगा, इसके बारे में अभी स्पष्ट नहीं है
- फिलहाल Cloudflare Workers और Deno Deploy, FetchEvent API का उपयोग करते हैं, लेकिन संभव है कि इससे बेहतर interface मिले
निष्कर्ष
- JavaScript एक general-purpose scripting language है
- JavaScript की universality की वजह से सर्वर को सरल बनाने वाले container-जैसे नए abstractions उभर रहे हैं
- इसका मतलब यह नहीं कि Linux containers गायब हो जाएँगे। उस स्तर का abstraction आगे भी उपयोगी रहेगा
→ लोगों द्वारा लिखे जाने वाले बहुत से "business logic" के लिए यह कुछ हद तक low-level abstraction है
→ website बनाते समयsystemdconfiguration जैसी चीज़ें boilerplate होती हैं - संभव है कि कई "web services" को Linux containers की बजाय JavaScript containers के नज़रिए से सोचने पर सरल बनाया जा सके
- हम Deno में इस विचार को explore कर रहे हैं
→ server abstraction को बुनियादी रूप से सरल बनाने की कोशिश कर रहे हैं
2 टिप्पणियां
अनुवादित लेख आ गया है
https://medium.com/@yujso66/…
मेरी समझ से इसका सार कुछ इस तरह है
शायद इसे ऐसे समेटा जा सकता है।
समझने में मदद के लिए कुछ और लिंक