- हाल में Node.js टूल्स को Rust, Zig, Go जैसी ज़्यादा तेज़ भाषाओं में फिर से लिखने की प्रवृत्ति चिंताजनक लगती है, और इस बारे में कुछ वस्तुनिष्ठ चिंताएँ व्यवस्थित की गई हैं
[प्रदर्शन]
- ऐसा माना गया है कि JavaScript टूल्स की गति बढ़ाने की संभावनाएँ अभी पूरी तरह खोजी नहीं गई हैं
- ESLint, Tailwind आदि में आसानी से सुधारे जा सकने वाले कई हिस्से मौजूद हैं
- ब्राउज़र में JavaScript अधिकांश वर्कलोड के लिए "काफ़ी तेज़" है
- तो फिर CLI टूल्स में JavaScript को छोड़ने की कोशिश क्यों की जा रही है?
बड़े पैमाने पर री-राइट
- लंबे समय तक JavaScript टूल इकोसिस्टम का फोकस "जो काम करे" उस पर रहा है
- अब API अधिकतर स्थिर हो चुके हैं, इसलिए हर कोई "वही चीज़, लेकिन ज़्यादा तेज़" चाहता है
- प्रदर्शन को ध्यान में रखकर नए सिरे से लिखा जाता है, और API पहले से तय होने के कारण डेवलपमेंट समय भी बचता है, इसलिए नए टूल तेज़ हो सकते हैं
- A से B में री-राइट करने पर गति बढ़ती है, इसलिए यह दावा करना आसान हो जाता है कि B, A से तेज़ है
- लेकिन संभव है कि तेज़ होने की वजह खुद री-राइट ही हो (क्योंकि दूसरी बार ज़्यादा जानकारी होती है और प्रदर्शन पर अधिक ध्यान दिया जाता है)
बाइटकोड और JIT
- ब्राउज़र में यह सामान्य बात है, लेकिन वहाँ बाइटकोड कैश और JIT (Just-In-Time compiler) का लाभ मिलता है
- अगर JavaScript सही तरह कैश हो जाए, तो ब्राउज़र को source code को बाइटकोड में parse और compile करने की ज़रूरत नहीं पड़ती
- जो functions बार-बार चलती हैं, वे मशीन कोड में और अधिक optimize हो जाती हैं (JIT)
- Node.js scripts में बाइटकोड कैश का लाभ बिल्कुल नहीं मिल पाता था
- लेकिन अब Node में भी compile cache का उपयोग किया जा सकता है (
NODE_COMPILE_CACHE environment variable सेट करके)
- JIT को किसी function के कई बार चलने पर ही "गरम" होने का मौका मिलता है, इसलिए one-off scripts में इसका लाभ मिलना कठिन है
- Pinafore में JavaScript-आधारित blurhash library को Rust(Wasm) version से बदलने की कोशिश की गई, लेकिन 5वीं iteration तक पहुँचते-पहुँचते प्रदर्शन का अंतर गायब हो गया
- Porffor जैसे टूल्स से Node scripts को AOT compile करने पर विचार किया जा सकता है
- Wasm उपयोग करने पर pure native tools की तुलना में प्रदर्शन में गिरावट आती है
[योगदान और डिबगिंग की आसानी]
- "हर चीज़ को native में फिर से लिखने" वाले आंदोलन को लेकर यही मुख्य संदेह है
- JavaScript अपने उदार types, आसान सीखने की प्रक्रिया और ब्राउज़र सपोर्ट के कारण लोकप्रिय भाषा है
- लंबे समय तक JavaScript इकोसिस्टम में library authors और users, दोनों ही JavaScript का उपयोग करते रहे हैं
- इससे योगदान की बाधा कम करने में मदद मिलती है
- लेकिन जब JavaScript library authors दूसरी भाषाओं का उपयोग करने लगते हैं, तो यह लाभ टूट जाता है
- साथ ही, JavaScript dependency को लोकल में संशोधित करना सरल होता है (सीधे node_modules में बदलाव करके)
- इसके विपरीत, native language में लिखे जाने पर source code को अलग से checkout और compile करना पड़ता है
- JavaScript library को debug करते समय परिचित browser developer tools या Node.js debugger का उपयोग किया जा सकता है
- Wasm में भी debugging असंभव नहीं है, लेकिन उसके लिए अलग skill set चाहिए
[निष्कर्ष]
- JavaScript इकोसिस्टम के लिए नई पीढ़ी के टूल्स आना अच्छी बात है
- मौजूदा टूल्स बहुत धीमे हैं और प्रतिस्पर्धा से उन्हें लाभ मिलने की संभावना है
- लेकिन ऐसा नहीं माना जाता कि JavaScript अपने स्वभाव से ही धीमा है या उसमें सुधार की कोई गुंजाइश नहीं है
- Chromium developer tools में हालिया सुधारों को देखकर लगता है कि अभी बहुत रास्ता बाकी है
- यह चिंता है कि दुनिया कहीं सिर्फ Rust और Zig डेवलपर्स की चीज़ बनकर न रह जाए
- औसत JavaScript डेवलपर build tools के bug का सामना करते समय खुद को असहाय महसूस कर सकता है
- इससे युवा web developers को सीखी हुई लाचारी सिखाई जा सकती है
- यह एक अनजाना रास्ता है, और इसके अनचाहे परिणाम हो सकते हैं
- दूसरी ओर, एक कम जोखिम वाला रास्ता भी है जिससे लगभग वही नतीजे मिल सकते हैं
- लेकिन मौजूदा प्रवाह के धीमा पड़ने के कोई संकेत नहीं दिखते
GN⁺ की राय
- Rust या Zig आदि में री-राइट करना हमेशा सबसे अच्छा विकल्प नहीं हो सकता। compile cache जैसी चीज़ों के ज़रिए JavaScript में सुधार की और गुंजाइश दिखती है
- नए डेवलपर्स को segfault जैसी जटिल समस्याओं के सामने खड़ा करना क्या वाकई अच्छा है, इस पर संदेह है। इससे शायद उन्हें सिर्फ असहायता ही सीखने को मिले
- JavaScript में लंबे समय से बने इकोसिस्टम के फ़ायदे (libraries के बीच स्वतंत्र संशोधन, परिचित debugging environment आदि) त्यागकर सिर्फ गति बढ़ाना सही दिशा है या नहीं, इस पर सोचना चाहिए
- मौजूदा JavaScript libraries को बेहतर बनाने की कोशिशें भी जारी रहनी चाहिए। अभी JavaScript की संभावनाएँ पूरी तरह खोजी नहीं गई हैं
- भले ही यह रुझान अब रोका न जा सके, फिर भी इस दिशा पर कम्युनिटी स्तर पर गंभीर चर्चा और विचार की ज़रूरत दिखती है
15 टिप्पणियां
छोटे दुकानदार और बड़े स्टोर के काम करने के तरीके कुछ अलग हो सकते हैं। मुझे लगता है कि बदलाव की प्रक्रिया पर आलोचनात्मक रुख अपनाने से ज़्यादा, इस तरह की प्रवृत्ति के अर्थ पर विचार करना ज़्यादा स्वस्थ सोच है.
यह पसंद या ट्रेंड के हिसाब से किया गया बदलाव लग सकता है, लेकिन कंपनियाँ आम तौर पर ऐसे फ़ैसले इस तरह नहीं लेतीं, है न?
क्या Python या JavaScript खुद धीमे हैं? इस पर भले ही ऐसा न कहा जा सके
लेकिन क्या अक्सर इस्तेमाल होने वाले Python या JavaScript से बने टूल धीमे हैं? मेरा मानना है कि इसका जवाब Yes है.
मैं कई low-power डिवाइस इस्तेमाल कर रहा हूँ, और सच में बहुत से टूल बेहद झुंझलाहट पैदा करने जितने धीमे हैं..
Python कम्युनिटी में भी लगभग इसी तरह की बातें बार-बार दोहराई जा रही हैं.
JavaScript, JavaScript में नहीं लिखा गया है, लेकिन ज़्यादातर JavaScript डेवलपर इस बात की परवाह नहीं करते. "शुरुआती डेवलपर" और "युवा web डेवलपर" के लिए यह कोई समस्या नहीं है कि JavaScript, JavaScript में नहीं लिखा गया, लेकिन JavaScript डेवलपमेंट टूल्स का JavaScript में नहीं लिखा होना समस्या है — यह बात कुछ खास तार्किक नहीं लगती. बल्कि इस तरह की बातों की परवाह करने वाले डेवलपर दोनों समूहों में बहुत ही कम संख्या में हैं.
भले ही इस बात से इनकार न किया जाए कि पर्याप्त optimization के बाद लगभग समान गति हासिल की जा सकती है, क्या सचमुच उसके लिए इतना करना सार्थक है?
यह बस उस दौर से बदलाव है जब डेवलपमेंट टूल्स को C++ की बजाय JavaScript में लिखना ज़्यादा किफायती हो गया था, और अब उस दौर में प्रवेश हो रहा है जहाँ JavaScript में लिखने से Rust में लिखना ज़्यादा किफायती है.
प्रवाह को पलटने का तरीका यह नहीं है कि ज़्यादा लागत लगाकर JavaScript optimization आंदोलन चलाया जाए, बल्कि यह है कि कम डेवलपमेंट लागत में भी कुशल JavaScript टूल्स बनाए जा सकें. (यह बात सुनने में मिलती-जुलती लग सकती है, लेकिन फ़र्क इस बात में है कि प्रयास कहाँ लगाया जाता है)
मैं सहमत हूँ। मेरा मानना है कि आर्थिकता को टूल उपयोगकर्ताओं के केंद्र में रखकर फिर से परिभाषित किया जाना चाहिए।
अब तक लगता है कि आर्थिकता एक ऐसा मापदंड रहा है जो टूल उपयोगकर्ताओं की बजाय टूल डेवलपर्स को ध्यान में रखकर बनाया गया था। जिन अक्षमताओं और performance समस्याओं का सामना टूल उपयोगकर्ताओं को करना पड़ता है, ऐसा महसूस होता है कि वे प्राथमिकता सूची में अपेक्षाकृत पीछे धकेल दी गई थीं। व्यक्तिगत रूप से मैं uv और vite का अच्छी तरह उपयोग कर रहा हूँ, और यदि संभव हो तो pip या create-react-app जैसे टूल्स से बचना चाहूँगा।
मेरे लिए इससे सहमत होना मुश्किल है, क्योंकि मेरा मानना है कि CLI tools को runtime के बिना चलने में सक्षम होना चाहिए।
अगर कोई कहे कि standalone WASM executable बनाया जा सकता है, तो जैसा कि मूल लेख में भी कहा गया है, performance में गिरावट होगी।
जैसे Java में CLI लिखना आम बात नहीं है, वैसे ही मेरा मानना है कि JavaScript के साथ भी यही बात लागू होती है।
लेखक को शायद यह गलतफ़हमी है कि क्योंकि SPA और JavaScript टूल डेवलपमेंट, दोनों में JavaScript इस्तेमाल होता है, इसलिए इनके लिए ज़रूरी बाकी क्षमताएँ भी एक जैसी होंगी। मेरा मानना है कि JavaScript टूल्स के लिए systems programming और compiler क्षेत्र की विशेषज्ञता चाहिए।
> लंबे समय तक JavaScript ecosystem में library लेखक और उपयोगकर्ता, दोनों JavaScript का इस्तेमाल करते रहे हैं
> इससे योगदान की बाधा कम करने में मदद मिली
> लेकिन अगर JavaScript library लेखक किसी दूसरी भाषा का इस्तेमाल करते हैं, तो यह बात टूट जाती है
भले ही भाषा एक ही हो, execution environment browser और NodeJS में अलग है, और शायद केवल वही लोग JavaScript टूल्स में योगदान दे सकते हैं जो इस अंतर को पार कर सकें। execution environment अलग है, इसलिए क्या इसे अलग ecosystem नहीं माना जाना चाहिए?
> जब औसत JavaScript developer को build tool में bug मिलता है, तो वह खुद को असहाय महसूस कर सकता है
> इससे युवा web developers को सीखी हुई लाचारी सिखाई जा सकती है
मुझे लगता है कि यह भी उसी तरह SPA डेवलपमेंट और JavaScript टूल डेवलपमेंट के बीच की सीमा पार कर सकने वाले लोगों की संख्या को बढ़ा-चढ़ाकर आँकने वाली बात है। frontend developers से systems programming के बराबर का ज्ञान माँगना अव्यावहारिक है। टूल उपयोगकर्ता ज़्यादा से ज़्यादा सतही error message या दिखने वाले लक्षण ही समझ सकते हैं, है न? मुझे नहीं लगता कि यह सिर्फ भाषा जान लेने से हल हो जाने वाली समस्या है।
लगता है कि यहाँ tools और libraries को मिलाकर बात की जा रही है। libraries के मामले में मैं कुछ हद तक सहमत हो सकता हूँ, लेकिन tools के बारे में, पता नहीं..
दूसरी भाषाओं के डेवलपर्स भी tools को native में लिखा हुआ देखने के आदी होंगे।
मेरी व्यक्तिगत राय में, चाहे वह कोई tool हो या library, अगर वह JavaScript में लिखी गई है तो JavaScript से परिचित डेवलपर उसे debug कर सकते हैं और ज़रूरत पड़ने पर उसमें योगदान भी दे सकते हैं। लेकिन अगर उसे Rust में फिर से लिखा जाए, तो open source योगदान करना लगभग केवल Rust डेवलपर्स तक सीमित हो जाता है। JavaScript डेवलपर्स का दायरा Rust की तुलना में बहुत बड़ा है, इसलिए open source ecosystem में चाहे tool हो या library, उसका JavaScript में लिखा होना अधिक फ़ायदेमंद हो सकता है।
मेरा मानना है कि JavaScript का execution environment browser और NodeJS के बीच बिखरा हुआ है, इसलिए language users की संख्या की सीधी तुलना अपने-आप में एक तर्क के रूप में सीमित है। backend Spring developers और JDK developers, React/Angular/Vue developers और JavaScript tool developers की रुचियाँ और स्थितियाँ अलग हैं, और उनका संबंध consumer और producer जैसा है
अगर लक्ष्य JavaScript tools की performance और usability में सुधार करना है, तो उस लक्ष्य के लिए implementation language बदलना भी व्यक्तिगत रूप से मुझे एक संभव विकल्प लगता है
मुझे लगता है कि डेवलपमेंट टूल्स के उपभोक्ताओं और निर्माताओं के बीच साफ़-साफ़ अंतर करना मुश्किल है। जैसे-जैसे कोई कंपनी बड़ी होती है, वह अक्सर अपनी मनचाही नीतियों के अनुसार toolchain को customize करती है या अतिरिक्त plugins को customize या implement करती है; ऐसे मामलों में, वही भाषा इस्तेमाल करना अपने-आप में एक बड़ा फ़ायदा होता है.
कई बार टूल के उपयोगकर्ता खुद टूल के improvements या implementation में रुचि लेते हैं और स्वाभाविक रूप से उसमें योगदान भी करने लगते हैं.
मेरा मानना है कि जो लोग toolchain customization में रुचि लेते हैं या वह काम करते हैं, वे केवल consumer की भूमिका से आगे बढ़कर prosumer या producer की भूमिका निभा रहे होते हैं। plugins के मामले में भी, मेरा मानना है कि वे producer और consumer के बीच मौजूद plugin contract के भीतर काम करते हैं। उस स्थिति में, एक ही language का उपयोग करना अलग configuration file format या extension point देने की तुलना में तकनीकी रूप से भी और communication cost के लिहाज़ से भी मददगार होता है, इस बात से मैं भी सहमत हूँ
हालाँकि, मुझे नहीं लगता कि JavaScript tools की performance समस्या या NodeJS की JIT latency उपभोक्ता के decision-making के दायरे में आती है। क्योंकि ऐसी architecture और behavior spec बनाने वाले पक्ष tool producers और runtime developers होते हैं।
JavaScript ecosystem बड़ा होने का यह मतलब नहीं है कि compiler/transpiler codebase में योगदान दे सकने वाले डेवलपर्स भी ज़्यादा होंगे—इस पर मुझे संदेह है। मेरा मानना है कि library framework और foundational tools पूरी तरह अलग क्षेत्र हैं।
लेकिन ऐसा हो सकता है कि दोबारा लिखना ही उसके तेज़ होने की वजह हो -> पीछे मुड़कर देखें तो यह बात वाकई सही लगती है...
यह व्यक्ति बहुत चयनात्मक है, इसलिए उनकी बात से मुझे सहमति है.
लेकिन, एक दूसरे स्तर पर, JS के अलावा भी अलग-अलग समाधान मौजूद होना तकनीकी प्रगति के लिहाज़ से बहुत महत्वपूर्ण है, इसलिए मुझे लगता है कि इसके उलट स्थिति का भी सम्मान किया जाना चाहिए!
Hacker News राय
एक राय यह है कि JavaScript मूल रूप से धीमा है। कई engineers ने इसे तेज़ बनाने की कोशिश की है, लेकिन यह अब भी static typed languages से धीमा है। बड़े प्रोग्रामों में स्पष्ट types वाली languages अधिक उपयुक्त होती हैं
JavaScript सीखना आसान नहीं है, और इसका prototype तथा type system जटिल है। TypeScript इससे मदद करता है, लेकिन फिर भी जटिलता बनी रहती है
केवल language बदलने से भी performance में बड़ा सुधार हो सकता है। मौजूदा system को JS और PHP से Go में बदलने पर 8-10 गुना performance improvement का अनुभव हुआ
parallel processing के महत्व को नज़रअंदाज़ किया जा रहा है। Rust parallel code लिखने के लिए उपयुक्त है, जबकि JS इसके लिए उपयुक्त नहीं है
JavaScript अब Java जैसी speed तक पहुँच चुका है, लेकिन C++ से 2-4 गुना धीमा है। performance बढ़ाने के लिए अपने comfort zone से बाहर निकलना पड़ता है
Rust, Zig, और Go programs में source code देखना और compile करना आसान है। नई language सीखने से समस्या हल करने के तरीके पर असर पड़ता है
ऐसा माना जाता है कि JavaScript tools की performance बढ़ाने की संभावनाएँ अभी पूरी तरह खत्म नहीं हुई हैं। लेकिन बेहतर foundation पर build करना अधिक कुशल है
Rspack, Rust में लिखा गया Webpack का compatible rewrite है, जिससे performance 5-10 गुना बेहतर होती है। यह Webpack को आसानी से replace कर सकता है
JavaScript dependencies को local में modify करना आसान है, लेकिन Rust में bugs कम होते हैं इसलिए बदलाव की ज़रूरत भी कम पड़ती है। Rust सीखना कठिन है, लेकिन इसे सीखकर दूसरी languages में भी बेहतर programmer बना जा सकता है