Rolldown: Rust में लिखा गया Rollup-संगत bundler
Rolldown नाम का एक नया JavaScript bundler, जो Rust में लिखा गया है और Rollup-संगत है, इस सवाल पर बहस छेड़ रहा है कि ecosystem को एक और tool की ज़रूरत क्यों है। समर्थकों का तर्क है कि Rust की performance, मजबूत multi-core कहानी, उभरता tooling ecosystem (जैसे Oxc), और Rollup-compatible व्यवहार, JavaScript- या Go-आधारित bundlers जैसे Rollup और esbuild को बढ़ाने के बजाय नए सिरे से शुरुआत करने को सही ठहराते हैं, खासकर complex code-splitting और plugin scenarios के लिए। आलोचक toolchain के fragmentation और सामान्य JS/TS developers की योगदान क्षमता घटने की चिंता जताते हैं, जबकि कुछ लोग Vite के साथ Rolldown की घनिष्ठ alignment को तेज़ और अधिक consistent builds की दिशा में एक आशाजनक रास्ता मानते हैं।
Rolldown के लिए प्रेरणा
- प्रोजेक्ट खुद को “Rust में Rollup-compatible” के रूप में पेश करता है, ताकि दो मानी गई समस्याएँ ठीक की जा सकें: esbuild में कमजोर code-splitting और Rollup में धीमे builds।
- टिप्पणीकारों का कहना है कि यह व्यवहार में “next generation Rollup” है और Rust-आधारित webpack विकल्प rspack का भी जवाब है।
- कुछ लोग इसे JS tooling में Rust की व्यापक लहर का हिस्सा मानते हैं (oxc, SWC, LightningCSS, Deno, आदि)।
esbuild या Rollup को बस बेहतर क्यों न किया जाए?
- Esbuild: इसे बढ़ाना बहुत कठिन बताया जाता है; bundling, treeshaking, transforms जैसी कई विशेषताएँ कुछ ही AST passes में कसकर जुड़ी हुई हैं, जिससे बड़े refactor करना maintainer के अलावा किसी और के लिए मुश्किल हो जाता है।
- इसका code-splitting ES module semantics और project priorities से सीमित है, जो जोखिम भरे “fast but maybe wrong” modes की बजाय correctness को प्राथमिकता देती हैं।
- Rollup: यह JS-आधारित होने और multicore का खराब उपयोग करने से सीमित है; JS code को native transforms (SWC, esbuild) के साथ मिलाने पर बार-बार parse/serialize steps और JS/native boundary crossings की overhead आती है।
Rust क्यों?
- Rust के पक्ष में तर्क: मजबूत performance, compile-time safety के साथ आसान multithreading, parsers के लिए अच्छी ergonomics (pattern matching, algebraic data types), और Cargo तथा crates.io के साथ एक सुसंगत ecosystem।
- आलोचकों का तर्क है कि कोई भी AOT-compiled language (Go, C#, C++) काम कर सकती है; सामान्य tooling workloads के लिए Rust का borrow checker अनावश्यक जटिलता हो सकता है या
.clone()के अत्यधिक उपयोग की ओर ले जा सकता है। - JS, Go, C++, C#, और Rust के बीच performance, safety, iteration speed, और tooling (Cargo बनाम CMake, C++ package manager की कमी, आदि) पर व्यापक बहस होती है।
Adoption, Vite integration, और ecosystem संबंधी चिंताएँ
- Rolldown Vite ecosystem से गहराई से जुड़ा है; सुझाव दिया जाता है कि यह लंबे समय में Vite में replacement होगा, और Vite 5.1 materials में शुरुआती experimentation का उल्लेख है।
- कुछ लोगों को चिंता है कि Rust core contributors के pool को कम कर देगा, क्योंकि अधिकांश JS/TS devs आसानी से इसमें patch नहीं कर सकते।
- अन्य लोग पूछते हैं कि क्या output quality (readability, non-“junk” bundles) Rollup के बराबर होगी और क्या यह Rollup की MagicString-style string hacking से बचेगा, बजाय इसके कि सीधे ASTs को transform करे।
Use cases और खुले प्रश्न
- Chunking को बड़ी, route-specific dependencies और dynamic imports को load करने के लिए महत्वपूर्ण माना जाता है, हालांकि कुछ लोग सवाल करते हैं कि क्या सचमुच कई apps को इसकी ज़रूरत है।
- यह स्पष्ट नहीं है कि Rolldown Vite में production-ready कब होगा और क्या यह dev और build behavior को पूरी तरह एकीकृत करेगा (“dev mode as build-plus”).