JavaScript का जन्म और मृत्यु
JavaScript ब्राउज़र में बहुत कम विशेषाधिकारों (privileges) के साथ चलता है। इसके बावजूद, यह सर्वर, बिल्ड टूल्स और यहाँ तक कि डेटाबेस भी चलाता है। यह कोई योजना नहीं थी। यह 1995 के एक निर्णय पर आधारित पैच (patches) की एक श्रृंखला थी।
2014 में, Gary Bernhardt ने "The Birth and Death of JavaScript" नामक एक टॉक (talk) दी थी। कई लोग इसे एक विफल भविष्यवाणी के रूप में देखते हैं। मैं इसे आर्किटेक्चरल घर्षण (architectural friction) के लिए एक नैदानिक उपकरण (diagnostic tool) के रूप में देखता हूँ।
Bernhardt ने एक विडंबनापूर्ण रास्ते का वर्णन किया। JavaScript एक खिलौना भाषा (toy language) के रूप में शुरू हुई थी। यह इसलिए जीवित रही क्योंकि ब्राउज़र में यही एकमात्र भाषा थी। इस एकाधिकार (monopoly) ने इसे दुनिया की सबसे अधिक निष्पादित (executed) भाषा बना दिया, भले ही यह सबसे अच्छा तकनीकी विकल्प न हो।
मुख्य तनाव सरल है। ब्राउज़र को कोड को सुरक्षित और तेज़ी से चलाने की आवश्यकता होती है। ये दोनों लक्ष्य अक्सर एक-दूसरे के विपरीत होते हैं।
2014 में, यह भविष्यवाणी की गई थी कि WebAssembly, JavaScript की जगह ले लेगा। ऐसा नहीं हुआ। WebAssembly स्थिर है और Figma या Google Earth जैसी चीज़ों के लिए उपयोगी है। हालाँकि, इसने एक एप्लिकेशन भाषा के रूप में JavaScript की जगह नहीं ली।
इसके बजाय, JavaScript का उत्परिवर्तन (mutation) हुआ। TypeScript, bundlers, और Deno या Bun जैसे नए runtimes, Bernhardt द्वारा पहचाने गए घर्षणों को ठीक करने के सभी प्रयास हैं।
इस टॉक का उपयोग JavaScript सीखने से बचने के लिए न करें। इसका उपयोग तब तक WebAssembly पर जाने को सही ठहराने के लिए न करें जब तक कि आपको प्रदर्शन (performance) की वास्तविक समस्या न हो।
इसका उपयोग अपने स्टैक (stack) के बारे में ये प्रश्न पूछने के लिए करें:
• क्या मैं इस टूल का उपयोग इसलिए कर रहा हूँ क्योंकि यह इस समस्या का सबसे अच्छा समाधान है? • क्या मैं इसका उपयोग इसलिए कर रहा हूँ क्योंकि इस संदर्भ में यही एकमात्र चीज़ है जो काम करती है? • क्या मेरे टूल्स की जटिलता किसी वास्तविक समस्या को हल करती है या उसे बस कहीं और स्थानांतरित कर देती है? • यदि मैं आज शून्य से शुरुआत करूँ, तो क्या मैं इसे चुनूँगा?
यदि आप सर्वर पर TypeScript का उपयोग करते हैं, तो आप टाइप सुरक्षा (type safety) प्राप्त करते हैं लेकिन कंपाइलेशन ओवरहेड (compilation overhead) बढ़ जाता है। यदि आप Next.js का उपयोग करते हैं, तो आप फीचर्स प्राप्त करते हैं लेकिन कैशिंग की जटिलता बढ़ जाती है। ये वास्तविक ट्रेड-ऑफ (trade-offs) हैं।
सबसे आम गलती भाषा को दोष देना है, जबकि समस्या वास्तव में खराब उपयोग की होती है। यदि आप भारी सिंक्रोनस (synchronous) कोड लिखते हैं जो इवेंट लूप (event loop) को ब्लॉक करता है, तो समस्या आप हैं, JavaScript नहीं।
किसी जादुई विकल्प की तलाश करना बंद करें। अपनी वास्तविक बाधाओं (bottlenecks) को मापना शुरू करें।