10 गुना तेज़ TypeScript

• Microsoft ने compiler और tools के native port के ज़रिये TypeScript performance में 10 गुना सुधार की घोषणा की
• editor startup time में बड़ा सुधार, build time 10 गुना कम, और memory usage में बड़ी कमी
• 2025 के मध्य तक tsc preview version जारी करने और 2025 के अंत तक full project build और language service उपलब्ध कराने की योजना

TypeScript performance सुधार की पृष्ठभूमि

• TypeScript की मुख्य वैल्यू बेहतरीन developer experience है
• codebase जितना बड़ा होता है, TypeScript की उपयोगिता उतनी बढ़ती है, लेकिन बड़े projects में performance issues सामने आते हैं
  • लंबे load और checking time की समस्या
  • तेज़ editor startup time और पूरे codebase analysis के बीच संतुलन की ज़रूरत
• AI-आधारित features के लिए तेज़ और सटीक semantic information की आवश्यकता है
• command-line build के ज़रिये codebase की स्थिति verify करने की मांग बढ़ रही है

native port की प्रगति योजना

• TypeScript compiler और tools के native port पर काम शुरू
• performance improvement के लक्ष्य:
  • editor startup time में बड़ा सुधार
  • build time को अधिकतम 10 गुना तक कम करना
  • memory usage में कमी
• 2025 के मध्य: command-line type checking सक्षम tsc preview version जारी करने की योजना
• 2025 के अंत: full project build और language service उपलब्ध कराने की योजना

कोड चलाना और testing

• TypeScript Go code repository में code build और run किया जा सकता है
• repository में tsc और language server को build और run करने के निर्देश दिए गए हैं
• नए features पर नियमित updates देने की योजना

कितना तेज़ हुआ?

• मौजूदा TypeScript projects के build time को कई लोकप्रिय codebases पर test करने पर निम्न performance improvements दिखे:
  • VS Code project में लगभग 15 लाख lines of code पर समय 77.8 सेकंड से घटकर 7.5 सेकंड हुआ, यानी लगभग 10.4 गुना तेज़
  • Playwright project में लगभग 3.5 लाख lines of code पर समय 11.1 सेकंड से 1.1 सेकंड हुआ, यानी लगभग 10.1 गुना सुधार
  • TypeORM project में लगभग 2.7 लाख lines of code पर समय 17.5 सेकंड से 1.3 सेकंड हुआ, यानी लगभग 13.5 गुना सुधार
  • date-fns project में लगभग 1 लाख lines of code पर समय 6.5 सेकंड से 0.7 सेकंड हुआ, यानी लगभग 9.5 गुना सुधार
  • tRPC project में लगभग 18 हज़ार lines of code पर समय 5.5 सेकंड से 0.6 सेकंड हुआ, यानी लगभग 9.1 गुना सुधार
  • rxjs project में लगभग 2 हज़ार lines of code पर समय 1.1 सेकंड से 0.1 सेकंड हुआ, यानी लगभग 11 गुना सुधार
• अभी सभी features पूरे नहीं हुए हैं, लेकिन ज़्यादातर codebases में 10 गुना या उससे अधिक performance improvement की उम्मीद है
• तेज़ type checking और code navigation संभव होगा
• AI tools integration और advanced refactoring support संभव होगा

editor performance सुधार

• editor load और response speed में सुधार
• Visual Studio Code codebase के आधार पर load time:
  • वर्तमान: 9.6 सेकंड → native version: 1.2 सेकंड (लगभग 8 गुना सुधार)
• memory usage में भी लगभग 50% कमी
• language service tasks (auto-complete, quick info, go to definition आदि) की performance बेहतर होने की उम्मीद
• Language Server Protocol (LSP) आधारित migration पर काम जारी है

version roadmap

• TypeScript 5.8 जारी हो चुका है, और TypeScript 5.9 जल्द आने वाला है
• JS-आधारित TypeScript codebase का development 6.x version के रूप में जारी रहेगा
• native codebase स्थिर होने पर इसे TypeScript 7.0 के रूप में जारी किया जाएगा
  • TypeScript 6 → JS-आधारित version
  • TypeScript 7 → native-आधारित version
• TypeScript 7 जारी होने के बाद भी 6.x version कुछ समय तक बनाए रखा जाएगा

अगले कदम

• performance, compiler API, LSP आदि पर अतिरिक्त जानकारी साझा की जाएगी
• GitHub FAQ में अक्सर पूछे जाने वाले सवाल देखे जा सकते हैं
• 13 मार्च 2025 को TypeScript community Discord में AMA आयोजित होगा (PDT सुबह 10 बजे | UTC शाम 5 बजे)

[click]

मुझे लगा कि लोग structural typing के बारे में सोचे बिना ही बात उछाल रहे हैं।
इसे C# या Rust जैसी nominal typing वाली भाषा में फिर से लिखना हो, तो प्रोजेक्ट की बुनियादी संरचना में बहुत ज़्यादा बदलाव करने पड़ते, इसलिए यह आसान नहीं रहा होगा।
structural typing अपनाने वाली भाषाओं में, मौजूदा JS-आधारित विकल्पों से बेहतर performance देने वाली चीज़ शायद C++ या Golang ही हो सकती है, लेकिन productivity तक को ध्यान में रखें तो कोई वास्तविक विकल्प नहीं है।

[kuthia]

किसी समय के बाद से TS में मेरी दिलचस्पी थोड़ी कम होने लगी थी, लेकिन ऐसी खबर देखकर फिर से उत्सुकता हो रही है, है न?

[pitou106]

ts में अगर वाकई बिल्कुल अपरिहार्य स्थिति को छोड़कर any का बेधड़क इस्तेमाल करने लगें, तो वो vanilla इस्तेमाल करने से अलग नहीं रह जाता.. ह

[yshrust]

लगता है विवाद काफ़ी गर्म है, इसलिए Anders Hejlsberg ने खुद आकर टिप्पणी छोड़ी है

https://github.com/microsoft/typescript-go/…

[jjpark78]

एक व्यक्ति जो चाहता है कि TypeScript में compile करने पर आउटपुट सीधे binary के रूप में मिले

[passerby]

फ़्रंटएंड के बारे में मुझे ज़्यादा जानकारी नहीं है.. क्या यह swc से अलग है?

[caniel]

SWC का फोकस Babel की तरह compatible JavaScript code जनरेट करने और bundling तक है, जबकि इसका फोकस TypeScript code को JavaScript में बदलने या errors को check करने पर है.

[halfenif]

अगर TypeScript कोड अब TypeScript में लिखा ही नहीं जाएगा, तो टीम खुद TypeScript का सीधे इस्तेमाल नहीं करेगी, और इससे लंबे समय में developer experience पर असर पड़ सकता है।

कहते हैं न, अपना ही बनाया हुआ खुद इस्तेमाल करना चाहिए। लेकिन language के मामले में यह थोड़ा सोचने वाली बात लगती है।

[dongjinahn]

मेरी निजी राय में, TS की बुनियाद JS के runtime ज़्यादातर (जैसे spidermonkey, v8) C++ में लिखे गए हैं और JS में implemented कोई runtime है भी नहीं,
और JS -> JS compilation भी pure JS से करने पर बहुत धीमा हो जाता है, इसलिए esbuild वगैरह की तरफ सब जाते दिखते हैं,
तो TS में भी क्या ज़रूरी है कि इतना dogfooding पर अड़े रहें, ऐसा लगता है

[wogns3623]

मुझे चिंता है कि कहीं बाद में मौजूदा TypeScript codebase के रखरखाव की अनदेखी न होने लगे।

[tsboard]

यह वाकई खुशखबरी है! हैरानी की बात है कि MS की TypeScript भाषा उम्मीद के उलट सच में काफी अप्रत्याशित(?) विकल्प चुनती दिखती है। MS के नज़रिए से देखें तो यह लगभग उसका पहला open source project था, और JS को replace करने की कोशिश करने वाले Google के Dart के विपरीत JS को complement करने का फैसला भी बहुत समझदारी भरा लगा। इस बार native porting language के लिए भी, जबकि उसके पास अपनी भाषाएँ भी काफी होंगी, Google के Go को चुनना भी चौंकाने वाला है।

[galadbran]

अरे, Deno वाली तरफ़ पहले से ही Rust-आधारित toolchain बना हुआ होगा... फिर अचानक Go क्यों?

[asheswook]

मेरा ख्याल है कि आप Node जैसे runtime की बात कर रहे हैं, लेकिन यहाँ बात TS भाषा के compiler की हो रही है।

[galadbran]

आह, लेख को थोड़ा और पढ़ने पर लगा कि editor के तेज़ होने वगैरह की बात भी थी, इसलिए शायद मैं भ्रमित हो गया था.

• tsc 10 गुना तेज़ हो गया है। यानी, ts -> js transpiling का समय बहुत कम हो गया है।
• VSCode जैसे ts में बने बड़े प्रोजेक्ट्स को load करते समय गति बहुत तेज़ हो जाती है। यानी, ts की syntax checking आदि tsc की सुविधाएँ साझा करने वाला logic तेज़ हुआ है।
• इसका मतलब यह नहीं है कि VSCode के चलने की गति तेज़ हो गई है।
  तो बात यह थी।

[illiil1lii]

रिकर्सिव generic types का इस्तेमाल करते समय मैंने इसे धीमा होते देखा है, इसलिए मुझे workaround अपनाना पड़ा। अगर यह 10 गुना तेज़ हो जाए, तो उम्मीद है कि ऐसे हिस्सों में भी सुधार हो सकेगा।

[tujuc]

"Go क्यों" वाली discussion thread दिलचस्प है।

https://github.com/microsoft/typescript-go/discussions/411

सोचने लायक बातें भी काफ़ी हैं...

[tsboard]

सही कहा, लेकिन .NET डेवलपर्स की भावना भी मैं समझ सकता हूँ...

[riki3]

लगता है .NET और Rust डेवलपर्स काफ़ी नाराज़ हो गए हैं

[bungker]

.NET समझ में आता है, लेकिन मुझे लगता है कि Rust, Go जैसी ही स्थिति में है। शायद पहले से बने हुए JS-संबंधित Go प्रोजेक्ट्स और लाइब्रेरीज़ ने भी इस फैसले को प्रभावित किया होगा।

[aa1567]

C# भाषा का डेवलपमेंट रुका नहीं है, लेकिन C# का इस्तेमाल करने वाले frameworks के साथ ऐसा बहुत ज़्यादा महसूस होता है कि उन्हें उपेक्षित छोड़ दिया गया है।

[clastneo]

Go में लिखें~

[caniel]

बहुत ज़्यादा उत्साहित हूँ।

[GN⁺]

Hacker News की राय

• TypeScript टीम के Daniel Rosenwasser ने घोषणा की खबर साझा की और बताया कि वे टीम लीडर Ryan Cavanaugh के साथ सवालों के जवाब देने के लिए तैयार हैं
  • Discord AMA में और अधिक जानकारी मिल सकती है
• तेज़ development tools शानदार हैं, और यह देखकर खुशी होती है कि TypeScript टीम हमेशा developer experience पर गहराई से सोचती है
  • अगर TypeScript कोड अब TypeScript में नहीं लिखा जाएगा, तो टीम खुद TypeScript का प्रत्यक्ष उपयोग नहीं करेगी, जिससे लंबे समय में developer experience पर असर पड़ सकता है
  • Flow के OCaml में लिखे जाने और असफल होने के उदाहरण का ज़िक्र करते हुए, टीम की सोच जानने की उत्सुकता जताई गई
• पहले Rust में तेज़ tsc बनाने की कोशिश के उदाहरण के तौर on दो प्रोजेक्ट्स का उल्लेख किया गया
  • stc: बंद हो चुका है
  • ezno: सक्रिय रूप से विकसित हो रहा है, और tsc के साथ 1:1 मेल को लक्ष्य नहीं बनाता
• अक्सर कोई प्रोजेक्ट एक लचीली scripting language से शुरू होता है, लेकिन अंत में ज़्यादा native expression जीत जाती है
  • यह भी राय दी गई कि शायद शुरुआत से ही lower-level expression अपनाना बेहतर हो सकता है
  • इससे सर्वर पर JS runtime इस्तेमाल करने की बुनियादी धारणा पर फिर से सोचने की ज़रूरत महसूस होती है
  • scripting languages के फायदे धीरे-धीरे कम होते जा रहे हैं
• एक पल के लिए लगा कि यह April Fools' Day मज़ाक है
• Go को चुनना अच्छा फैसला था
  • Rust की जगह Go चुनना प्रभावशाली लगा
  • यह अफसोस भी जताया गया कि AOT-compiled .NET नहीं चुना गया
• नए codebase को मौजूदा codebase के साथ जितना हो सके उतना compatible रखना महत्वपूर्ण है
  • Go का syntax TypeScript codebase से मिलता-जुलता है, इसलिए porting आसान है
• Golang और TypeScript की syntax संबंधी समानता पर हैरानी जताई गई
  • Golang में sum types इस्तेमाल करने में हुई कठिनाई का अनुभव साझा किया गया
• Daniel और Anders द्वारा native port पर की गई गहन चर्चा वाले एक podcast का परिचय दिया गया
• बड़े TypeScript files को refactor करते समय performance problems सामने आने की बात कही गई
  • TypeScript में codebase migration से टीम को बहुत मदद मिली, लेकिन performance issues अब भी मौजूद हैं
• पहले PHP इस्तेमाल किया जाता था, लेकिन 4 साल पहले से TypeScript का उपयोग शुरू किया गया
  • TypeScript का type system उपयोगी है और compile speed तेज़ है
  • Microsoft के प्रशंसक न होने के बावजूद, TypeScript को एक अच्छी तरह बनाई गई भाषा माना गया है