스크립트
00:00:00आप गिनती में एक और नाम जोड़ सकते हैं क्योंकि एक और Rust रीराइट आ गया है, इस बार Vite dev
00:00:03सर्वर को Lovable टीम ने Rust में दोबारा लिखा है, जो कथित तौर पर चार गुना बेहतर मेमरी
00:00:07उपयोग और दो गुना तेज़ कोल्ड स्टार्ट देता है। तो चलिए आगे बढ़कर इस दावे की जांच करते हैं क्योंकि यह
00:00:12थोड़ा भ्रामक हो सकता है, और फिर देखते हैं कि क्या यह ऐसी चीज़ है जिस पर आपको भविष्य में स्विच करना चाहिए,
00:00:15और यह भी कि Vite के निर्माता क्या सोचते हैं कि इसका ओपन सोर्स के भविष्य के लिए क्या अर्थ है।
00:00:24तो जिस प्रोजेक्ट की मैं बात कर रहा हूँ उसे OJ यानी ऑरेंज जूस कहा जाता है, और विचार यह है कि यह एक
00:00:29Rust बाइनरी है जिसे मैं अपने मौजूदा Vite प्रोजेक्ट की तरफ पॉइंट कर सकता हूँ और यह बस इसे चला देता है। यह मेरी Vite
00:00:33कॉन्फिग पढ़ता है, यह अभी भी मेरे मौजूदा Vite प्लगइन्स चलाता है, लेकिन उनके नीचे का dev सर्वर, यानी फाइल
00:00:38वॉचर, मॉड्यूल ग्राफ, हॉट मॉड्यूल रीलोडिंग और React फास्ट रिफ्रेश सब कुछ Rust में दोबारा लिखा गया है।
00:00:44मजेदार बात यह है कि इसे rolldown और oxc का उपयोग करके किया गया है, जिनका उपयोग Vite खुद करता है और voidzero
00:00:49इन्हें मेंटेन करता है। अब इसे खुद आजमाने के लिए, मैंने एक TanStack ऐप बनाया ताकि देख सकूँ कि कोई अंतर है या नहीं
00:00:53इसे Vite dev या OJ dev के साथ चलाने के बीच। सतह पर, ऐसा लगता है कि वे लगभग एक जैसे काम करते हैं,
00:00:58और सब कुछ काम करता है जैसे सर्वर-साइड रेंडरिंग, हाइड्रेशन, सर्वर फंक्शन्स, फास्ट रिफ्रेश,
00:01:03डायनेमिक फाइल रूट्स, सर्वर रूट्स, Tailwind और एसेट इम्पोर्ट्स, लेकिन थोड़ा गहराई में जाने पर,
00:01:07मैंने कुछ छोटे अंतर देखे। पहला अंतर यहाँ फास्ट रिफ्रेश पर था। यदि मैं किसी फाइल को एडिट करता हूँ,
00:01:13तो यहाँ Vite काउंटर अपना स्टेट बरकरार रखता है, लेकिन OJ के तहत काउंट वापस शून्य पर रीसेट हो जाता है,
00:01:17जो दर्शाता है कि OJ केवल बदले हुए कंपोनेंट के बजाय पूरा रीलोड करता है। मैंने वास्तव में तय किया कि
00:01:22एक प्लेन React ऐप में इसी व्यवहार को टेस्ट करने की कोशिश करूँ जो TanStack Start नहीं था,
00:01:26और दिलचस्प बात यह है कि यह वास्तव में यहाँ काम करता हुआ लगा। तो यहाँ वही एडिट काउंट को समान रखता है,
00:01:30और यह पूरे पेज को अपडेट नहीं कर रहा है, इसलिए ऐसा लगता है कि यह असली हॉट अपडेट कर रहा है। तो मुझे नहीं पता कि
00:01:35TanStack Start और एक प्लेन React ऐप के बीच यह अंतर क्यों है, शायद यह उन
00:01:39एज केसेस में से एक है जिन पर उन्होंने अभी विचार नहीं किया है। दूसरा अंतर जो मैंने देखा वह था
00:01:42सर्वर फंक्शन के साथ। यह सर्वर फंक्शन ऐप के अंदर से देव सर्वर के पूरे प्रोसेस ट्री की मेमरी को मापता है,
00:01:46और Vite के तहत इस ऐप पर, यह दो प्रोसेस में लगभग 380MB है, और OJ के तहत,
00:01:53यह दो प्रोसेस में लगभग 320MB है। तो इस तरह के एक छोटे से ऐप पर, ऐसा लगता है कि मेमरी
00:01:59मेमोरी का इस्तेमाल लगभग एक जैसा ही है, जिसमें OJ बस थोड़ा सा आगे है। तो क्या इसका मतलब यह है कि यह प्रोजेक्ट
00:02:04बिलकुल बेकार है? खैर, नहीं, क्योंकि वास्तव में OJ को इसके लिए नहीं बनाया गया है। OJ वास्तव में
00:02:09बहुत बड़े ऐप्स पर सबसे अच्छा काम करता है। जब मैंने इसे 5000 कंपोनेंट्स वाले React ऐप पर एक स्क्रिप्ट के साथ टेस्ट किया जो
00:02:14प्रत्येक dev सर्वर कोड को चलाती है, असली Chrome ब्राउज़र में पेज खोलती है, घड़ी को रोक देती है जब
00:02:19सबसे गहरा कंपोनेंट DOM में होता है, और फिर उस पूरे प्रोसेस ट्री की मेमरी का सैंपल लेती है, तो OJ का नॉर्मल
00:02:24मोड डिफॉल्ट Vite की तुलना में पेज पेंट करने में लगभग 1.7 गुना तेज़ है, और लगभग एक-चौथाई
00:02:29मेमरी का उपयोग करता है। अब Vite के पक्ष में बात करें तो, Vite 8.1 ने bundled dev mode नाम का एक प्रायोगिक फीचर पेश किया था,
00:02:34और यदि आप उसे चालू करते हैं, तो Vite वास्तव में 1.18 सेकंड तक पहुँच जाता है, जो वास्तव में OJ के
00:02:40नॉर्मल मोड से थोड़ा तेज़ है, लेकिन यह आपको मेमरी में नहीं बचाता है। और OJ का एक बंडल मोड भी है, जिसे इस्तेमाल करने पर
00:02:45यह फिर से तेज़ हो जाता है, लगभग 0.89 सेकंड में, और मेमरी को Vite के लगभग एक-चौथाई हिस्से पर बनाए रखता है।
00:02:51इसलिए ऐसा लगता है कि OJ के कुछ वास्तविक मेमरी लाभ हैं, और यही कारण है कि Lovable ने
00:02:55यह प्रोजेक्ट बनाया है। Lovable प्रीव्यू एक असली Vite dev सर्वर चलाते हैं, और Lovable का कहना है कि वे प्रतिदिन लगभग
00:03:00दस लाख ऐसे सैंडबॉक्स चलाते हैं, और इस पैमाने पर, संसाधन की खपत
00:03:04वास्तव में मायने रखने लगती है। इसलिए Lovable ने OJ को ऐसे प्रीव्यू प्राप्त करने के लिए बनाया जो तुरंत शुरू हों और हल्के रहें,
00:03:09उस इकोसिस्टम को छोड़े बिना जो पहली जगह में ऐप को चालू रखता है।
00:03:13उन्होंने उस यूज़ केस यानी एजेंट्स के इर्द-गिर्द काफी शानदार डिज़ाइन निर्णय भी लिया। एडिट करते समय,
00:03:17एक व्यक्ति आमतौर पर एक समय में एक ही फाइल सेव करेगा, लेकिन एक एजेंट एक झटके में 10 या उससे अधिक फाइलें लिख सकता है,
00:03:22और Vite इनमें से प्रत्येक सेव को एक अपडेट के रूप में मानता, लेकिन OJ में, वॉचर,
00:03:26मॉड्यूल ग्राफ, कंपाइलर और हॉट अपडेट एक ही पाइपलाइन हैं, इसलिए एक ही झटके में किए गए बदलावों को एक अपडेट में मिला दिया जाता है।
00:03:32एक गेट भी है जिसे आप चालू कर सकते हैं जहाँ अपडेट्स को तब तक रोककर रखा जाता है जब तक कि एजेंट खुद
00:03:35किसी फ्लश एंडपॉइंट पर पोस्ट नहीं करता, ताकि प्रीव्यू केवल पूरा हुआ बदलाव ही लागू करे। आप देख सकते हैं कि यह
00:03:40Lovable के अपने यूज़ केस को हल करने के लिए एक बहुत ही विशिष्ट प्रोजेक्ट है, और Vite के निर्माता Evan You
00:03:45ने भी इसे स्वीकार किया। इस ट्वीट में उनका पहला बिंदु यह है कि यह एक बहुत ही प्रभावशाली प्रोजेक्ट है जो
00:03:49Lovable की अपनी समस्या को अच्छी तरह से हल करता है, लेकिन यह पूरी तरह से Vite का रीराइट नहीं है। यह सिर्फ dev सर्वर है,
00:03:54और यह Rolldown और oxc पर भी बना है, जिन्हें void0 मेंटेन करता है, इसलिए यह शायद ही उन्हें रिप्लेस कर रहा है।
00:04:00OJ में पार्सर, ट्रांसफॉर्मर और प्रोडक्शन बंडलर सभी void0 वाले हैं,
00:04:04Lovable ने बस उनके चारों ओर सर्वर लिखा है। आप मूल रूप से इसे इस तरह सोच सकते हैं कि Vite एक Node
00:04:08प्रोसेस है जो Rust को चलाता है, जबकि OJ एक Rust प्रोसेस है जो Rust को चला रहा है, जिसके बीच में एक लेयर
00:04:13JavaScript की है ताकि यह अभी भी Vite की प्लगइन API से बात कर सके। Evan फिर आगे बताते हैं
00:04:17कि OJ तेज़ होने का कारण यह है कि यह केवल एक ही प्रकार के ऐप का समर्थन करता है। OJ वास्तव में केवल
00:04:22React ऐप्स के साथ काम करता है, यानी वे जिन्हें Lovable जनरेट कर रहा है। दूसरी ओर Vite को
00:04:27हर फ्रेमवर्क, हर अजीब कॉन्फिग, इसके चारों ओर बने हर टूल का समर्थन करना पड़ता है, और यह जानबूझकर
00:04:31esbuild या React प्लगइन जैसी चीज़ों को अलग पैकेज के रूप में छोड़ देता है, ताकि आवश्यकता पड़ने पर आप उन्हें खुद जोड़ सकें।
00:04:36इसके बाद, वे बेंचमार्क में खामियों को भी उजागर करते हैं। ब्लॉग के Vite Coldstart में
00:04:40vite-plugin-checker शामिल है, जो बैकग्राउंड वर्कर में TypeScript चलाता है, लेकिन OJ वास्तव में
00:04:45उस प्लगइन का समर्थन नहीं करता है, इसलिए यह उस काम को पूरी तरह से छोड़ देता है। उन्होंने यह भी बताया कि Vite में, bundled dev
00:04:50mode के साथ, यह OJ के Coldstart के काफी करीब है, जो बिल्कुल वैसा ही है जैसा हमने अपने आंकड़ों में देखा था, लेकिन वे स्वीकार करते हैं
00:04:55कि OJ काफी कम मेमरी का उपयोग करता है, और Vite को शायद इसे सुधारने का लक्ष्य रखना चाहिए।
00:04:59इस ट्वीट में Evan का अंतिम बिंदु वह है जो मुझे सबसे दिलचस्प लगता है। ओपन सोर्स की गतिशीलता
00:05:03बदल रही है, AI के कारण किसी चीज़ को फिर से लागू करने की लागत घट गई है, इसलिए हम और अधिक
00:05:08देखने जा रहे हैं जिसे वे ओपन सोर्स टूल्स के अनुकूलित प्रोजेक्शन (tailored projections) कहते हैं, यानी एक ही डिपेंडेंसी,
00:05:13एक यूज़ केस में फिट होने के लिए एक कंपोनेंट की सीमाओं के तहत फिर से निर्मित। वे एक और उदाहरण के रूप में TanStack का redact देते हैं। एक संभावित
00:05:19भविष्य यह है कि मेंटेनर्स के पास हजारों साधारण PRs का तांता लगने के बजाय, हर कोई
00:05:23बस अपना खुद का फोर्क मेंटेन करे। उनका कहना है कि ईमानदारी से, वे आश्वस्त नहीं हैं कि यह एक अच्छी बात है, लेकिन वे
00:05:28सोचते हैं कि यह काफी संभव है कि कुछ वर्षों में यही होने वाला है। तो एक तरफ, ऐसे फोर्क
00:05:33मेंटेनर्स के लिए बहुत सारे साधारण PRs की तुलना में बेहतर हैं, लेकिन हम इकोसिस्टम के विखंडन (fragmentation) का जोखिम उठाते हैं। मुझे लगता है
00:05:39कि केवल समय ही बताएगा कि यह कैसे सामने आएगा, और ओपन सोर्स का भविष्य क्या होने वाला है।
00:05:43कुल मिलाकर, यह वास्तव में ऐसा टूल नहीं है जिसे Lovable के अलावा कोई और उपयोग करने जा रहा है, जब तक कि आप
00:05:47सैंडबॉक्स में लाखों Vite dev सर्वरों की समान समस्याओं का सामना नहीं कर रहे हों, और मेरा मतलब है,
00:05:52क्या आपने कभी ध्यान दिया है कि Vite आपके अपने लैपटॉप पर धीमा है या बहुत अधिक मेमरी का उपयोग कर रहा है? मैंने व्यक्तिगत रूप से
00:05:57नहीं दिया है, लेकिन यह निश्चित रूप से अभी भी एक शानदार प्रोजेक्ट है, और यह बहुत बढ़िया है कि उन्होंने ऐसा किया है,
00:06:01इसलिए मुझे कमेंट्स में बताएं कि आप इसके बारे में क्या सोचते हैं। जब आप वहाँ हों, तो सब्सक्राइब करें, और हमेशा की तरह,
00:06:04अगले वीडियो में मिलते हैं।
00:06:09अगले वीडियो में मिलते हैं।
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기