Vite 8.0 जारी

 (vite.dev)
13 पॉइंट द्वारा GN⁺ 2026-03-14 | 5 टिप्पणियां | WhatsApp पर शेयर करें
  • मौजूदा esbuild + Rollup डुअल स्ट्रक्चर को Rust-आधारित बंडलर Rolldown में एकीकृत करके अधिकतम 10~30 गुना तेज़ build performance हासिल की गई
  • नया plugin registry जारी किया गया है, जिससे Vite·Rolldown·Rollup plugins को खोजा और manage किया जा सकता है
  • Vite Devtools, TypeScript path resolution, Wasm SSR, console forwarding जैसी developer convenience features जोड़ी गई हैं
  • यह release Vite ecosystem का सबसे बड़ा structural change है, जो आगे integrated toolchain development की नींव बनेगा

Rolldown-आधारित Vite 8

  • Vite 8 ने मौजूदा esbuild(डेवलपमेंट के लिए) और Rollup(प्रोडक्शन के लिए) की डुअल बंडलर संरचना को Rolldown single bundler में एकीकृत किया
    • Rolldown एक Rust में लिखा गया high-performance bundler है, जो Rollup के समान plugin API को support करता है
    • मौजूदा ज़्यादातर Vite plugins बिना किसी अलग modification के काम करते हैं
  • Performance Rollup की तुलना में 10~30 गुना तेज़ है, और module-level caching, flexible chunk splitting, Module Federation जैसी advanced features को support करती है

Rolldown अपनाने की प्रक्रिया

  • शुरुआती चरण में rolldown-vite package के रूप में technology preview दिया गया, ताकि community feedback इकट्ठा किया जा सके
    • अलग-अलग real-world codebases पर test करते हुए compatibility issues को हल किया गया
    • मुख्य plugins और frameworks के लिए dedicated CI test system बनाया गया
  • दिसंबर 2025 में Vite 8 beta जारी करते हुए Rolldown को पूरी तरह integrate किया गया
    • beta अवधि के दौरान Rolldown Release Candidate stage तक पहुँचा और स्थिर हुआ

वास्तविक performance improvement के उदाहरण

  • कई कंपनियों ने build time reduction की रिपोर्ट दी
    • Linear: 46 सेकंड → 6 सेकंड
    • Ramp: 57% कमी
    • Mercedes-Benz.io: अधिकतम 38% कमी
    • Beehiiv: 64% कमी
  • बड़े projects में इसका असर और अधिक स्पष्ट दिखा, और Rolldown में लगातार सुधार का संकेत दिया गया

Integrated toolchain और technology stack

  • Vite 8, Vite(build tool), Rolldown(bundler), Oxc(compiler) के घनिष्ठ सहयोग से एक end-to-end toolchain के रूप में विकसित हुआ
    • parsing·transformation·optimization की पूरी प्रक्रिया में consistency सुनिश्चित
    • Oxc के semantic analysis का उपयोग करके tree-shaking optimization संभव
    • नए JS specifications को तेज़ी से अपनाने वाली संरचना

अतिरिक्त सुविधाएँ

  • Vite Devtools: development server में project state का visual analysis संभव
  • TypeScript path(alias) auto resolution और emitDecoratorMetadata के लिए built-in support
  • Wasm SSR: server-side rendering environment में .wasm?init import support
  • Browser console forwarding: browser errors को terminal तक भेजकर debugging efficiency बढ़ाता है
  • @vitejs/plugin-react v6: Babel हटाया गया, Oxc-आधारित React Refresh लागू, install size में कमी

आगे की development direction

  • Full Bundle Mode(प्रायोगिक): development के दौरान भी bundling करके 3 गुना तेज़ server startup, 40% तेज़ reload, 10 गुना कम network requests हासिल
  • Raw AST transfer और Native MagicString transformation के जरिए Rust और JS के बीच performance gap कम करना
  • Environment API stabilization के लिए ecosystem collaboration जारी

Install size में बदलाव

  • Vite 8, Vite 7 की तुलना में लगभग 15MB बड़ा है
    • lightningcss(लगभग 10MB): default CSS minification feature प्रदान करता है
    • Rolldown binary(लगभग 5MB): speed optimization के लिए size बढ़ा
  • आने वाले releases में size optimization जारी रहेगी

Migration guide

  • ज़्यादातर projects को settings बदले बिना upgrade किया जा सकता है
    • मौजूदा esbuild और rollupOptions settings अपने-आप convert हो जाती हैं
  • बड़े projects के लिए 2-step migration की सिफारिश
    • Vite 7 से rolldown-vite पर switch करने के बाद Vite 8 पर upgrade
  • विस्तृत प्रक्रिया आधिकारिक Migration Guide और Changelog में देखी जा सकती है

Rollup और esbuild के लिए आभार

  • Rollup ने Vite के plugin ecosystem की नींव प्रदान की, और Rolldown ने उसी API को आगे बढ़ाया
  • esbuild तेज़ development experience देने वाली मुख्य तकनीक रही, और Rust·Go-आधारित tooling के विकास की प्रेरणा बनी
  • दोनों projects का योगदान Vite के DNA में गहराई से समाहित है

Community और collaboration

  • Vite 8 का विकास sapphi-red और Vite team, Rolldown team, और अनेक community contributors के सहयोग से पूरा हुआ
  • VoidZero, Bolt, NuxtLabs ने प्रमुख partners के रूप में भाग लिया

संबंधित पढ़ाई

5 टिप्पणियां

 
GN⁺ 2026-03-14
Hacker News की राय

  • यह सोचने पर मजबूर करता है कि इंडस्ट्री ने “build तो वैसे भी धीमे ही होते हैं” मानकर बिना सवाल किए जिन अक्षम tools का इस्तेमाल किया, उनमें कितने computing resources बर्बाद किए
    हमने उन्हीं धीमे builds के हिसाब से schedules बनाए, break time को मज़ाक की तरह लिया, और cache layers तक बना डाले
    Vite maintainers को सलाम

    • धीमे JS bundles से बर्बाद हुए resources से भी बड़ा नुकसान अक्षम runtimes और abstractions से होता है
      ज़्यादातर production software ज़रूरत से कई गुना धीमा है
      Electron apps कई GB RAM खाकर भी 40 साल पुराने software से ज़्यादा laggy लगते हैं, यही इसका सबूत है
    • मैं भी यही सोचता हूँ। ESLint या Prettier जैसे tools भी Oxc के बारे में जानने के बाद वैसी ही बर्बादी लगने लगे
    • लगता है आगे चलकर matrix multiplication में भी हम ऐसी बर्बादी पर पीछे मुड़कर सोचेंगे
    • build performance लंबे समय से मेरी दिलचस्पी का विषय रही है
      14 साल पहले build का इंतज़ार करते हुए बर्बाद होने वाला समय देखकर लगा था कि यह समस्या खासकर Java ecosystem में गंभीर है
      पहले एक Ruby project में integration tests हर बार DB फिर से बनाते थे और उसमें 10 मिनट लगते थे
      Kotlin/Spring Boot की compilation भी धीमी है, और Rust compiler भी कोई बहुत तेज़ नहीं है
      लेकिन tests हमारे नियंत्रण में होते हैं। unit tests milliseconds में खत्म होने चाहिए, और integration tests में parallelization और data randomization से बड़ा सुधार संभव है
      मैं MacBook Pro पर Redis, DB और Elasticsearch सहित सैकड़ों spring integration tests 40 सेकंड से कम में चलाता हूँ
      एक बार ऐसा setup बन जाए तो fast feedback loop मिलता है और development का मज़ा लौट आता है

  • Vite 8 में मेरा योगदान Wasm SSR support था
    मैंने .wasm?init imports को SSR environment में भी काम करने लायक बढ़ाया
    प्रक्रिया धीमी थी, लेकिन टीम ने बारीकी से मदद की और documentation भी जोड़ी, यह काफ़ी प्रभावशाली था

    • ऐसी behind-the-scenes बातें सुनकर और दिलचस्प लगता है
      इससे महसूस होता है कि Vite team सिर्फ tool नहीं बना रही, बल्कि contributors की training और collaboration को भी गंभीरता से लेती है

  • Electron के दौर में ऐसी performance improvements देखना सच में अच्छा लगता है
    एक project जिसे मैं लंबे समय से maintain कर रहा हूँ (जो React hooks से पहले शुरू हुआ था), उसमें पहले Webpack-आधारित react-scripts से build होने में 2 मिनट लगते थे
    अब Vite 8 के साथ वही 1 सेकंड में खत्म हो जाता है। यह दिखाता है कि हम कितने resources बर्बाद करते आए हैं

    • अब लगता है AI models के ऊपर machine-readable interfaces को जबरन चिपकाने वाला नया दुःस्वप्न शुरू हो गया है
    • विडंबना यह है कि Vite homepage A55 या S23FE पर भी lag करता है
    • असल में JS तो मूल रूप से ऐसी भाषा थी जिसे build process की ज़रूरत नहीं होती
      browser को इसे सीधे चलाना चाहिए, और TypeScript भी केवल types हटते ही सीधे चलने लायक डिज़ाइन की गई थी
      ऐसे build tools का अस्तित्व ही शायद गलत दिशा लगता है

  • हमारी team में Vite 8 अपनाने के बाद build time 4 मिनट से घटकर 30 सेकंड हो गया
    यह लगभग drop-in replacement जैसा था, और Vite team का धन्यवाद

    • हमारे यहाँ भी 10 सेकंड से 1 सेकंड हो गया। इसकी कुंजी Rolldown है
      Vite में integrate होने से पहले से ही हम इसे इस्तेमाल कर रहे थे, और यह सच में शानदार है
    • 4 मिनट? जानना चाहूँगा app कितना बड़ा है
      लोग कहते हैं कि यह Next से तेज़ है, तो उस स्तर पर यह काफ़ी विशाल scale होगा
    • हमारे एक project में 12 मिनट से 2 मिनट हो गया। सच में चौंकाने वाला बदलाव है

  • Vite team का धन्यवाद, जिसने किसी खास framework से बंधा नहीं हुआ open source bundling solution बनाया
    (हल्की खाँसी के साथ Turbopack का ज़िक्र)

  • शानदार खबर है। लेकिन लगता है Next.js ऐसी community उपलब्धियों का लाभ नहीं उठा पाएगा
    वजह है Vercel का NIH syndrome

    • Vercel का तरीका हमेशा अधूरे previews को सालों तक चलाते रहने जैसा रहा है
      Next 13 में Turbopack alpha शुरू किया और Next 16 में जाकर उसे default बनाया
      2022 में Vite के साथ तुलना वाले benchmarks भी विकृत थे
      caching issues, धीमी performance, RSC security vulnerabilities, उलझाऊ app router, Vercel के बाहर hosting की असुविधा आदि
      Next.js चुनना अपने आप में एक risk है
      संबंधित links: तुलना चर्चा, caching history, performance analysis, security CVE, OpenNext
    • कई साल बाद React पर लौटा हूँ, लेकिन Next के होने की वजह समझना मुश्किल है
      आधिकारिक docs में भी Next को default की तरह पेश करना अजीब लगता है
      React को non-SPA की तरह इस्तेमाल करने की वजह समझ नहीं आती
    • Next.js की संरचना ऐसी है कि कई enterprise SaaS partners के integrations के कारण उसे official SDK के रूप में आगे बढ़ाया जाता है
      उदाहरण: Sitecore Cloud, Sanity, Contentful आदि
    • जानकारी के लिए, Cloudflare Vinext भी है (हालाँकि मैंने खुद इस्तेमाल नहीं किया)

  • Vite+, Void Cloud, Void Framework आदि के साथ
    अब लगता है Vercel और Void के बीच मुकाबला शुरू होगा
    खासकर PRC(Server Functions) demo दिलचस्प है — यह DB से UI तक end-to-end type safety दिखाता है
    हम Telefunc(tRPC के विकल्प) के साथ RPC design पर शोध कर रहे हैं, और Void team के साथ collaboration की उम्मीद है
    संबंधित links: PRC demo video, Telefunc, Vike

    • दिलचस्प बात यह है कि ऐसी अफ़वाह है कि Vercel अप्रत्यक्ष रूप से Void का investor है
      Void Cloud शायद Cloudflare Workers के ऊपर बना है, और फिलहाल जानकारी कम है
      फिर भी Vite+ को MIT open source के रूप में जारी करना बहुत उत्साहजनक है
      अगर Bun, Anthropic support पर ध्यान केंद्रित करते हुए OSS की अनदेखी करता है, तो वह अपनी competitive edge खो सकता है
      संदर्भ: Void Cloud

  • JS ecosystem चाहे जितना उलझा हो, Vite लगातार बेहतरीन DX और production quality दिखाता आया है
    integrated Rolldown bundler के साथ यह और तेज़ व लचीला foundation बनेगा
    1998 से web development कर रहा हूँ, और इस नज़रिए से मैं इसका बहुत बड़ा fan हूँ

  • मैं long-term maintenance को महत्व देता हूँ, इसलिए esbuild को सीधे इस्तेमाल करता हूँ
    Vite जैसे wrappers internal changes की वजह से जब-तब टूटें, यह मुझे पसंद नहीं

    • मैंने भी इसी तरह esbuild + एक साधारण RPC layer इस्तेमाल की है
      type validation के लिए Zod, और सिर्फ Postgres types का code generation किया
      अगली बार शायद Kysely इस्तेमाल करता
    • esbuild ही वह अकेला JS tool है जो कई सालों बाद भी टूटा नहीं
    • लेकिन अभी भी इसमें code splitting की कमी है
    • Top-level await का support भी नहीं है, और live reloading, HMR की तुलना में काफ़ी धीमा है

  • tsconfig paths के लिए built-in support वाकई शानदार QoL improvement है
    इससे config duplication कम किया जा सकता है

    • अच्छी खबर है, लेकिन Node.js import alias भी आज़माने लायक है
      project के अनुसार वह और सरल हो सकता है
 
aer0700 2026-03-14

असल में JS मूल रूप से ऐसी भाषा थी जिसे build process की ज़रूरत नहीं थी; browser को इसे वैसे ही चला पाना चाहिए, और TypeScript को भी इस तरह डिज़ाइन किया गया था कि सिर्फ types हटाकर उसे तुरंत चलाया जा सके। ऐसे build tools का अस्तित्व ही गलत दिशा जैसा लगता है -> इसे सामान्य स्थिति में वापस कैसे लाया जा सकता है?
 
carnoxen 2026-03-17

जो चीज़ अब तक सिर्फ़ browser में चलती थी, वह अब सीधे server पर चलने लगी है, इसलिए यह शायद एक तरह से अपरिहार्य क्रम ही लगता है।
 
ahiou 2026-03-15

मुझे लगता है कि यह web app के उन्नत होते जाने से पैदा हुई एक स्वाभाविक घटना है।
 
savvykang 2026-03-14

शायद ब्राउज़र JS को भी Flash की तरह छोड़ देना चाहिए, है ना? लेकिन JS के छोड़े जाने के कोई आसार नज़र नहीं आते।