00:00:00(प्रफुल्ल संगीत) - नमस्ते, सभी को।
00:00:06मैं Lydia हूँ।
00:00:07मेरा पद BUN में प्रोपेगेंडा का मुखिया है।
00:00:11अगर आप मेरे बारे में कुछ जानते हैं,
00:00:13तो आप जानते हैं कि मैं JavaScript रनटाइम और परफॉर्मेंस के बारे में बात करना पसंद करता हूँ।
00:00:17दरअसल,
00:00:17BUN से जुड़ने से पहले,
00:00:19मैं कुछ सालों के लिए Vercel में था ताकि Next डेवलपर्स को तेजी से ऐप्स बनाना सिखाया जा सके।
00:00:24तो मैं यहाँ आज यह दिखाने के लिए बहुत उत्साहित हूँ कि यह कितना बेहतर हो सकता है जब हम Next Framework की परफॉर्मेंस को BUN के रनटाइम परफॉर्मेंस के साथ जोड़ते हैं।
00:00:35लेकिन BUN के बारे में बात करने से पहले,
00:00:38मैं थोड़ा पीछे जाना चाहता हूँ और दिखाना चाहता हूँ कि Next.js जैसे फ्रेमवर्क पहले स्थान पर क्या खास बनाते हैं।
00:00:45क्योंकि उन्होंने वास्तव में वेब पर परफॉर्मेंस को फिर से परिभाषित किया।
00:00:49इसने सिर्फ वेबसाइटों को तेजी नहीं दी।
00:00:52इसने प्रक्रिया के हर हिस्से को सुव्यवस्थित किया।
00:00:55हमें Webpack के साथ और अब Turbo Pack के साथ स्मार्ट bundling मिली।
00:00:59हमें built-in image और font optimization मिली।
00:01:02हमें efficient server-side rendering,
00:01:05static-side rendering मिली और अब हमें ISR और RSC मिल गया ताकि data fetching को component में ही लाया जा सके।
00:01:12और ये सभी सुधार किसी तरह फ्रेमवर्क को optimize करने की सीमा को बढ़ाते हैं,
00:01:17लेकिन वास्तव में सिर्फ एक निश्चित बिंदु तक।
00:01:21हमेशा यह एक मौलिक layer रहा है जिसे Next.js अभी तक optimize नहीं कर सका।
00:01:26और यह engineering के प्रयास या capability की कमी के कारण नहीं है,
00:01:31बल्कि यह Next के दायरे से बाहर है।
00:01:34और वह है runtime खुद।
00:01:37आमतौर पर जब आप Next dev चलाते हैं या Vercel पर deploy करते हैं,
00:01:40तो आपका Next app Node पर चलता है।
00:01:42तो इसका मतलब है कि Node का runtime आपके JavaScript को execute करता है।
00:01:45यह event loop को manage करता है, file IO को, सबकुछ।
00:01:49और यह आपके JavaScript code को operating system से connect करता है।
00:01:53और यह समझ में आता है क्योंकि Node पिछले लगभग 15 सालों से default runtime रहा है।
00:01:59यह battle tested है,
00:02:01यह reliable है,
00:02:02लेकिन 2025 में,
00:02:03यह भी एक bottleneck बन गया है।
00:02:06गलत मत समझो, Node शानदार है।
00:02:09यह server पर JavaScript चलाना संभव बनाया।
00:02:13उससे पहले,
00:02:14Node के 2009 में introduce होने से पहले,
00:02:17JavaScript वास्तव में सिर्फ browser के लिए था।
00:02:20Node ने इसे एक runtime देकर बदल दिया जिसमें JavaScript engine,
00:02:24event loop,
00:02:25async IO और browser से परे सभी चीजें करने के लिए APIs हैं।
00:02:29जैसे disk से files पढ़ना, memory, सब कुछ।
00:02:33अब hood के नीचे, Node V8 JavaScript engine का use करता है।
00:02:37यह Google का तेज Chrome engine है,
00:02:39जो long running tasks के लिए बहुत अच्छा है,
00:02:42जैसे आपके Chrome browser में एक tab।
00:02:44लेकिन बिल्कुल, V8 सिर्फ एक engine है।
00:02:46यह सिर्फ JavaScript को execute करना जानता है।
00:02:49यह files open नहीं कर सकता,
00:02:51TCP connections नहीं बना सकता,
00:02:53और इस तरह की सभी चीजें।
00:02:54तो यहीं Node के built-in APIs काम आते हैं।
00:02:57जैसे FS, HTTP, NET, और इसी तरह।
00:03:01तो ये APIs किसी तरह हमारे JavaScript code और operating system के बीच bridge हैं।
00:03:07और ये APIs खुद एक C library पर निर्भर करते हैं जिसे libuv कहते हैं।
00:03:13यह JavaScript के लिए ही बनाया नहीं गया है।
00:03:16यह ज्यादा एक generic abstraction है जो Node अलग-अलग operating systems पर file IO,
00:03:23networking,
00:03:24और सामान करने के लिए use करता है।
00:03:27तो जब हम अपने JavaScript code में fs.read file जैसा कुछ call करते हैं,
00:03:31तो हम वास्तव में कंप्यूटर से पूछ रहे हैं,
00:03:34मैं इस file को disk से पढ़ना चाहता हूँ।
00:03:36लेकिन इससे पहले कि हम वहाँ पहुँच सकें,
00:03:38इसे पहले V8 से,
00:03:39या JavaScript code से V8 में जाना होता है।
00:03:42फिर यह Node C++ binding को pass करता है।
00:03:46यह फिर libuv को call करता है,
00:03:48और यह thread work और सभी तरह के overhead का भी जिक्र नहीं है।
00:03:52और सिर्फ तब libuv हमारे kernel को system call करता है disk से यह file वास्तव में प्राप्त करने के लिए।
00:03:58और जबकि ये सब हो रहा होता है,
00:04:00हमारे पास वह event loop होता है जो libuv use करता है ताकि हमारा बाकी JavaScript code still execute हो सके और इसी तरह।
00:04:06और यह model ठीक काम करता है।
00:04:08हम अभी भी Node का use कर रहे हैं, लेकिन यह optimal नहीं है।
00:04:13तो 2009 में वापस,
00:04:14जब Node को introduce किया गया था,
00:04:17हमारा hardware बहुत अलग दिखता था।
00:04:19सर्वर के पास शायद चार cores थे,
00:04:22limited memory था,
00:04:23और storage काफी slow था।
00:04:25Threads भी expensive थे,
00:04:27तो हर connection के लिए एक नया thread बनाना बस अच्छी तरह से scale नहीं होता था।
00:04:32तो उस समय के लिए Node का model बहुत अच्छा था क्योंकि हम एक thread का use करके हजारों connections को efficiently handle कर सकते थे।
00:04:40लेकिन 2025 में आगे बढ़ते हैं,
00:04:42हमारा hardware बहुत अलग दिखता है।
00:04:44अब हमारे पास सैकड़ों CPU cores हैं,
00:04:47terabytes की memory है,
00:04:48और storage 50 गुना तेज है।
00:04:51लेकिन हम अभी भी 2009 के आधार पर Node के model का use कर रहे हैं।
00:04:55यह अभी भी सबकुछ को उसी event loop से push कर रहा है।
00:04:59और फिर से, यह ठीक है।
00:05:00Node की architecture ठीक है जब सर्वर दिनों के लिए चलते थे।
00:05:04लेकिन आधुनिक समय में,
00:05:05हमारे पास अक्सर serverless functions होते हैं या हमारे पास dev servers होते हैं।
00:05:09ये सभी और भी short burst scripts होते हैं जिन्हें तेजी से start होना चाहिए और बहुत कम समय के लिए चलना चाहिए।
00:05:16तो इन environments में,
00:05:18startup का हर millisecond और हर data layer महत्वपूर्ण है क्योंकि वे सभी latency को add करते हैं।
00:05:24अब फिर से,
00:05:25जब आप अपना next app चलाते हैं,
00:05:29तो आप इसे Node पर चला रहे हैं।
00:05:34तो इसका मतलब है कि आपका app जो भी करता है,
00:05:36जैसे pages को render करना,
00:05:37assets को serve करना,
00:05:38responses को stream करना,
00:05:40वे सभी उन सभी layers से गुजरते हैं जो हमने अभी देखे थे।
00:05:43तो JavaScript से VA से Node में, सभी तरह की चीजें।
00:05:46और Next ने Node runtime को भी blocking के आधार पर performance को squeeze करने में एक incredible काम किया है।
00:05:57क्योंकि दिन के अंत में,
00:05:58ये सभी improvements अभी भी Node पर चलते हैं।
00:06:01तो जब आप एक dev server को spin up करते हैं या files को rebuild करते हैं,
00:06:05hot reloading,
00:06:06आप अभी भी उन runtime limits को hit कर रहे हैं।
00:06:09तो अगर हम वास्तव में तेजी से चलना चाहते हैं,
00:06:11तो हमें फ्रेमवर्क से परे देखना होगा।
00:06:13हमें एक level गहरा जाना होगा।
00:06:15हमें runtime को खुद rethink करना होगा।
00:06:18तो यहीं BUN आता है।
00:06:20BUN सिर्फ Node के ऊपर बनाई गई एक और layer नहीं है।
00:06:24यह एक बिल्कुल नया runtime है जो 2025 में हमारे पास hardware के लिए scratch से बनाया गया है।
00:06:33तो Node की तरह C++ में LibUV पर नहीं,
00:06:37BUN को Zig में बनाया गया है।
00:06:40और यह एक modern systems language है जो metal के बहुत करीब चलता है।
00:06:45तो JavaScript engine के लिए,
00:06:47BUN Apple के वाकई तेज JavaScript core engine का use करता है।
00:06:51और यह वाकई तेजी से spin करता है,
00:06:53मुख्य रूप से क्योंकि यह कुछ initialization optimizations को defer कर सकता है जो V8 जैसे engines करते हैं।
00:06:59और यह भी बस वाकई quickly चलता है,
00:07:01जो,
00:07:02फिर से,
00:07:02आधुनिक tasks के लिए perfect है जो हम आजकल dev servers,
00:07:06serverless environments के साथ use करते हैं,
00:07:08और ये shorter build scripts।
00:07:10core runtime खुद Zig में लिखा गया है।
00:07:13तो BUN APIs और सभी parts जो async I/O को handle करते हैं।
00:07:17तो जहाँ Node सभी async operations के लिए LibUV use करता है,
00:07:22जैसे files को read करना,
00:07:23network requests,
00:07:24और इसी तरह,
00:07:25BUN इन्हें direct system calls के रूप में operating system को implement कर सकता है क्योंकि यह Zig में लिखा है।
00:07:33अब network requests के लिए,
00:07:35हम useSockets use करते हैं,
00:07:36तो यह थोड़ा अलग है।
00:07:37लेकिन हम LibUV की जगह Zig का use करके abstraction की बहुत सारी layers को remove कर रहे हैं।
00:07:44तो अब अगर आप BUN runtime के साथ एक file को read करना चाहते हैं,
00:07:47तो यह अभी भी,
00:07:47निश्चित रूप से,
00:07:48आपके JavaScript code से जाता है।
00:07:49यह अब JSC engine को Zig में जाता है,
00:07:52जो फिर direct system call कर सकता है।
00:07:55तो फिर से,
00:07:56हमारे JavaScript code और actual operating system के बीच कम layers।
00:08:01और यहाँ नतीजा यह है कि startup से लेकर file access,
00:08:05HTTP servers,
00:08:06और इसी तरह सबकुछ इतना तेज महसूस होता है।
00:08:09लेकिन BUN सिर्फ परफॉर्मेंस के बारे में नहीं है।
00:08:12हम 100% Node compatible होने का भी लक्ष्य रखते हैं।
00:08:15तो हम यह सुनिश्चित करना चाहते हैं कि Node के सभी अपने APIs काम करें।
00:08:19लेकिन फिर यह भी tons of additional built-in APIs के साथ ship होता है,
00:08:24जैसे S3,
00:08:24SQL,
00:08:25या Squeel,
00:08:25जो भी आप कहना चाहें।
00:08:27Redis, hashing, एक shell, इतनी सारी चीजें।
00:08:30और अगर आपने कभी अन्य programming languages का use किया है,
00:08:34जैसे Go या Python,
00:08:35तो यह batteries-included approach आपके लिए बहुत परिचित है।
00:08:39लेकिन JavaScript developers के रूप में,
00:08:41हम सिर्फ यह माना हुआ हो गए हैं कि लगभग सबकुछ के लिए dependencies install करना है।
00:08:45मैं अपने लगभग सभी apps में password hashing use करता हूँ।
00:08:48लेकिन मुझे फिर भी हर बार dependency install करनी होती है।
00:08:52तो BUN इसे बदलता है।
00:08:54जो सामान आप लगभग हर समय use करते हो,
00:08:57वह बस runtime में ही बना हुआ है।
00:08:59यह बस global पर built है।
00:09:01और फिर से,
00:09:02ये सिर्फ surface-level wrappers नहीं हैं NPM dependency के ऊपर।
00:09:06ये वास्तव में Zig में बने हैं।
00:09:08तो ये modern hardware के लिए performance के लिए optimize किए गए हैं।
00:09:12उदाहरण के लिए, BUN के पास एक built-in SQL client है।
00:09:16तो आप सीधे Postgres,
00:09:18MySQL,
00:09:18और SQLite से एक single API का use करके connect कर सकते हैं।
00:09:23आपको कोई भी additional dependencies install नहीं करनी होंगी।
00:09:26और फिर से, यह सिर्फ कुछ NPM package को call करना नहीं है।
00:09:30यह वास्तव में सभी BUN है बस सीधे system से बात कर रहा है।
00:09:35और यह सिर्फ convenience नहीं है कि हमारे पास ये built in हैं।
00:09:38BUN के options आमतौर पर Node और NPM alternatives की तुलना में बहुत तेज भी होते हैं।
00:09:44उदाहरण के लिए,
00:09:45यहाँ,
00:09:45BUN.SQL Node पर MySQL 2 की तुलना में 11 गुना तेज है,
00:09:50जो बहुत अच्छा है।
00:09:51या आप BUN के S3 clients का use कर सकते हैं।
00:09:54और यह किसी भी S3-compatible storage के साथ out of the box काम करता है।
00:09:58तो Amazon S3,
00:09:59Super Base Storage,
00:10:00Cloudflare R2,
00:10:01आप कहते हो क्या।
00:10:03और फिर से, यह API भी incredibly fast है।
00:10:06तो यहाँ,
00:10:06हम देख सकते हैं कि यह Node पर AWS S3 SDK की तुलना में 6 गुना तेज है।
00:10:12अब निश्चित रूप से,
00:10:13आप अभी भी BUN runtime के साथ अपनी normal dependencies का use कर सकते हैं।
00:10:17आपको इन built-in APIs का use करना अनिवार्य नहीं है।
00:10:20लेकिन ये आपके bundle size को बहुत reduce करते हैं,
00:10:23क्योंकि हम अब ये dependencies add नहीं कर रहे।
00:10:25और यह NPM vulnerabilities में मदद करता है जो हमने पिछले महीने देखे थे,
00:10:30क्योंकि आपको उन्हें install नहीं करना पड़ता।
00:10:32और भी tons of APIs हैं।
00:10:33मैं अत्यधिक recommend करता हूँ कि आप docs को भी check करें।
00:10:37लेकिन BUN सिर्फ runtime के साथ ही नहीं आता।
00:10:40यह एक वाकई तेज package manager भी ship करता है जो YARN से 17 गुना तेज है,
00:10:47NPM से 7 गुना तेज है,
00:10:49और PNPM से 4 गुना तेज है।
00:10:51और अच्छी बात,
00:10:52आपको BUN runtime का use नहीं करना होगा BUN install को use करने के लिए।
00:10:55और यह बस-- आप BUN install को Node के साथ use कर सकते हैं।
00:10:58यह बस काम करेगा।
00:10:59तो आपको अपनी project के बारे में कुछ भी बदलना नहीं होगा।
00:11:03इसमें एक वाकई तेज built-in bundler और transpiler भी है।
00:11:06तो आप अपनी files को तुरंत serve और build कर सकते हैं।
00:11:09तो आपको Webpack, ESBuild, कोई extra setup की जरूरत नहीं है।
00:11:12और अच्छी बात यह है कि यह TypeScript और JSX को भी box से ही support करता है।
00:11:18यह एक वाकई तेज test runner भी है जो vTest से 14 गुना तेज है और जब हम 1,
00:11:23000 React tests को SSR'd करते हैं तो jest से 23 गुना तेज है।
00:11:26तो फिर से, आपको वाकई तेज tests मिलते हैं।
00:11:29आपको कुछ भी install नहीं करना होता।
00:11:31तो यह सब कुछ बहुत अच्छा लगता है,
00:11:33लेकिन हम BUN runtime को कैसे use कर सकते हैं?
00:11:35और next में, honestly, यह बहुत simple है।
00:11:38BUN install करने के बाद,
00:11:39आपको बस अपने start command या अपने dev command को update करना होगा और bun run --bun add करना होगा।
00:11:45बस यही।
00:11:46आप अब BUN runtime पर चल रहे हैं।
00:11:48अब आप सोच रहे हो सकते हैं, मुझे वह --bun की जरूरत क्यों है?
00:11:51जैसे, मैं पहले से ही bun run कह रहा हूँ।
00:11:54वह,
00:11:54फिर से,
00:11:55क्योंकि BUN वास्तव में node compatibility की परवाह करता है।
00:11:57तो आमतौर पर,
00:11:58अगर हम बस bun run next dev का use करते हैं,
00:12:02तो BUN का पता लगाएगा कि next CLI उस node shebang का use करती है।
00:12:07और उस स्थिति में,
00:12:07BUN ऐसा होगा,
00:12:08ठीक है,
00:12:08मैं समझता हूँ कि मुझे node का use करना होगा।
00:12:11तो फिर यह बस node को default में वापस करेगा,
00:12:13भले ही हमने bun run कहा था।
00:12:15लेकिन --bun flag के साथ,
00:12:16हम किसी तरह shebang को skip करने के लिए force कर रहे हैं और कहते हैं,
00:12:19ठीक है,
00:12:20हम बस bun runtime का use कर रहे हैं।
00:12:21तो बस किसी तरह की extra explanation के रूप में।
00:12:25तो अब इस command के साथ,
00:12:27bun को आपके next dev server को start करें।
00:12:29bundler खुद still next है।
00:12:31तो वह अभी भी, आप जानते हो, Turbo Pack है।
00:12:33मुझे लगता है Web Pack, Turbo Pack, अब यह default है।
00:12:35लेकिन अब सभी उसके नीचे का runtime,
00:12:37तो वह बात जो आपके JavaScript को execute कर रहा है,
00:12:40files को read कर रहा है,
00:12:41responses को serve कर रहा है,
00:12:43और इसी तरह,
00:12:43वह सब bun है।
00:12:44और क्योंकि bun को node compatible होने के लिए design किया गया है,
00:12:47आपको अपने code के बारे में कुछ भी बदलना नहीं चाहिए।
00:12:50या अपनी packages या अपनी middleware।
00:12:51सबकुछ अभी भी काम कर रहा होना चाहिए।
00:12:53अगर नहीं, तो यह भी bun में एक bug माना जाता है।
00:12:57यह 100% node compatible होना चाहिए।
00:12:59तो अगर आप इसे try कर रहे हैं,
00:13:00तो आप issues में run करते हैं,
00:13:02हमें बताइए।
00:13:02लेकिन आपको कुछ भी rewrite नहीं करना चाहिए।
00:13:05और अब जो आपका app bun के ऊपर चलता है,
00:13:07आपको bun के सभी built-in APIs की access मिलती है।
00:13:10तो उदाहरण के लिए,
00:13:11हम बस S3 client को use कर सकते हैं,
00:13:13सही है,
00:13:13किसी भी server function में,
00:13:14React server component में,
00:13:16और इसी तरह।
00:13:16तो हमें कोई भी dependencies install नहीं करनी होंगी।
00:13:18तो बस compare करने के लिए जो यह सामान्य रूप से Node के साथ दिखाई दिया होगा,
00:13:22आप देख सकते हैं कि bun के साथ,
00:13:24हमारे पास बहुत कम code है।
00:13:25हमारे पास कम dependencies हैं।
00:13:27और यह सभी अन्य S3 providers के साथ भी instantly compatible है।
00:13:32तो अगर आप Amazon S3 से Cloudflare R2 की तरह switch करना चाहते हैं,
00:13:36super base storage,
00:13:37सभी अन्य providers,
00:13:39यह super simple है।
00:13:40या एक और भी complete एक,
00:13:42हम S3,
00:13:42bun shell,
00:13:43और SQL को सीधे React server component में use कर सकते हैं।
00:13:47तो पहले,
00:13:48हम SQL के साथ database को query करते हैं image के लिए presign S3 URL को generate करने के लिए blog post को fetch करने के लिए,
00:13:54bun shell का use करें words की गणना करने के लिए।
00:13:57फिर से,
00:13:57कोई extra API layer या third party tools नहीं है जो bun call कर रहा है।
00:14:02Bun runtime को,
00:14:03database connections को,
00:14:05और shell को सभी natively SIG में handle करता है,
00:14:08metal के करीब।
00:14:10और फिर से, निश्चित रूप से, यह सिर्फ S3 SQL नहीं है।
00:14:12हमें bun run --bun को next dev के सामने add करके bun के सभी APIs की access मिलती है।
00:14:20लेकिन निश्चित रूप से,
00:14:21अब आप सोच सकते हैं,
00:14:22ठीक है,
00:14:22मैं Postgres का use नहीं कर रहा हूँ।
00:14:24मैं S3 का use नहीं कर रहा हूँ।
00:14:25मैं कोई भी crazy dependencies का use नहीं कर रहा हूँ,
00:14:27तो मुझे इसकी परवाह क्यों करनी चाहिए?
00:14:28जो बात मुझे BUN में ले गई,
00:14:30इससे पहले कि मैं join करता,
00:14:32honestly बस incredible DX थी।
00:14:34आप बस कोई भी JS,
00:14:35TS,
00:14:36TSX,
00:14:36JSX,
00:14:37कोई भी file को configuration के बिना run कर सकते हैं।
00:14:41यह बस काम करता है।
00:14:41आपको TSNode,
00:14:42Babel,
00:14:43SWC,
00:14:43और इसी तरह के बारे में सोचना नहीं होता।
00:14:46तो भले ही आप next का use नहीं कर रहे हैं,
00:14:48भले ही आप सिर्फ develop कर रहे हैं,
00:14:50आप एक quick build script चाहते हैं,
00:14:52बस bun run का use करो,
00:14:53बस इसे try करो,
00:14:54यह तुम्हारी जिंदगी को इतना बेहतर बनाता है क्योंकि आपको कोई configuration की जरूरत नहीं है।
00:14:59Bun भी bun x के साथ आता है।
00:15:01और यह bun का NPX का एक तरह का equivalent है।
00:15:04फिर से, आपको कुछ भी बदलना नहीं होता।
00:15:06आपको इसके लिए bun runtime का use नहीं करना होता।
00:15:08आप बस NPX को bun x से change कर सकते हैं।
00:15:11और आप तुरंत startup में improvements देखते हैं।
00:15:13उदाहरण के लिए,
00:15:15bun x create next step का use करना NPX create next step से 5 गुना तेज है।
00:15:20और फिर से, आपको इसके लिए bun runtime का use नहीं करना होता।
00:15:23यह बस बहुत तेज है।
00:15:25लेकिन निश्चित रूप से,
00:15:26bun install भी है,
00:15:27जो फिर से,
00:15:28आपको runtime को change नहीं करने की जरूरत नहीं है।
00:15:31यह सिर्फ आपके installs को इतना तेज बनाता है,
00:15:34basic next projects पर भी।
00:15:36अब स्पष्ट रूप से, locally bun को run करना एक बात है।
00:15:39लेकिन हम bun पर चलने वाले apps को कैसे deploy करते हैं?
00:15:42क्योंकि यह, निश्चित रूप से, एक पूरी तरह का नया runtime है।
00:15:46अब आप पहले से ही कई platforms जैसे render,
00:15:48railway पर bun पर Next.js का use कर सकते हैं,
00:15:51या Docker के साथ अपने app को containerize कर सकते हैं।
00:15:54लेकिन हम सभी Next.js developers हैं।
00:15:56आदर्श रूप से,
00:15:57हम Vercel को भी deploy करने में सक्षम होना चाहते हैं।
00:16:00तो स्वाभाविक रूप से,
00:16:02हमने Guillermo को kindly ask करते हुए tweet किया कि Vercel पर native bun support के लिए।
00:16:07और हमें बहुत जल्दी एक बहुत ही promising response मिली।
00:16:10और फिर कुछ हफ्तों बाद,
00:16:12bun support को कम से कम internally achieve किया जा चुका है।
00:16:15तो मैं बहुत excited हूँ कि native bun support Vercel में बहुत जल्द आएगा।
00:16:20और यह मतलब है कि आप-- [तालियाँ]
00:16:25Vercel में महान engineers को तालियाँ जो इसे संभव बनाई।
00:16:29लेकिन यह बहुत exciting है क्योंकि यह मतलब है कि हम अब बुन apps को Vercel पर किसी अन्य Next project की तरह आसानी से run कर सकते हैं।
00:16:37तो एक real world example भी।
00:16:39मैं यकीन नहीं हूँ कि आप स्क्रीन पर इसे देख सकते हैं।
00:16:41लेकिन Vercel पर bun को run करके एक HONO API को चलाना पहले से ही 30% drop या CPU drop देखा है।
00:16:49यह, निश्चित रूप से, एक अलग framework है।
00:16:50यह HONO API है।
00:16:52लेकिन यह वही runtime benefits हैं जो आप get करेंगे अगर यह एक server function,
00:16:56RSC,
00:16:56और इसी तरह होता।
00:16:57क्योंकि bun CPU और memory usage में बहुत कुछ बचाता है।
00:17:02अब हम,
00:17:02निश्चित रूप से,
00:17:03native bun support के लिए wait नहीं करना होगा अपने apps में इसका use करना शुरू करने के लिए।
00:17:06सबसे simple तरीका किसी तरह इसे use करना या incrementally adopt करना है।
00:17:11तो पहले,
00:17:11मैं सिर्फ bun install पर switch करने की recommend करता हूँ।
00:17:14अपने code base में कुछ भी बदलता नहीं।
00:17:16यह बस bun के वाकई तेज package manager का use करता है।
00:17:19साथ ही,
00:17:19अगर आप यह जानने में interested हैं कि bun install इतना ज्यादा तेज क्यों है,
00:17:22तो मैंने इस पर एक article लिखा हूँ ज्यादा समय पहले नहीं।
00:17:24मैं अत्यधिक recommend करता हूँ कि आप इसे check करें।
00:17:26यह बस-- आप जानते हो, हम steps को skip नहीं कर रहे।
00:17:29हम जो भी कर रहे हैं।
00:17:29यह systems engineering को कुछ हद तक explain करता है जो इसे इतना तेज बनाता है।
00:17:35अब bun install का use करने के बाद,
00:17:37फिर bun runtime का use करने की कोशिश करें।
00:17:39आप बस इसे locally bun run --bun के साथ use कर सकते हैं।
00:17:42अपने app को test करें।
00:17:42देखो कि सबकुछ काम करता है।
00:17:44यह करना चाहिए।
00:17:45अगर नहीं, तो हमें बताइए।
00:17:47और फिर lastly,
00:17:48आप किसी तरह incrementally bun के native APIs में move कर सकते हैं जहाँ यह समझ में आता है।
00:17:53आप,
00:17:53निश्चित रूप से,
00:17:54अभी भी ये NPM dependencies को mix and match कर सकते हैं।
00:17:57लेकिन सबसे अच्छी बात यह भी है कि यहाँ हर step reversible है।
00:18:00तो अगर आपने bun के native APIs में से एक का use किया है और यह काम नहीं किया,
00:18:04तो आप हमेशा बस node पर वापस switch कर सकते हैं।
00:18:06लेकिन यह definitely check करने लायक है।
00:18:08अब इस बात को खत्म करने से पहले,
00:18:10मैं बस bun में engineers की amazing team को एक बहुत बड़ा धन्यवाद कहना चाहता हूँ।
00:18:17ज्यादातर लोग Jared को जानते हो सकते हैं,
00:18:19लेकिन bun के पीछे एक पूरी team है जो हर रोज इतनी मेहनत करती है बun को और भी तेज,
00:18:23और भी stable,
00:18:24और उपयोग के लिए बहुत अधिक मजेदार बनाने के लिए।
00:18:27वे वास्तव में JavaScript के साथ संभव सीमाओं को push कर रहे हैं।
00:18:32तो next ने फिर से imagine किया कि हम वेब के लिए कैसे बनाते हैं,
00:18:35लेकिन bun इसे imagine किया कि क्या शक्ति देता है।
00:18:38मेरी बातों के लिए आने के लिए बहुत बहुत धन्यवाद,
00:18:40और मैं बहुत excited हूँ देखने के लिए कि आप bun और Next के साथ क्या build करेंगे।