There is a peculiar kind of silence in a room full of developers waiting for a build to finish. Eyes drift to second mon

बिल्ड पूरा होने का इंतज़ार कर रहे डेवलपर्स से भरे कमरे में एक अजीब तरह की खामोशी होती है। नज़रें दूसरे मॉनिटर्स पर भटकती हैं। अंगूठे फोन स्क्रॉल करते हैं। कोई ऐसी कॉफी लेने उठता है जिसकी उसे वास्तव में ज़रूरत नहीं है। यदि आपने आधुनिक JavaScript codebase में थोड़ा भी समय बिताया है, तो आप इस ठहराव को जानते हैं। यह कोई ब्रेक नहीं है। यह आपकी सोच में एक रुकावट है।

हम फ्रेमवर्क के बारे में बहुत बात करते हैं। React, Vue, Svelte, और अगले हफ्ते जो भी नया आएगा, सारा ध्यान उन्हीं पर रहता है। कॉन्फ्रेंस फ्रेमवर्क की घोषणाओं के लिए बिक जाती हैं। ब्लॉग पोस्ट सिंटैक्स शुगर का विश्लेषण करते हैं। लेकिन इस पूरे यूज़र-फेसिंग शोर के नीचे, ज़मीन इस तरह बदल रही है जो वास्तव में आपके कोड लिखने के तरीके को बदल देगी। क्रांति किसी फ्रंटएंड फ्रेमवर्क से नहीं आ रही है। यह टूलिंग लेयर में हो रही है, और इसे Rust और Go में लिखा जा रहा है।

सालों तक, JavaScript टूल्स JavaScript के साथ ही बनाए गए थे। यह तर्कसंगत था। Babel ने एक पीढ़ी को सिखाया कि आज ही कल के सिंटैक्स को कैसे लिखा जाए। Webpack ने हमारे विभाजित कोड को ऐसी चीज़ में बंडल किया जिसे ब्राउज़र समझ सके। ESLint ने हमारे कमिट करने से पहले ही बग्स पकड़ लिए। ये टूल्स एक छोटे वेब के लिए बनाए गए थे। उन्होंने कुछ सौ मॉड्यूल्स की कल्पना की थी, दस हज़ार की नहीं। उन्होंने सिंगल रेपो (single repos) की कल्पना की थी, मोनोरेपो (monorepos) की नहीं, जहाँ एक साझा UI पैकेज में बदलाव का असर दर्जनों एप्लिकेशन पर पड़ता है।

फिर ऐप्स बड़े होते गए। कोडबेस विशाल रिपॉजिटरी में बदल गए। टूल्स वही रहे, और लेटेंसी (latency) बढ़ती गई। दो सेकंड में होने वाला हॉट रीलोड बारह, फिर तीस सेकंड का हो गया। लंच से पहले पूरा टेस्ट सुइट चलाना एक कल्पना बन गया। Linters उन फाइलों पर अटकने लगे जिन्हें वे हज़ारों बार चेक कर चुके थे। कागज़ पर हर देरी छोटी लगती है। व्यवहार में, ये ठहराव एकाग्रता को तोड़ देते हैं। वे आपको अपने काम को बैच में करने, किसी फिक्स के काम करने से पहले झिझकने, और प्रयोग करने से बचने के लिए प्रशिक्षित करते हैं क्योंकि फीडबैक मिलने में बहुत समय लगता है।

टूलिंग की अगली पीढ़ी बस JavaScript के रास्ते से हटकर उस लेटेंसी पर प्रहार करती है।

नया इंजन रूम

देखें कि कैसे विशिष्ट कार्यों को वापस पाया जा रहा है।

Transformation का मतलब पहले Babel होता था। यह एक यूनिवर्सल प्रीप्रोसेसर था, जो JSX और stage-3 प्रस्तावों को सादे ES5 में बदलता था। यह अभी भी प्रभावशाली सॉफ्टवेयर है, लेकिन यह सिंगल-थ्रेडेड JavaScript है जो JavaScript को ही पार्स (parse) कर रहा है। अब OXC का आगमन हुआ है, जो एक Rust-आधारित टूलचेन है। यह वही काम करता है जो Babel करता है, लेकिन बेंचमार्क बताते हैं कि यह लगभग 40 गुना तेज़ है और 70% कम मेमोरी का उपयोग करता है। यह कोई मामूली सुधार नहीं है। यह उस टूल और उस टूल के बीच का अंतर है जिसे आप नोटिस करते हैं और उस टूल के बीच जिसे चलते हुए आप भूल जाते हैं।

Bundling वह जगह है जहाँ सबसे ज़्यादा समस्या थी। Webpack एक दशक तक मानक बना रहा, लेकिन इसके इंटरनल एक अलग स्केल के लिए बनाए गए थे। Turbopack, जो इसका Rust उत्तराधिकारी है, केवल तेज़ी से रीकंपाइल नहीं करता है। यह यह समझने के लिए आक्रामक मेमोइज़ेशन (memoization) का उपयोग करता है कि वास्तव में क्या बदला है और केवल उसी हिस्से को फिर से बनाता है। एक बड़े एप्लिकेशन में, एक सिंगल कंपोनेंट को बदलने में पूरा ग्राफ ट्रैवर्सल (graph traversal) नहीं होना चाहिए। Turbopack के साथ, बिल्ड लगभग तत्काल होने लगते हैं। प्रोग्रेस बार गायब हो जाता है क्योंकि देखने के लिए कुछ बचता ही नहीं है।

Testing की अपनी अलग ही बाधा है। Jest ने JavaScript टेस्टिंग को फिर से परिभाषित किया, फिर भी वॉच मोड (watch mode) में ऐसा महसूस हो सकता है जैसे वह हर कीस्ट्रोक पर आपके कोडबेस को फिर से सीख रहा हो। Vitest एक अलग आर्किटेक्चरल दृष्टिकोण अपनाता है। क्योंकि यह शून्य से अपना खुद का डिपेंडेंसी ट्री बनाने के बजाय Vite के मॉड्यूल ग्राफ का पुन: उपयोग करता है, इसलिए यह वॉच मोड में Jest की तुलना में लगभग 8.5 गुना तेज़ गति से रिपोर्ट करता है। यहाँ जीत केवल कच्ची गति (raw velocity) की नहीं है। यह सामंजस्य (coherence) की है। आपका टेस्ट रनर और आपका देव सर्वर अंततः इस बात पर सहमत होते हैं कि आपका प्रोजेक्ट कैसा दिखता है।

Linting भी इसी तरह के ओवरहेड से जूझता है। ESLint का लचीलापन ही उसकी महाशक्ति है; इसके नियम केवल AST पर काम करने वाले JavaScript फ़ंक्शन हैं। उस लचीलेपन की कीमत प्रोसेसिंग साइकिल के रूप में चुकानी पड़ती है। Rust में लिखा गया Oxlint, दायरे को सामान्य मामलों तक सीमित करता है और तेज़ी से काम करता है। यह ESLint की तुलना में 50 से 100 गुना तेज़ चलता है। इसका व्यावहारिक प्रभाव यह है कि लिंटिंग आपके एडिटर के सेव एनिमेशन से पहले ही समाप्त हो जाती है। आप उन लाल लहरदार रेखाओं (red squiggles) को सहन करना बंद कर देते हैं जो समस्या ठीक करने के बाद भी सेकंडों तक बनी रहती हैं।

शायद सबसे प्रतीकात्मक बदलाव type checking में हो रहा है। Microsoft वर्तमान में TypeScript compiler को Go में फिर से लिख रहा है। शुरुआती बेंचमार्क चौंकाने वाले हैं: नए कार्यान्वयन (implementation) के साथ VS Code लगभग 8 गुना तेज़ी से लोड होता है, और type checking स्वयं लगभग 10 गुना तेज़ है। विचार करें कि इसका क्या अर्थ है। TypeScript, JavaScript की सफलता की कहानी है। यह एक ऐसी भाषा है जो JavaScript में कंपाइल होती है, जिसका उपयोग JavaScript ecosystems को type-check करने के लिए किया जाता है, और अब इसका अपना compiler एक native systems language पर जा रहा है क्योंकि JavaScript वह प्रदर्शन (performance) नहीं दे सकता जिसकी ecosystem को आवश्यकता है। यह टूल गति प्राप्त करने के लिए अपने ही मार्ग को बदल रहा है।

इनमें से कुछ भी React की जगह नहीं लेता। यह Next.js को खत्म नहीं करता और न ही TypeScript को अप्रचलित (obsolete) बनाता है। Frameworks अभी भी आपके component model और routing को परिभाषित करते हैं। ये नए टूल्स बस नीचे की हर चीज़ को तेज़ बना देते हैं। वे सड़क हैं, कार नहीं।

जब गति व्यवहार बदल देती है

Tooling से जुड़ी चर्चाएँ अक्सर बेंचमार्क चार्ट में ही अटक जाती हैं। संख्याओं की तुलना करना आसान है। लेकिन वास्तविक प्रभाव मानवीय व्यवहार में होता है।

जब फीडबैक सेकंड से घटकर मिलीसेकंड में आ जाता है, तो आप केवल कार्यों को तेज़ी से पूरा नहीं करते। आप उन्हें अलग तरह से पूरा करते हैं। आप बदलावों को जमा करना बंद कर देते हैं। आप एक लाइन लिखते हैं, परिणाम देखते हैं, और सुधार करते हैं। आप टेस्ट इसलिए चलाते हैं क्योंकि वे तुरंत हो जाते हैं, न कि इसलिए क्योंकि आपके pull request की उन्हें आवश्यकता है। आप उस refactor को आज़माते हैं जो शायद काम न करे, क्योंकि उसे वापस लेना (undo करना) कुछ भी खर्च नहीं करता। आप मशीन के वापस अनुमति देने का इंतज़ार करने के बजाय समस्या के समाधान में ही डूबे रहते हैं।

इसे मनोवैज्ञानिक 'flow' कहते हैं। इसके लिए क्रिया और परिणाम के बीच एक सटीक लूप की आवश्यकता होती है। एक गिटारवादक तब नहीं बजा सकता यदि amp हर नोट में देरी करे। एक चित्रकार रंग तब नहीं मिला सकता यदि ब्रश आधा सेकंड की देरी से अपडेट हो। डेवलपर्स भी अलग नहीं हैं। Latency केवल एक झुंझलाहट नहीं है। यह सोचने पर लगने वाला एक टैक्स है।

इसलिए, उत्पादकता में वृद्धि केवल तकनीकी नहीं है। यह आदतन है। तेज़ टूल्स आपको प्रयोग करने के लिए प्रशिक्षित करते हैं। धीमे टूल्स आपको हिचकिचाने के लिए प्रशिक्षित करते हैं। एक साल के दौरान, यह अंतर पूरी तरह से अलग सॉफ़्टवेयर में बदल जाता है। तत्काल फीडबैक वाली टीम अधिक आत्मविश्वास के साथ काम (ship) करती है। वे काम को छोटे टुकड़ों में बाँट देते हैं क्योंकि कोशिश करने की लागत शून्य होती है। उनके code reviews कम हो जाते हैं क्योंकि बग्स उसी क्षण पकड़े जाते हैं, बीस मिनट बाद CI में नहीं।

अदृश्य कार्य

यही कारण है कि सुर्खियाँ भ्रामक होती हैं। Frameworks के बारे में लिखना आसान है। उनके पास लोगो, APIs और Twitter ड्रामा होता है। Infrastructure डिज़ाइन के अनुसार अदृश्य होता है। आप एक bundler को कॉन्फ़िगर करने के उत्साह के साथ नहीं जागते। आप चाहते हैं कि वह गायब हो जाए। लेकिन गायब होना ही वह काम है जो एक अच्छा infrastructure करता है। यह भार उठाता है ताकि दृश्य परत (visible layer) हल्की बनी रहे।

यदि आप किसी टीम का नेतृत्व कर रहे हैं या किसी legacy codebase का रखरखाव कर रहे हैं, तो इसे आपकी प्राथमिकताओं को सूचित करना चाहिए। React से Vue पर माइग्रेट करना आपके component tree को नया आकार दे सकता है। Webpack से Turbopack या Babel से OXC पर माइग्रेट करना आपके पूरे कार्यदिवस को बदल सकता है। बाद वाली बात को मैनेजमेंट को समझाना कठिन है क्योंकि इसके लिए कोई नया होमपेज डेमो नहीं होता। वहाँ केवल एक ऐसी टीम होती है जो अपने build terminal को देखकर आहें भरना बंद कर देती है।

ऑडिट करें कि वास्तव में आपको क्या धीमा कर रहा है। यदि आप 2015 में बने toolchain पर एक आधुनिक monorepo चला रहे हैं, तो आप रूढ़िवादी (conservative) नहीं हो रहे हैं। आप दैनिक घर्षण कर (friction tax) चुका रहे हैं। इसका समाधान कोई नया frontend paradigm सीखना नहीं है। यह इंजन को बदलना है।

Frameworks आते रहेंगे। उन्हें ट्वीट्स और कॉन्फ्रेंस की मुख्य बातें (keynotes) मिलती रहेंगी। लेकिन JavaScript को लिखने का अनुभव कैसा है, इसमें वास्तविक बदलाव पर्दे के पीछे (under the hood) हो रहा है, उन compiled languages में जो आपके समय को कीमती मानती हैं। यही क्रांति है। किसी लिस्ट को रेंडर करने का नया तरीका नहीं, बल्कि एक ऐसा toolchain जो इतना तेज़ हो कि आपके रास्ते से हट जाए और आपको सोचने दे।