Vite, Rust और JavaScript टूलिंग का भविष्य | Better Stack Podcast एपि‍सोड 11

BBetter Stack
컴퓨터/소프트웨어창업/스타트업AI/미래기술

Transcript

00:00:00- तो V+ का अंतिम सार्वजनिक संस्करण संभवतः,
00:00:03यह इस्तेमाल में कुछ मजेदार जैसा महसूस होगा।
00:00:06- ये इवान यू हैं।
00:00:07- इवान यू।
00:00:09- इवान यू।
00:00:10- इवान यू!
00:00:10- मैंने Vue बनाया, मैंने Vite बनाया।
00:00:14अब मैं Voice Zero नाम की एक कंपनी चलाता हूँ।
00:00:16- Vite, Vite+ से कैसे अलग है?
00:00:19- आपका डेवलपमेंट अनुभव बिल्कुल वैसा ही होगा
00:00:21जैसा आज Vite का है।
00:00:22लेकिन अगर आप और आगे जाना चाहते हैं,
00:00:24तो यह हर कदम पर आपके लिए मौजूद है।
00:00:26- टीम और आप खुद AI का उपयोग कैसे कर रहे हैं?
00:00:28- हमने कुछ अनोखे प्रयोग करने शुरू किए,
00:00:30जैसे Angular कंपाइलर को Rust में पोर्ट करना।
00:00:32- React Server components पर आपके क्या विचार हैं?
00:00:34- मैं पहले दिन से ही इसे लेकर संशयी रहा हूँ।
00:00:36- आमतौर पर जब मैं किसी पॉडकास्ट की शुरुआत करता हूँ,
00:00:39तो मैं मेहमानों से अपना परिचय देने के लिए कहता हूँ।
00:00:40लेकिन मुझे लगता है कि अगर कोई इसे देख रहा है
00:00:42और वो आपको नहीं जानता, तो मुझे बहुत हैरानी होगी।
00:00:44मुझे लगता है कि आप बहुत प्रसिद्ध हैं।
00:00:46लेकिन हर किसी को पता होना चाहिए,
00:00:48या ज्यादातर लोगों को पता होना चाहिए कि आप कौन हैं।
00:00:49- उन्होंने कम से कम Vite या Vue के बारे में तो निश्चित रूप से सुना ही होगा।
00:00:53- हाँ, तो मैंने Vue बनाया, मैंने Vite बनाया।
00:00:57अब मैं Voice Zero नाम की कंपनी चलाता हूँ
00:00:59जहाँ हम और भी कई ओपन सोर्स प्रोजेक्ट्स पर काम करते हैं।
00:01:03वहाँ Rodeo, Vtest, OXC हैं।
00:01:07और हाँ, Vue और Vite शायद ज्यादा लोकप्रिय हैं,
00:01:11लेकिन Voice Zero के साथ हम जिन चीजों पर काम कर रहे हैं,
00:01:14वे भी काफी शानदार हैं।
00:01:15क्योंकि Rodeo एक Rust-आधारित बंडलर है।
00:01:18OXC यह पूरा Rust टूल चेन है जिसमें
00:01:22पार्सर से लेकर रिज़ॉल्वर, ट्रांसफॉर्मर,
00:01:25मिनीफायर आदि सब शामिल हैं।
00:01:28और OXC के ऊपर, हमारे पास OX Linter और OX Format हैं,
00:01:32जो एक ESLint संगत लिंटर है
00:01:35और एक Prettier संगत फॉर्मेटर है।
00:01:37और अभी कई चीजों पर काम चल रहा है, लेकिन हाँ।
00:01:41तो हम फिलहाल मुख्य रूप से ओपन सोर्स के बारे में बात करना चाहते हैं।
00:01:45- जरूर।
00:01:45चूंकि आप इतनी सारी चीजों पर काम कर रहे हैं,
00:01:47तो आप अपना समय कैसे बांटते हैं?
00:01:50- देखिए, मैं निजी तौर पर इन सभी
00:01:52प्रोजेक्ट्स के लिए कोड नहीं लिखता।
00:01:53सच तो यह है कि आजकल मैं बहुत कम कोड लिखता हूँ
00:01:56जब से मैंने कंपनी शुरू की है।
00:01:58कंपनी में कई ऐसे इंजीनियर्स हैं
00:02:01जो Rust में मुझसे कहीं बेहतर हैं
00:02:03और वे अब पूरी तरह से AI के मुरीद हो चुके हैं।
00:02:05तो यह आधा उनकी मेहनत और आधा Cloud Code या Codex का काम है
00:02:10जो बहुत सारा Rust कोड लिख रहे हैं।
00:02:12और मुझे कई DX (डेवलपर अनुभव) फैसलों पर
00:02:17निर्णय लेना होता है,
00:02:22तय करना होता है कि आगे हमें किस पर ध्यान देना है।
00:02:25और जाहिर है, प्रोडक्ट्स भी हैं
00:02:28कि हम इसे एक ऐसे प्रोडक्ट में कैसे बदलें
00:02:31जिससे पैसा कमाया जा सके,
00:02:32जिस पर हम अभी भी काम कर रहे हैं।
00:02:34हाँ, तो आजकल एक कंपनी चलाने के लिए
00:02:39वो सभी चीजें करनी पड़ती हैं।
00:02:41- नए ओपन सोर्स प्रोजेक्ट्स के लिए
00:02:43विचार कहाँ से आते हैं?
00:02:45क्या वे ज्यादातर आंतरिक जरूरतों से आते हैं
00:02:48जब आपको लगता है कि यह
00:02:49दूसरे लोगों की समस्याओं को भी हल कर सकता है?
00:02:53- दरअसल यह सब Vite से शुरू होता है, है ना?
00:02:56जब मैंने Vite बनाया, तो मैं बस इस पर प्रयोग कर रहा था।
00:03:01यह एक प्रोटोटाइप के रूप में शुरू हुआ था
00:03:03और फिर मुझे लगा, हमें एक बंडलर की जरूरत है।
00:03:07हमने इस पूरी तरह से अनबंडल
00:03:10नेटिव ESM देव सर्वर से शुरुआत की, ठीक है?
00:03:13सरल कोड के लिए वो विचार बहुत अच्छा रहा,
00:03:16लेकिन फिर जब हमने कुछ बड़ी डिपेंडेंसीज़ का उपयोग करना शुरू किया
00:03:18तो समझ आया कि यह सही से काम नहीं करेगा
00:03:21अगर आप सभी डिपेंडेंसीज़ को अनबंडल लोड करते हैं।
00:03:24उदाहरण के लिए, अगर आपके पास load SES जैसी चीज है,
00:03:26जिसमें लगभग 700 फाइलें हैं।
00:03:28तो हमें लगा, ठीक है,
00:03:30हमें डिपेंडेंसीज़ को बंडल करने के लिए कुछ चाहिए, है ना?
00:03:34उस समय Rollup, esbuild और Webpack थे।
00:03:41Webpack ESM आउटपुट नहीं देता, इसलिए उसका उपयोग नहीं कर सकते थे।
00:03:47तो मैंने Rollup को देखा और Rollup काफी धीमा है।
00:03:50esbuild की तुलना में यह बहुत धीमा है, है ना?
00:03:53यह Webpack से तेज है, लेकिन esbuild के मुकाबले धीमा है।
00:03:56इसलिए हमने डिपेंडेंसीज़ को प्री-बंडल करने के लिए esbuild का उपयोग किया,
00:03:59जो बेहद तेज है।
00:04:00और फिर हमने सारे सोर्स कोड को अनबंडल ESM के रूप में सर्व किया
00:04:02और उसने बहुत अच्छा काम किया।
00:04:04और फिर जब प्रोडक्शन की बात आई,
00:04:06तो हमने मूल रूप से सोचा,
00:04:08चलो प्रोडक्शन के लिए पूरे सिस्टम को
00:04:10बंडल करने हेतु esbuild का उपयोग करते हैं।
00:04:11फिर हमें एहसास हुआ कि चंक्स (chunks) को विभाजित करने के मामले में
00:04:14esbuild का नियंत्रण बहुत सीमित है।
00:04:17जो कि बड़े एप्लिकेशन बनाने के दौरान एक बहुत ही सामान्य जरूरत है
00:04:19क्योंकि आप नियंत्रण रखना चाहते हैं,
00:04:21जैसे कि मैं इन लाइब्रेरी डिपेंडेंसीज़ को
00:04:24एक वेंडर चंक में रखना चाहता हूँ, ताकि वे बेहतर तरीके से कैश हो सकें।
00:04:26मैं नहीं चाहता कि यह चंक कभी बदले, समझे?
00:04:28ताकि इसका हैश (hash) स्थिर रहे।
00:04:32भले ही मैं अपना सोर्स कोड बदल दूँ,
00:04:33उस चंक का हैश वही रहना चाहिए।
00:04:35ताकि जब भी यूजर्स वेबसाइट पर आएं,
00:04:38उन्हें वो चंक हमेशा कैश किया हुआ मिले।
00:04:39तो इस तरह के बहुत सारे ऑप्टिमाइजेशन हैं
00:04:41जिन्हें esbuild बिल्कुल भी अनुमति नहीं देता।
00:04:44उसका चंक बांटने का बस एक ही डिफ़ॉल्ट तरीका है
00:04:47और बस उतना ही।
00:04:49उसका प्लगइन सिस्टम भी कम लचीला है।
00:04:53ऐसा है कि अगर किसी एक प्लगइन ने तय कर लिया
00:04:56कि मैं इस फाइल को प्रोसेस करने वाला हूँ, तो बस हो गया।
00:04:59फिर कोई दूसरा प्लगइन उसे छू भी नहीं सकता।
00:05:02जबकि हम Rollup का काफी उपयोग कर रहे थे,
00:05:05हम Rollup के प्लगइन सिस्टम से परिचित थे।
00:05:08तो हमने अंत में यह किया कि,
00:05:10हम प्रोडक्शन बंडलिंग के लिए Rollup का उपयोग करेंगे,
00:05:13लेकिन देव प्री-बंडलिंग के लिए esbuild का।
00:05:15यह ऐसा था कि इस मेल में हर चीज ने वही किया
00:05:20जिसमें वो माहिर थी।
00:05:23और असल में, आज का Vite 7 भी अभी भी
00:05:26इसी कॉम्बिनेशन पर आधारित है।
00:05:27और यह बहुत से लोगों के लिए ठीक-ठाक काम करता है, है ना?
00:05:31लेकिन जाहिर है कि समस्याएं हैं क्योंकि esbuild
00:05:35Go में लिखा गया है और Rollup JavaScript में,
00:05:40जिसका मतलब है कि प्रोडक्शन बिल्ड
00:05:41आज भी RSPack जैसे पूरी तरह से Rust आधारित
00:05:43बंडलर्स की तुलना में काफी धीमा है।
00:05:47और देव सर्वर के लिए, esbuild और Rollup के
00:05:52प्लगइन सिस्टम अलग-अलग होने की वजह से,
00:05:55हम डेवलपमेंट के दौरान डिपेंडेंसीज़ पर
00:05:57प्लगइन्स का वही सेट लागू नहीं कर सकते,
00:05:59लेकिन प्रोडक्शन बिल्ड के दौरान
00:06:01वे डिपेंडेंसीज़ पर लागू होते हैं।
00:06:03और फिर कुछ बारीक व्यवहार संबंधी अंतर आ जाते हैं।
00:06:07जैसे जब आपके पास ESM और CJS का मिला-जुला ग्राफ हो,
00:06:10तो esbuild और Rollup इसे थोड़ा अलग तरह से संभालते हैं।
00:06:13उनके 'tree shaking' व्यवहार में भी अंतर होता है।
00:06:15तो हालांकि वे दोनों अच्छा काम करते हैं, है ना?
00:06:18हमने व्यवहार की इन विसंगतियों को ठीक करने के लिए पैच भी लगाए
00:06:22और वो सब किया।
00:06:22हमने चीजों को काम के लायक बनाया, लेकिन गहराई में हम जानते थे,
00:06:25कि ये दो अलग-अलग चीजें हैं जिन्हें हमने किसी तरह
00:06:29साथ में जोड़ दिया है, है ना?
00:06:31तो एक तो प्रोडक्शन बिल्ड को तेज बनाने के लिए
00:06:35और दूसरा देव और प्रोडक्शन बिल्ड को अधिक सुसंगत बनाने के लिए,
00:06:40सबसे अच्छा यही है कि एक ही बंडलर हो
00:06:42जो दोनों काम करे, है ना?
00:06:44लेकिन समस्या यह है कि esbuild तेज तो है,
00:06:47पर उसे बढ़ाना (extendable) बहुत आसान नहीं है।
00:06:50उसका कोडबेस पूरी तरह से Go में है।
00:06:54तो इवान वालेस, जो esbuild के लेखक हैं।
00:06:57जाहिर है वे एक जीनियस इंसान हैं
00:06:59और उन्होंने esbuild को बेहद तेज बनाया है,
00:07:02लेकिन अन्य लोगों के लिए इसे
00:07:05एक्सटेंड करना या फोर्क करना
00:07:07या इसके ऊपर एक लेयर बनाकर उसे मेंटेन करना आसान नहीं है।
00:07:10यह करना आसान नहीं है, है ना?
00:07:12और साथ ही इवान वालेस को उन चीजों के लिए मनाना
00:07:15बहुत मुश्किल है जो वो नहीं करना चाहते,
00:07:17क्योंकि उन्हें पैसे की जरूरत नहीं है और उन्हें परवाह नहीं है।
00:07:21तो हमें लगा, ठीक है, और Rollup के बारे में क्या?
00:07:27क्या हम Rollup को तेज बना सकते हैं, है ना?
00:07:28तो कुछ प्रयोग किए गए,
00:07:30लेकिन बुनियादी तौर पर Rollup JavaScript में लिखा गया है
00:07:33और JavaScript का मतलब है कि यह सिंगल-थ्रेडेड है।
00:07:36तो हमने वर्कर पोल और वर्कर्स में प्लग-इन्स जैसी चीजों की कोशिश की।
00:07:41Rollup के मेंटेनर ने इसमें एक Rust पार्सर,
00:07:47SWC पार्सर डालने की कोशिश की।
00:07:50उससे परफॉरमेंस में कोई खास सुधार नहीं हुआ
00:07:54क्योंकि जब आपके पास Rust और JS का मिला-जुला सिस्टम होता है,
00:07:57तो डेटा पास करने की एक लागत (cost) हमेशा जुड़ी रहती है।
00:07:59जैसे आप स्ट्रिंग्स के बड़े टुकड़ों को इधर-उधर भेज रहे हैं।
00:08:02अगर आपको मेमोरी क्लोन करने की जरूरत पड़ती है, तो यह और भी धीमा हो जाता है।
00:08:05तो पता चला कि Rust से मिलने वाला परफॉरमेंस लाभ,
00:08:09जब आपके पास सिर्फ Rust पार्सर हो
00:08:12लेकिन बाकी सब कुछ JavaScript में हो,
00:08:13तो वो लाभ डेटा पास करने की लागत के कारण बराबर हो जाता है।
00:08:16तो अंत में परफॉरमेंस लगभग वैसी ही रही, है ना?
00:08:19तो हमें लगा कि Rollup को बहुत ज्यादा तेज बनाना
00:08:23तकनीकी रूप से संभव नहीं है।
00:08:26तो एकमात्र विकल्प इसे फिर से लिखना ही था,
00:08:30एक ऐसा बंडलर लिखना जो खास तौर पर
00:08:33Vite के लिए डिजाइन किया गया हो और बहुत तेज हो, है ना?
00:08:37यहीं से यह सोचने की शुरुआत हुई कि,
00:08:40हमें क्या करना चाहिए?
00:08:42तो हमने अनिवार्य रूप से यह तय किया,
00:08:44मूल विचार Rollup को Rust में फोर्क करने का था।
00:08:48फोर्क नहीं, पोर्ट करना, ठीक है?
00:08:49हम Rollup को Rust में पोर्ट करना चाहते थे।
00:08:51इसीलिए इस प्रोजेक्ट का नाम Rolldown रखा गया।
00:08:53तो यह है Rollup, Rolldown।
00:08:54और शुरुआत एक सीधे पोर्ट के रूप में हुई थी,
00:08:58लेकिन हमें एहसास हुआ कि JavaScript में लिखा गया कोड
00:09:02सीधे Rust में पोर्ट करना इतना आसान नहीं है
00:09:06क्योंकि JavaScript बहुत गतिशील (dynamic) है।
00:09:08यह एक डायनेमिक भाषा है, है ना?
00:09:11भले ही आप TypeScript का उपयोग करें,
00:09:13आप फिर भी चीजों को जितना चाहें उतना म्यूटेट कर सकते हैं।
00:09:16और Rust मेमोरी को लेकर बहुत सख्त है।
00:09:19यह लाइफ साइकिल, ओनरशिप आदि को लेकर सख्त है।
00:09:23इसलिए आपको चीजों को JavaScript के मुकाबले
00:09:25काफी अलग तरह से स्ट्रक्चर करना पड़ता है।
00:09:27इसलिए मौजूदा JavaScript कोड को
00:09:29Rust जैसी भाषा में पोर्ट करना
00:09:31कभी भी सीधा काम नहीं होगा।
00:09:33यह लगभग इसे फिर से लिखने जैसा ही है।
00:09:35और हमने अंततः वास्तव में,
00:09:37हम दोनों दुनिया का सर्वश्रेष्ठ चाहते थे, है ना?
00:09:42Rollup अपने आप में एक बहुत ही हल्का कोर है।
00:09:45तो अगर आप Rollup को
00:09:47प्रोडक्शन के लिए तैयार एक प्रीसेट में बदलना चाहते हैं,
00:09:49तो यह वास्तव में काफी जटिल काम है
00:09:51क्योंकि आपको नोड रिज़ॉल्वर प्लगइन जैसी चीज चाहिए,
00:09:54क्योंकि नोड मॉड्यूल्स को रिज़ॉल्व करना कोई इन-बिल्ट फीचर नहीं है।
00:09:56इसे आपके प्लगइन में जोड़ना होगा।
00:09:58CommonJS मॉड्यूल्स को सपोर्ट करने के लिए आपको CommonJS प्लगइन जोड़ना होगा
00:10:03क्योंकि Rollup कोर केवल ESM आधारित है।
00:10:06और फिर आपको बस ढेर सारे प्लगइन्स जोड़ने पड़ते हैं
00:10:10जैसे define, inject, replace।
00:10:14इनमें से बहुत से फीचर्स ES build में इन-बिल्ट हैं,
00:10:17लेकिन Rollup में इनके लिए प्लगइन्स की जरूरत होती है।
00:10:20और सबसे खराब बात यह है कि JavaScript की दुनिया में इनमें से अधिकांश प्लगइन्स,
00:10:25एक एक्स्ट्रा फुल AST पार्स ट्रांसफॉर्म कोजेन के रूप में लागू होते हैं।
00:10:30तो हर प्लगइन वास्तव में पूरा काम करता है,
00:10:33जैसे पिछले प्लगइन से कोड लेना,
00:10:36उसे फिर से पार्स करना, ट्रांसफॉर्म करना,
00:10:38नया कोड और नया सोर्स मैप जेनरेट करना।
00:10:41और फिर आपको उन सभी सोर्स मैप्स को एक साथ मर्ज करना होता है।
00:10:43यही कारण है कि JavaScript बिल्ड सिस्टम धीमा और धीमा होता जाता है
00:10:46क्योंकि हर प्लगइन बस इसी चीज को बार-बार दोहरा रहा है।
00:10:49तो हमें लगा, ठीक है, हमें ये चीजें भी इन-बिल्ट चाहिए।
00:10:53तो हमने ES build जैसा दायरा रखा,
00:10:56लेकिन API का आकार Rollup जैसा, और यही Rolldown है, है ना?
00:11:01लेकिन Rolldown बनाने के लिए हमें लगा,
00:11:03हमें एक पार्सर चाहिए, हमें सभी ट्रांसफॉर्म्स चाहिए, है ना?
00:11:07हमें एक मिनीफायर चाहिए, हमें एक रिज़ॉल्वर चाहिए।
00:11:10तो हमें वो सब कैसे मिलेगा?
00:11:12और यहीं OXC काम आता है।
00:11:14OXC निम्न-स्तरीय भाषा टूल चेन का वो सेट है
00:11:17जो आपको यह सब देता है।
00:11:20तो OXC के लेखक उस समय ByteDance में काम कर रहे थे
00:11:25और मेरी काफी समय से इस प्रोजेक्ट पर नजर थी।
00:11:28तो बोरशिन, वो OXC के लेखक हैं
00:11:30और वे अब Voice Zero में हमारे VP of Engineering हैं।
00:11:33कंपनी की स्थापना के तुरंत बाद वे हमसे नहीं जुड़े थे।
00:11:36मैं उन्हें जोड़ने की कोशिश कर रहा था, लेकिन वे हिचकिचा रहे थे,
00:11:38जैसे पता नहीं क्या होगा,
00:11:39लेकिन हमने वैसे भी OXC के ऊपर Rolldown बनाना शुरू कर दिया था।
00:11:44हमें लगा, यह बहुत बढ़िया चीज है।
00:11:45मुझे विश्वास है कि यही सही रास्ता है,
00:11:47क्योंकि मैंने सभी उपलब्ध विकल्पों को देखा था, ठीक है?
00:11:51मुझे कुछ ऐसा चाहिए था जिसे जोड़कर बनाया जा सके (composable)।
00:11:54मुझे कुछ ऐसा चाहिए था जिसका टूल चेन का हर हिस्सा
00:11:57स्वतंत्र रूप से इस्तेमाल किया जा सके।
00:12:00मैं यह भी चाहता था कि यह बहुत ज्यादा तेज हो, है ना?
00:12:03तो हमने OXC और SWC की तुलना की।
00:12:06OXC का पार्सर SWC पार्सर की तुलना में
00:12:09लगभग तीन गुना तेज है जबकि दोनों ही Rust में लिखे गए हैं,
00:12:12क्योंकि डिजाइन से जुड़े ऐसे कई फैसले
00:12:15और बारीक तकनीकी विवरण थे
00:12:18जिनकी वजह से परफॉरमेंस में यह अंतर आया।
00:12:20मुख्य बात यह है कि बोरशिन कंपनी में शामिल होने से पहले
00:12:24ज्यादातर समय पार्सर और लिंकिंग परफॉरमेंस को
00:12:27लेकर बहुत बारीकी से काम कर रहे थे।
00:12:30और जैसे कि,
00:12:32OXC 'arena allocator' नाम की किसी चीज का उपयोग करता है,
00:12:34जो AST के लिए सभी मेमोरी आवंटन को
00:12:39मेमोरी के एक लगातार खंड (consecutive chunk) में रखता है।
00:12:41यह बस मेमोरी का एक बड़ा हिस्सा आवंटित कर देता है
00:12:43और सीधे उसमें AST डाल देता है।
00:12:45तो इससे मेमोरी खाली करने में कम समय लगता है।
00:12:50यह कुछ और दिलचस्प चीजों के द्वार भी खोलता है जो हमने की हैं
00:12:53और जिससे OXLint में तेज JS प्लगइन्स संभव हो पाए हैं,
00:12:57क्योंकि लगातार मेमोरी की वजह से हम
00:12:59मेमोरी के पूरे हिस्से को बिना क्लोन किए JavaScript को पास कर सकते हैं,
00:13:01और फिर JS साइड पर उसे डीसीरियलाइज कर सकते हैं।
00:13:05तो इसके बहुत सारे लाभ हैं,
00:13:06लेकिन उस समय मैं जब इस प्रोजेक्ट को देख रहा था,” तो
00:13:10मैं वाकई बहुत प्रभावित हुआ,
00:13:10और हमने इसके ऊपर Rolldown बनाने का फैसला किया
00:13:13और आखिरकार बोरशिन को साथ आने के लिए मना लिया।
00:13:16और अब कंपनी का दायरा अनिवार्य रूप से यह बन गया है
00:13:21कि हमारे पास यह वर्टिकल Rust स्टैक है
00:13:24जो एक पार्सर से शुरू होता है।
00:13:26यह बंडलिंग से लेकर Vite तक सब कवर करता है,
00:13:29और फिर हमारे पास Linter, Formatter, TestRunner भी हैं, ठीक है?
00:13:33तो हमारे पास एक पूरा टूल चेन है।
00:13:34और आगे हम जो कर रहे हैं,
00:13:37असल में हम इस पर काफी समय से काम कर रहे हैं,
00:13:40वो है इन सभी चीजों को एक सुसंगत पैकेज में पिरोना
00:13:43ताकि आपको केवल एक बेसिक ऐप चलाने के लिए
00:13:47पाँच अलग-अलग चीजें इंस्टॉल न करनी पड़ें, है ना?
00:13:50आपको छह-सात अलग-अलग
00:13:51कॉन्फ़िगरेशन फाइलों की भी जरूरत नहीं पड़ेगी।
00:13:55हम उन सभी को बस एक ही कॉन्फ़िगरेशन फाइल में डाल देते हैं,
00:13:57और उनके साथ मिलकर काम करने की गारंटी है
00:13:59क्योंकि वे सभी एक ही पार्सर,
00:14:02एक ही ट्रांसफॉर्म पाइपलाइन और एक ही रिज़ॉल्वर पर आधारित हैं।
00:14:05तो इसमें कुछ भी अप्रत्याशित नहीं होगा।
00:14:07उदाहरण के लिए, अगर आप Webpack और Jest का उपयोग करते हैं,
00:14:10तो आपको उनके रिज़ॉल्यूशन लॉजिक को अलग-अलग कॉन्फ़िगर करना पड़ता है
00:14:14क्योंकि वे बस एक ही चीज का उपयोग नहीं करते।
00:14:16तो हाँ, विजन वास्तव में यह है कि,
00:14:19चलो बस एक ऐसा वर्टिकल स्टैक बनाते हैं
00:14:22जो हर जगह एक समान रूप से काम करे।
00:14:25डेवलपमेंट के अनुभव को जितना संभव हो सके उतना सरल
00:14:29और तेज बनाएं, ठीक है?
00:14:30परफॉरमेंस एक बहुत बड़ी बात है।
00:14:32मैंने इसे एक तरह से मान ही लिया था,
00:14:34लेकिन आपने शायद वो ट्वीट्स देखे होंगे कि कैसे Rolldown
00:14:39Rollup से 20 गुना ज्यादा तेज है।
00:14:43OX Lint, ESLint से 50 से 100 गुना ज्यादा तेज है।
00:14:47OX Format, Prettier से 30 से 40 गुना ज्यादा तेज है।
00:14:51तो हमारा लक्ष्य वास्तव में इसे इतना संगत बनाना है
00:14:57कि आप बिना किसी बड़े बदलाव के माइग्रेट कर सकें,
00:15:00लेकिन आपको परफॉरमेंस में भारी उछाल मिले
00:15:04और अब आपका टेस्ट लूप, लिंट चेक
00:15:08और बाकी सब कुछ बहुत तेज और सुचारू होगा।
00:15:12और हाँ, इससे लोग
00:15:15तेजी से और ज्यादा ऐप्स बना पाएंगे।
00:15:17- पता है, मुझे यह बात बहुत अच्छी लगी कि कैसे यह बात
00:15:20'हमें Vue के लिए इस तरह के बिल्ड टूल की जरूरत है' से शुरू होकर,
00:15:22'ओह, अब मैं उस हिस्से को बेहतर बनाना चाहता हूँ' तक पहुँच गई।
00:15:24'अब मैं उस छोटे से हिस्से को भी सुधारना चाहता हूँ।'
00:15:25और हाँ, जैसा कि आपने कहा, आप वास्तव में
00:15:27पूरे वर्टिकल स्टैक के मालिक हैं।
00:15:29यह बहुत प्रभावशाली है और यह वाकई बहुत तेज है।
00:15:32मैं शुरू होने से पहले ही लड़कों को बता रहा था
00:15:33कि मेरी पिछली नौकरियों में से एक में,
00:15:35हमने एक पुराने (legacy) प्रोजेक्ट पर काम शुरू किया था
00:15:37और उसमें Webpack का इस्तेमाल होता था और बिल्ड होने में 50 मिनट लगते थे।
00:15:40मुझे नहीं पता था कि वहाँ क्या चल रहा था,
00:15:42लेकिन मैंने उनसे सबसे पहली बात यही कही थी कि,
00:15:43हमें इसे तुरंत Vue पर ले जाने की जरूरत है।
00:15:46क्योंकि CSS में जरा सा बदलाव करने पर भी,
00:15:47रीबिल्ड होने के लिए दो मिनट तक
00:15:49इंतजार करना पड़ता था।
00:15:49और मुझे लगा, यह ठीक नहीं है।
00:15:52हमें हॉट मॉड्यूल रीलोडिंग का उपयोग करना चाहिए।
00:15:54जैसे ही मैं फाइल सेव करूँ, बदलाव दिख जाना चाहिए।
00:15:57तो हाँ, Vue ने निश्चित रूप से इसमें मदद की।
00:15:59और मुझे लगता है कि जिस तरह से Vue
00:16:02आगे बढ़ा है और लोकप्रिय हुआ है, वो वाकई काबिल-ए-तारीफ है।
00:16:05मैंने देखा कि इसके लगभग 20 करोड़ NPM डाउनलोड्स
00:16:07हर महीने होते हैं, जो अविश्वसनीय है।
00:16:09यह-
00:16:10- हाँ, हमने अभी कुछ समय पहले ही हर हफ्ते 5 करोड़ का आंकड़ा पार किया है।
00:16:13- हाँ, यह तो दिमाग चकरा देने वाला है।
00:16:15- मैं उन 5 करोड़ के बारे में ही सोच रहा था।
00:16:19इसमें शायद थोड़ा बहुत योगदान उन
00:16:21'वाइब कोडेड' ऐप्स का भी होगा।
00:16:23जो बस एक बार इस्तेमाल कर फेंक देने वाले ऐप्स होते हैं।
00:16:26फिर भी, यह दिखाता है कि बहुत से लोग
00:16:29या शायद बहुत से AI एजेंट्स इसका इस्तेमाल कर रहे हैं।
00:16:33- मैं कहने ही वाला था कि Betaslack की
00:16:34इंजीनियरिंग टीम Vue की बहुत बड़ी प्रशंसक है।
00:16:36तो उनके यहाँ बैकएंड पर Rails और फ्रंट एंड पर Vue है।
00:16:40और उनके कुछ सवाल हैं जिन्हें मैं पॉडकास्ट के दौरान
00:16:42बातों के सिलसिले के हिसाब से पूछूँगा।
00:16:46लेकिन आपने बंडलिंग के बारे में कुछ जिक्र किया
00:16:48और उनका एक सवाल यह था कि,
00:16:49चूंकि वे Rails में 'import maps' का उपयोग करते हैं,
00:16:52तो आप बंडलिंग का भविष्य कहाँ देखते हैं?
00:16:54क्योंकि अगर आप import maps का उपयोग कर रहे हैं,
00:16:56तो आपको ज्यादा बंडल करने की जरूरत नहीं पड़ती।
00:16:57तो हाँ, आपको क्या लगता है यह किस दिशा में जा रहा है?
00:17:00- दरअसल Rolldown के डॉक्यूमेंटेशन में
00:17:02मेरा एक समर्पित पेज है,
00:17:04जिसका शीर्षक है,
00:17:07'हमें आज भी बंडलर्स की जरूरत क्यों है?'
00:17:10- क्या आपसे यह सवाल अक्सर पूछा जाता है?
00:17:13- हाँ, मेरा मतलब है कि DHH
00:17:16'नो बंडल, नो बिल्ड' के बारे में काफी मुखर रहते हैं।
00:17:18तो उस पर ध्यान देना ही पड़ता है।
00:17:20और तो और, 'import maps' एक हद तक काम करते हैं,
00:17:24लेकिन 'unbundled' सामान्य तौर पर एक ऐसी अवधारणा है
00:17:29जो केवल एक निश्चित पैमाने तक ही काम करती है।
00:17:35जैसे अगर आपका ऐप हजार मॉड्यूल्स से कम का है,
00:17:39तो आपका पूरा मॉड्यूल ग्राफ शायद
00:17:41कुछ सौ मिलीसेकेंड के भीतर लोड हो जाता है
00:17:43और वो पूरी तरह से स्वीकार्य है।
00:17:45और अगर आप जानते हैं कि आप उस सीमा के भीतर काम कर रहे हैं,
00:17:48तो यह वास्तव में बहुत अच्छा है।
00:17:50यह डिफ़ॉल्ट रूप से लेजी (lazy) है,
00:17:53जिसका मतलब है कि अगर आपके पास एक बड़ा ऐप है
00:17:56और उसका हर पेज अलग-थलग (siloed) है,
00:17:58तो आपके पास यह सब-मॉड्यूल ग्राफ होता है,
00:18:00जो काफी अच्छे से काम करता है।
00:18:01यही कारण है कि Vite डेवलपमेंट में काफी अच्छे से काम करता है।
00:18:05लेकिन यह हर समस्या का समाधान नहीं है
00:18:07क्योंकि हमने खुद Vite के साथ यह महसूस किया है
00:18:09और यही कारण है कि हम Rolldown में
00:18:12'full bundle mode' नाम की किसी चीज पर काम कर रहे हैं
00:18:15कि अनबंडल मोड की अपनी सीमाएं हैं,
00:18:18जैसे कि असली बाधा मॉड्यूल्स की संख्या होती है।
00:18:21तो ऐसे बहुत सारे ऐप्स हैं जहाँ वे,
00:18:25डेवलपमेंट के दौरान हजारों-हजारों मॉड्यूल्स
00:18:29लोड कर रहे होते हैं, ठीक है?
00:18:32आप 3000 मॉड्यूल्स तक लोड कर सकते हैं
00:18:33और वो आपके ब्राउज़र को जाम कर देगा।
00:18:36असली समस्या नेटवर्क लेवल पर आती है
00:18:38क्योंकि नेटिव ESM के साथ,
00:18:40आप हर मॉड्यूल को लाने के लिए एक HTTP रिक्वेस्ट भेज रहे हैं।
00:18:44और अगर आपका इम्पोर्ट ग्राफ काफी गहरा है,
00:18:46तो उसे पहले मॉड्यूल को वापस लाना पड़ता है
00:18:49और तब समझ आता है कि, ठीक है, मुझे इन अतिरिक्त मॉड्यूल्स की जरूरत है
00:18:52और फिर उन्हें लाना पड़ता है।
00:18:53और फिर उन्हें,
00:18:54जैसे आपको पहले इम्पोर्टिंग मॉड्यूल को इवैल्यूएट करने से पहले
00:18:57पूरे ग्राफ को पूरी तरह से खंगालना पड़ता है।
00:19:00तो अगर आप खराब नेटवर्क पर हैं,
00:19:04तो पहली चीज रेंडर करने से पहले ही
00:19:06कई नेटवर्क राउंड ट्रिप्स की संभावना बढ़ जाती है।
00:19:09और फिर अगर आपके पास हजारों मॉड्यूल्स हैं,
00:19:13तो नेटवर्क की वजह से स्थिति और भी खराब हो जाती है।
00:19:17यहाँ तक कि लोकल डेवलपमेंट में, Vite देव सर्वर में भी,
00:19:20अगर आपके पास 3000 से ज्यादा मॉड्यूल्स हैं,
00:19:23तो इसे लोकली लोड करने में एक या दो सेकंड का समय लग सकता है।
00:19:27तो कल्पना कीजिए कि नेटवर्क पर
00:19:29प्रोडक्शन में इसका क्या असर होगा, है ना?
00:19:31आप वाकई ऐसा नहीं चाहेंगे क्योंकि अगर आप इसे बंडल करते हैं,
00:19:35तो इसमें शायद सिर्फ 100 मिलीसेकेंड लगेंगे, ठीक है?
00:19:38तो यह एक तरह से मुफ़्त में मिलने वाला ऑप्टिमाइजेशन है
00:19:40जो आपको हमेशा अपनाना चाहिए
00:19:41जब आप एक निश्चित सीमा पार कर लेते हैं।
00:19:45मुझे लगता है कि बंडलिंग और बिल्ड टूल्स से बचने का मुख्य तर्क
00:19:47यह है कि लोग टूल्स को कॉन्फ़िगर करते-करते थक गए हैं, है ना?
00:19:52उन्हें शायद बग्स मिले होंगे,
00:19:55कॉन्फ़िगरेशन से जुड़ी ऐसी समस्याएं आई होंगी जिन्हें वे सुलझा नहीं पाए।
00:19:56और क्योंकि Webpack ने इसे इतना जटिल बना दिया था,
00:20:01तो हर कोई बस यही सोचने लगा,
00:20:04जब आप बंडलर कॉन्फ़िगर करने के बारे में सोचते हैं,
00:20:06तो लगता है कि 'यह मेरा काम नहीं है, मैं यह नहीं करना चाहता', है ना?
00:20:08तो मुझे लगता है कि लोगों के मन में बस एक चिढ़ पैदा हो गई है,
00:20:11जब भी वे 'बिल्ड स्टेप' के बारे में सुनते हैं,
00:20:14उन्हें लगता है कि 'यह बुरा है, मैं इससे बचना चाहता हूँ', ठीक है?
00:20:16तो एक तरह से, हम इन टूल्स के जरिए जो करना चाहते हैं वो यह है कि,
00:20:19हम इन कॉन्सेप्ट्स को बहुत सरल बनाना चाहते हैं,
00:20:22और बड़े जटिल ऐप्स के लिए यह कभी भी सीधा नहीं होने वाला, है ना?
00:20:24लेकिन हम इसे एक नए ऐप के लिए इतना सरल बनाना चाहते हैं
00:20:28कि अगर आपका ऐप बहुत ज्यादा जटिल नहीं है,
00:20:32तो आपको वास्तव में इसके बारे में ज्यादा सोचने की जरूरत न पड़े।
00:20:34तो आपको बस यह कहने में सक्षम होना चाहिए, 'ठीक है, यह ऐप शुरू करो',
00:20:37'यह Vite का उपयोग कर रहा है और मुझे पता है कि सब कुछ शानदार होगा।'
00:20:41तो हकीकत में, मैं ऐसे लोगों को जानता हूँ, वहाँ एक कम्युनिटी जैम है
00:20:45जिसे Ruby Vite, Vite Rails या ऐसा ही कुछ कहते हैं
00:20:48जो Rails में Vite को काफी अच्छे से काम करने लायक बना देता है।
00:20:50मुझे लगता है कि 'नो बिल्ड' सेटअप के अपने फायदे हैं, है ना?
00:20:55इससे आपको सुकून मिलता है क्योंकि आप जानते हैं,
00:20:59कि आप बहुत सी डिपेंडेंसीज़
00:21:05और उन अनिश्चितताओं से बच सकते हैं जो चीजों को बिगाड़ सकती हैं।
00:21:12मुझे लगता है कि कुछ लोगों का बिल्ड सिस्टम से
00:21:14भरोसा उठने की वजह यह भी है कि उन्हें लगता है,
00:21:17कि हमेशा कुछ न कुछ गलत होगा ही।
00:21:20डिपेंडेंसी अपग्रेड करते ही बिल्ड टूट जाएगा, आप जानते ही हैं,
00:21:23वे वास्तव में इन सबसे बचना चाहते हैं, जो कि आकर्षक लगता है।
00:21:26लेकिन मेरा मानना है कि अंततः,
00:21:29अगर तकनीक पर्याप्त रूप से अच्छी और स्थिर है, है ना?
00:21:33तो आप हमेशा अपने यूजर्स के लिए बेहतरीन UX चाहते हैं
00:21:36और पूरी तरह से अनबंडल होने का मतलब है कि आपको अपने
00:21:37एप्लिकेशन के आकार की एक बहुत ही सीमित सीमा के भीतर रहना होगा।
00:21:41आपको ऑप्टिमाइजेशन की भी चिंता करनी होगी,
00:21:45क्योंकि आपको यह सोचना होगा कि,
00:21:48कहीं मैं किसी खास पेज पर गलती से बहुत ज्यादा चीजें तो
00:21:52इम्पोर्ट नहीं कर रहा हूँ, है ना?
00:21:54मैं अपने मॉड्यूल्स को समझदारी से कैसे कैश करूँ?
00:21:57मेरा मानना है कि अनबंडल Rails के साथ भी,
00:22:01मॉड्यूल्स को सही तरह से कैश करने के लिए उन्हें स्टैम्प करने हेतु
00:22:03अभी भी प्री-प्रोसेस जैसे किसी स्टेप की जरूरत पड़ती ही है।
00:22:06तो अनिवार्य रूप से आपको चीजों को सुचारू रूप से चलाने के लिए
00:22:08ऑप्टिमाइजेशन पर ध्यान देना ही होगा।
00:22:11मैं कहूँगा कि यह निश्चित रूप से काफी सारे
00:22:15मामलों में काम करता है, लेकिन यह कोई,
00:22:18यह हर तरह के उपयोग के मामले के लिए नहीं है।
00:22:21और कुछ लोग वास्तव में बहुत बड़े ऐप्स बनाते हैं, है ना?
00:22:24जिनमें बहुत सारे फीचर्स होते हैं।
00:22:29तो आप बस उन्हें अनबंडल होने के लिए मजबूर नहीं कर सकते
00:22:31और फिर उन्हें परफॉरमेंस की ऐसी स्थिति में नहीं छोड़ सकते
00:22:35जिसे सुधारना नामुमकिन हो।
00:22:37- तो उन लोगों के लिए जो इससे बहुत ज्यादा परिचित नहीं हैं,
00:22:39Vite, Vite+ से कैसे अलग है?
00:22:42और इससे लोगों को क्या फायदा होगा?
00:22:45- तो Vite+, अभी हम एक छोटे से बदलाव (pivot) से गुजर रहे हैं
00:22:49कि इस समय Vite+ को वास्तव में क्या होना चाहिए।
00:22:54विचार यहाँ यह है कि अगर आप
00:22:57JavaScript डेवलपमेंट में बिल्कुल नए सिरे से कदम रख रहे हैं,
00:23:02जैसे कि आप इस क्षेत्र में एकदम नए हैं,
00:23:06आपके पास एक नई मशीन है जिसमें कभी कुछ इंस्टॉल नहीं किया गया।
00:23:11तो आप 'जीरो' से एक चालू ऐप तक कैसे पहुँचते हैं,
00:23:14जिसमें हॉट मॉड्यूल प्लेसमेंट, सभी बेहतरीन तरीके,
00:23:17लिंटिंग, फॉर्मेटिंग, टेस्टिंग, सब आपके लिए पहले से तय हो, है ना?
00:23:21अभी यह सब सीखने के लिए बहुत कुछ है।
00:23:25जैसे सबसे पहली चीज जो आपको सीखनी होगी वो है,
00:23:28Node.js क्या है?
00:23:33इसे मैं कैसे इंस्टॉल करूँ?
00:23:36Node वर्जन मैनेजर क्या होता है?
00:23:38मुझे कौन सा पैकेज मैनेजर इस्तेमाल करना चाहिए?
00:23:39मुझे कौन सा बिल्ड टूल इस्तेमाल करना चाहिए?
00:23:40मुझे कौन सा लिंटर इस्तेमाल करना चाहिए?
00:23:42आपको इन सभी सवालों के जवाब ढूंढने पड़ते हैं।
00:23:44हम इन सभी सवालों को खत्म करना चाहते हैं।
00:23:45जैसे हम आपको एक सुविचारित (opinionated) शुरुआती बिंदु देते हैं
00:23:47और यह ऐसा है कि,
00:23:49आपको Node.js इंस्टॉल करने की भी जरूरत नहीं है, समझे?
00:23:50तो हम Vite+ के साथ काम करने के इस नए तरीके
00:23:52पर प्रयोग कर रहे हैं, जैसे curl,
00:23:54HTTPS vplus.dev इंस्टॉल पाइप बैश।
00:23:57और फिर VP dev, VP new, और आपके पास एक नया प्रोजेक्ट होगा
00:23:59और फिर आप VP dev करेंगे और आपके पास
00:24:03चीजों का एक पूरा सेट तैयार होगा।
00:24:08आपके पास लिंटर है, फॉर्मेटर है,
00:24:15टेस्ट रनर, बंडलर, आप इसका उपयोग
00:24:17मोनो रेपो (mono repo) तैयार करने के लिए भी कर सकते हैं।
00:24:21इसमें लाइब्रेरी बंडलिंग भी है।
00:24:25हम इसमें 'link stage' जैसी इन-बिल्ट चीजें भी जोड़ने की योजना बना रहे हैं,
00:24:28जो आपके चेंज लॉग (change log) को मैनेज करेंगी।
00:24:31अगर आप बड़ी मोनोरेपो लाइब्रेरीज़ पर काम कर रहे हैं,
00:24:32और फिर 'VP run' नाम की भी एक चीज है
00:24:39जो एक रनर है, बिल्कुल pnpm run की तरह,
00:24:41लेकिन यह थोड़ा ज्यादा उन्नत है,
00:24:44एक तरह से NX जैसा जहाँ यह समझ सकता है
00:24:49कि आपके कामों (tasks) को चलाने का सही क्रम क्या है
00:24:52और उन्हें समझदारी से कैश भी कर सकता है।
00:24:57हालांकि यह वैकल्पिक (opt in) है।
00:24:59तो यह चीजों का एक पूरा सेट है, जिसे आप जानते हैं,
00:25:03अगर आपको इन अतिरिक्त चीजों की जरूरत नहीं है,
00:25:04तो आप इसे सामान्य Vite की तरह ही इस्तेमाल कर सकते हैं, है ना?
00:25:07आपका डेवलपमेंट अनुभव बिल्कुल वैसा ही होगा
00:25:11जैसा आज Vite का है।
00:25:13लेकिन अगर आप और आगे जाना चाहते हैं,
00:25:17एंटरप्राइज लेवल के प्रोडक्शन के लिए तैयार
00:25:18मोनोरेपो तक जाना चाहते हैं, तो यह हर कदम पर आपके लिए मौजूद है।
00:25:20और साथ ही, क्योंकि यह उन सभी
00:25:24आजमाई हुई तकनीकों पर बना है
00:25:27जिन्हें लोग पहले से ही ऐसी स्थितियों में इस्तेमाल कर रहे हैं।
00:25:31तो यही वो चीज है जिसे हम पेश करना चाहते हैं, ठीक है?
00:25:33तो हम बहुत से मौजूदा यूजर्स को
00:25:35अपनी ओपन सोर्स पेशकशों की ओर ला रहे हैं,
00:25:39जैसे लोग Webpack से Vite पर माइग्रेट कर रहे हैं,
00:25:44वे ESLint से OXLint पर जा रहे हैं।
00:25:47हम उम्मीद करते हैं कि Vite+ एक समाधान बने कि,
00:25:48अगर मैं JavaScript में कदम रख रहा हूँ तो मुझे क्या करना चाहिए?
00:25:52शुरुआत करने का सबसे तेज़ और सरल तरीका क्या है?
00:25:54मैं उस सवाल का जवाब देना चाहता हूँ
00:25:57और इसे AI के साथ बहुत अच्छी तरह से काम करने लायक भी बनाना चाहता हूँ।
00:26:00- तो क्या कंपनी का लक्ष्य यही है,
00:26:02मुझे लगता है कि बहुत से लोग तब डर जाते हैं जब वे सुनते हैं
00:26:05कि ओपन सोर्स प्रोजेक्ट्स के पीछे कोई कंपनी है
00:26:07क्योंकि आप शायद कुछ फीचर्स को पैसे के पीछे (paywall) रख सकते हैं
00:26:11लेकिन क्या आपका लक्ष्य हमेशा की तरह यही है कि,
00:26:14जो Vite+ कर सकता है वो आप खुद भी कर सकें।
00:26:15बस उसमें बहुत सारी कॉन्फ़िगरेशन करनी पड़ती है
00:26:17और Vite+ एक तरह से सुविधा के लिए है
00:26:20जो सब कुछ एक साथ पेश करता है, जैसा कि आपने कहा।
00:26:23तो आप कभी किसी फीचर को 'पेवॉल' नहीं करेंगे।
00:26:25- हाँ, तो हमने Vite+ की लाइसेंसिंग के
00:26:26बारे में एक विचार साझा किया था, ठीक है?
00:26:29हमने कहा था, ठीक है, अगर आपकी कंपनी
00:26:31एक निश्चित स्तर से ऊपर है, तो आपको इसके लिए भुगतान करना होगा।
00:26:34वो सोच अब बदल रही है
00:26:37क्योंकि हम बहुत सी इच्छुक कंपनियों से बात कर रहे हैं
00:26:39और बस यह देखने की कोशिश कर रहे हैं कि इसे ज्यादा लोगों तक पहुँचाने
00:26:41और वैल्यू क्रिएट करने के बीच सही संतुलन क्या होगा
00:26:44ताकि हम भी आगे बढ़ सकें और टिके रह सकें, है ना?
00:26:46मुझे लगता है कि हम उस सीमा को काफी ऊपर ले जाएंगे।
00:26:50ताकि केवल कंपनियों की एक बहुत छोटी श्रेणी को ही
00:26:53इसके लिए भुगतान करना पड़े।
00:26:56तो अधिकांश यूजर्स इसका मुफ़्त में आनंद ले सकेंगे
00:27:00और साथ ही क्योंकि हमारे पास,
00:27:02हम कुछ ऐसे विचारों पर काम कर रहे हैं जो सर्विस की तरह ज्यादा हैं
00:27:07बजाय इसके कि सिर्फ फीचर्स के लिए पैसे लिए जाएं, है ना?
00:27:11तो एक ऐसी सर्विस जो Vite+ के साथ मिलकर काम करे
00:27:14जो एक तरह से कोड की क्वालिटी में सुधार करे
00:27:17और आपके कोड की क्वालिटी पर नजर रखे
00:27:20और आपको सुझाव या टिप्स दे,
00:27:25जैसे आपको कुछ चीजों को बेहतर बनाने में मदद करे।
00:27:27क्योंकि बहुत सारा ऐसा 'डोमेन नॉलेज' है
00:27:31जिसे अब हम AI एजेंट्स के जरिए बड़े पैमाने पर उपलब्ध करा सकते हैं।
00:27:35तो हम उसी दिशा में आगे बढ़ने की कोशिश कर रहे हैं।
00:27:37- ठीक है, मैं यह भी सोच रहा था कि,
00:27:39क्या Vite+ सब कुछ आसान बना रहा है,
00:27:41क्या आपको लगता है कि AI मौजूदा समाधानों के साथ ऐसा कर सकता है
00:27:44या क्या आपको लगता है, क्या आपके पास ऐसा कोई अनुभव रहा है
00:27:48जहाँ आपने AI से लिंटर, बिल्ड और सब कुछ का फॉर्मेट
00:27:51एक साथ जोड़ने के लिए कहा हो,
00:27:53क्या आपको लगता है कि यह (A) अपनी ट्रेनिंग डेटा की वजह से
00:27:56पुरानी तकनीक पर निर्भर रहेगा और सब कुछ गड़बड़ कर देगा?
00:28:00- तो हम देखते हैं कि AI से तैयार बहुत सारे ऐप्स
00:28:02आज भी Vite 6 जैसी पुरानी चीजों का उपयोग कर रहे हैं, उदाहरण के लिए, है ना?
00:28:05क्योंकि एक बड़ी बात यह है कि जब हम नया वर्जन रिलीज करते हैं,
00:28:07जब हम नए फीचर्स लाते हैं, तो मॉडल्स को
00:28:09उस डेटा पर ट्रेन होने में समय लगता है, समझे?
00:28:13मॉडल्स हमेशा ताजा खबरों
00:28:17और तकनीक से पीछे ही रहेंगे, तो हम जो कुछ करना चाहते हैं वो ये है
00:28:20जैसे कि अगर हम Vite+ का नया वर्जन लाते हैं,
00:28:26तो यह आपको देगा, सबसे पहले,
00:28:29यह अपनी खुद की एजेंट स्टाइल MD और स्किल्स के साथ आएगा।
00:28:31तो जब आप Vite+ अपग्रेड करेंगे, तो यह बस अपग्रेड हो जाएगा,
00:28:34यह आपके एजेंट की MD में उससे संबंधित हिस्से को पैच कर देगा
00:28:37और उन स्किल्स से जोड़ देगा जिन्हें
00:28:41आपके NPM पैकेज में अपडेट किया जा रहा है।
00:28:44और फिर यह भी है,
00:28:47हम आपको एक ऐसा प्रॉम्प्ट दे सकते हैं जो आपको बताए,
00:28:50अगर आप इस वर्जन से इस वर्जन पर अपग्रेड करना चाहते हैं,
00:28:54तो यह प्रॉम्प्ट आपके एजेंट को इसे सुचारू रूप से करने में मदद करेगा।
00:28:58तो इसमें से बहुत कुछ तो
00:29:00टूलिंग के रचनाकारों की ओर से ही आना होगा, है ना?
00:29:05क्योंकि आप, एक चीज जो हमने गौर की है
00:29:08वो ये कि हमारे पास OX Linter, OX format और Vtest हैं,
00:29:10वे OpenClaw में इस्तेमाल हो रहे हैं, ठीक है?
00:29:13और OpenClaw एक बहुत ही अजीब (crazy) कोडबेस है।
00:29:17इसमें JavaScript की लगभग 54,000 लाइनें हैं
00:29:19और यह बहुत तेज गति से आगे बढ़ रहा है।
00:29:22और उसका लेखक बिना पढ़े ही चीजों को मर्ज कर रहा है।
00:29:26और इसमें बहुत सारी ऐसी चीजें हैं
00:29:29जिनका कोई मतलब नहीं बनता।
00:29:31तो हम उन PRs को देख रहे हैं जो OX Linter को अपग्रेड या
00:29:34इसे अपनाने की बात करते हैं।
00:29:36वहाँ बस ऐसे विकल्प (options) दिए गए हैं जिनका कोई वजूद ही नहीं है।
00:29:40और हमें लगता है, रुको, हमारे पास ये विकल्प नहीं हैं,
00:29:43हमें इन्हें बनाना होगा।
00:29:45और फिर जब यह टाइप चेकिंग कर रहा होता है,
00:29:46तो आप बस टाइप चेकिंग को ठीक कर देते हैं।
00:29:51ठीक है, मैं इस नियम को बंद कर रहा हूँ।
00:29:54ताकि टाइप पास हो जाए।
00:29:57तो ऐसा है कि अगर आप गार्डरेल्स नहीं देंगे,
00:29:59तो AI शॉर्टकट अपनाएगा, है ना?
00:30:00और ज्यादा महत्वपूर्ण बात यह है कि पीटर,
00:30:04जो OpenClaw के लेखक हैं,
00:30:06वे कोई TypeScript डेवलपर नहीं हैं।
00:30:07उन्होंने इसे करने के लिए बस TypeScript को चुना।
00:30:09तो वे टूलिंग एक्सपर्ट नहीं हैं।
00:30:12उन्हें इस क्षेत्र में अनुभव नहीं है।
00:30:15AI ने उनकी मदद की।
00:30:18लेकिन AI द्वारा इस्तेमाल किए जाने वाले टूल्स के लेखक के तौर पर,
00:30:20हमने गौर किया कि यह कहाँ पीछे रह जाता है।
00:30:22और ऐसा है कि, ठीक है, अगर आप हमारे बिना
00:30:25बताए यही करते रहे,
00:30:26तो तीन महीने में आपका कोड बिखर जाएगा।
00:30:29तो हाँ, हमें लगता है कि AI के इस दौर में
00:30:30हम यही वैल्यू दे सकते हैं कि,
00:30:35आप बिना चीजें बिगाड़े कैसे तेजी से काम कर सकते हैं?
00:30:38आप AI के साथ तेजी से फीचर्स कैसे भेजते रह सकते हैं?
00:30:41क्योंकि कोड भेजने की गति
00:30:44भारी मात्रा में बढ़ रही है क्योंकि अब एजेंट्स हैं, है ना?
00:30:46लोग अब पहले के मुकाबले कहीं ज्यादा तेजी से फीचर्स भेज सकते हैं।
00:30:50लेकिन क्या इन सभी फीचर्स का सही से रिव्यु किया गया है?
00:30:54क्या वे सब, आप जानते ही हैं, जब आप दिन में 20 PRs मर्ज करते हैं,
00:30:58तो क्या कोडबेस अभी भी वैसा ही है,
00:30:59जैसा उसे मेंटेन किया जाना चाहिए?
00:31:03कोड की सेहत बहुत ही अस्थिर होती है।
00:31:06तो आपको समय-समय पर रुक कर
00:31:11वैसा ही करना पड़ता है जैसा हम इंसानी डेवलपमेंट में करते हैं, है ना?
00:31:14आप कुछ समय तक फीचर्स भेजते हैं,
00:31:19फिर आपको रुककर सोचना पड़ता है कि,
00:31:22ठीक है, हमें चीजों को साफ करने की जरूरत है।
00:31:25हमें जमा हुए 'टेक्निकल डेट' (tech debt) को खत्म करने की जरूरत है।
00:31:26तो AI एजेंट्स के साथ, हम अब बहुत तेजी से काम कर रहे हैं।
00:31:30हम टेक्निकल डेट भी बहुत तेजी से जमा कर रहे हैं, है ना?
00:31:33तो आपको उस कर्ज को चुकाने के लिए भी AI का ही सहारा लेना होगा।
00:31:36तो हाँ, मुझे लगता है कि यह वो हिस्सा है
00:31:37जिसे लोग नजरअंदाज कर रहे हैं
00:31:38और जिसे अभी एक समाधान की जरूरत है।
00:31:40- हाँ, मैंने भी ओपन कोर कोडबेस को देखा,
00:31:42जैसा कि आपने कहा, और वो थोड़ा अस्त-व्यस्त है।
00:31:45यह निश्चित रूप से इस बात का बेहतरीन उदाहरण है कि क्या होता है
00:31:49जब आप AI को पूरी तरह आजाद छोड़ देते हैं
00:31:53और उसे वो सब करने देते हैं जो वो चाहता है
00:31:56बिना किसी देखरेख के।
00:31:57इंटरनेट पर पिछले कुछ हफ्तों से इसे ट्रेंड होते हुए देखना
00:32:00और वो सब देखना जो यह कर रहा है, काफी मजेदार रहा है।
00:32:03लेकिन हाँ, मैं AI की भूमिका के बारे में यह भी पूछने वाला था,
00:32:05क्या आप फॉर्मेटर और लिंटर बनाने का तरीका बदलते हैं
00:32:07ताकि AI एजेंट्स उनका बेहतर उपयोग कर सकें?
00:32:09क्या भविष्य इसी तरह से आकार ले रहा है
00:32:11या आपको लगता है कि आपने फॉर्मेटर्स और लिंटर्स को
00:32:13तेज बनाने का जो तरीका अपनाया है, उससे AI के दौर में बस मदद मिली है?
00:32:16मुझे लगता है कि जाहिर तौर पर उनके तेज होने से AI एजेंट्स उनका उपयोग कर सकते हैं।
00:32:19- मुझे लगता है कि यह निश्चित रूप से एक अच्छी सोच है
00:32:22क्योंकि हमने उस समस्या के बारे में सोचना शुरू कर दिया है
00:32:26क्योंकि इन लिंटर्स और फॉर्मेटर्स का
00:32:29मूल दायरा वास्तव में बहुत बड़ा है
00:32:31क्योंकि हम ESLint और Prettier जैसी चीजों के साथ
00:32:34संगत होने की कोशिश कर रहे हैं,
00:32:38जो बरसों से, एक दशक से चलन में हैं,
00:32:40जहाँ लोगों के अपने कस्टम नियम हैं,
00:32:45पुराने उपयोग के मामले (legacy use cases) हैं,
00:32:48और हम उनके साथ 100% संगत होने की कोशिश कर रहे हैं।
00:32:50यह बहुत बड़ी मेहनत का काम है
00:32:53जो हमने आखिरकार हासिल कर लिया है क्योंकि हमने हाल ही में
00:32:54100% ESLint प्लगइन अनुकूलता हासिल की है।
00:32:56हमने ESLint के सभी प्लगइन टेस्ट पास कर लिए हैं
00:33:00और हमने अपने फॉर्मेटर के साथ Prettier के
00:33:03100% अनुपालन (conformance) को भी छू लिया है, ठीक है?
00:33:06तो इन दो उपलब्धियों का मतलब है कि, ठीक है,
00:33:09अब हम भरोसे के साथ लोगों को हमारे टूल्स पर
00:33:13आने की सलाह दे सकते हैं और आगे क्या है, उस पर भी बात कर सकते हैं।
00:33:17जहाँ, आप जानते हैं, वो पूछने के लिए अच्छा सवाल है।
00:33:21कि लिंटिंग और फॉर्मेटिंग को,
00:33:23एजेंट्स के इस्तेमाल के दौरान खुद को कैसे ढालना चाहिए, है ना?
00:33:25यह निश्चित रूप से एक ऐसा सवाल है जिस पर हम सक्रिय रूप से काम कर रहे हैं।
00:33:28हाँ।
00:33:31- तो फिलहाल के लिए इसका जवाब लंबित (pending) ही है, मैं कहूँगा।
00:33:34यह अभी भी विकसित हो रहा है, हाँ।
00:33:38AI कोडिंग की दुनिया में निश्चित रूप से बहुत सी चीजें बदल रहा है,
00:33:40तो यह देखना दिलचस्प है।
00:33:44- Vite+ के विषय पर ही टिके रहते हुए,
00:33:49आपने इसे ViteConf 2025 में दिखाया था
00:33:53और आपने एक फीचर दिखाया था जो 'Vite install' था।
00:33:54तो मेरा सवाल यह है कि, क्या वो फीचर अब भी मौजूद है?
00:33:57और Vite+ में BUN जैसी किसी चीज के
00:33:59साथ कितनी समानता (overlap) होने वाली है?
00:34:01- यह एक अच्छा सवाल है, है ना?
00:34:04तो ViteConf के बाद से चीजें थोड़ी बदली हैं, ठीक है?
00:34:06मैं कहूँगा कि अंतिम,
00:34:10Vite+ का अंतिम सार्वजनिक संस्करण संभवतः,
00:34:14एक मायने में BUN जैसा ही महसूस होगा, है ना?
00:34:17तो ऑनबोर्डिंग का अनुभव, जैसा कि मैंने कहा,
00:34:19अगर आपके पास एक नई मशीन है,
00:34:21और आप सोच रहे हैं, 'मैं जितनी जल्दी हो सके एक वेब ऐप बनाना शुरू करना चाहता हूँ'।
00:34:23तो आप बस स्क्रिप्ट्स को 'curl' करेंगे
00:34:27और आपको 'VP' नाम का एक ग्लोबल बाइनरी मिलेगा और आप करेंगे,
00:34:30तो जब आप किसी प्रोजेक्ट के भीतर होते हैं, ठीक है?
00:34:33अगर आपके पास एक .node वर्जन फाइल है
00:34:38और package.json में एक पैकेज मैनेजर फील्ड है,
00:34:41जो कि इन चीजों को निर्दिष्ट करने के लिए सामान्य तरीके हैं,
00:34:43वो JS एनवायरनमेंट जिसमें आप काम कर रहे हैं, ठीक है?
00:34:45Vite+ सक्षम प्रोजेक्ट में,
00:34:46बल्कि, भले ही आप उस प्रोजेक्ट में Vite+ का उपयोग न कर रहे हों,
00:34:51जब तक आप इन पारंपरिक
00:34:56एनवायरनमेंट सोर्स का उपयोग कर रहे हैं,
00:35:02आप NVM के विकल्प के रूप में Vite+ का उपयोग कर सकते हैं।
00:35:04आप इसे कोर पैक के विकल्प के रूप में उपयोग कर सकते हैं।
00:35:06आप वर्जन्स के बारे में सोचना बंद कर देते हैं।
00:35:11विचार यह है कि, जब आप अपना वर्कफ़्लो चलाते हैं,
00:35:15तो आप इसके माध्यम से करते हैं, आप 'npm run' करना भी बंद कर देते हैं।
00:35:20आप 'VP run' का उपयोग करते हैं।
00:35:22तो विचार यहाँ यह है कि, जब आप 'VP run' करते हैं,
00:35:26तो यह नोड के सही वर्जन का उपयोग करेगा,
00:35:28यह सही पैकेज मैनेजर वर्जन का उपयोग करेगा।
00:35:31और सही चीजें करेगा।
00:35:36तो इंस्टॉल का मतलब है कि यह बस,
00:35:40हमारे पास पहले अपना खुद का पैकेज मैनेजर नहीं है, ठीक है?
00:35:44तो यह एक कोर पैक के समान ज्यादा है
00:35:45जहाँ मुझे नहीं पता कि आपने NI नाम के पैकेज का उपयोग किया है या नहीं,
00:35:48यह एंथोनी फू का है।
00:35:52तो NI का अनिवार्य रूप से मतलब है कि जब आप NI चलाते हैं,
00:35:55तो यह अपने आप समझ जाएगा कि कौन सा पैकेज मैनेजर इस्तेमाल करना है,
00:35:59चाहे आप रन कर रहे हों या इंस्टॉल या अनइंस्टॉल,
00:36:02जो भी हो, ठीक है?
00:36:05तो Vite इंस्टॉल अनिवार्य रूप से वही है,
00:36:06साथ में पैकेज मैनेजर वाला हिस्सा।
00:36:10कोर पैक यही करता है, है ना?
00:36:14तो भले ही आपके पास कुछ और इंस्टॉल न हो,
00:36:16आप किसी प्रोजेक्ट में जाते हैं और package.json
00:36:19फाइल में किसी खास वर्जन का
00:36:24pnpm पैकेज मैनेजर दिया गया है।
00:36:27आप 'Vite install' चलाते हैं, यह अपने आप चेक करेगा
00:36:30कि pnpm का वो वर्जन इंस्टॉल है या नहीं।
00:36:34अगर नहीं है, तो यह बस उसे इंस्टॉल कर देगा
00:36:36और pnpm इंस्टॉल के साथ इंस्टॉल की प्रक्रिया शुरू कर देगा।
00:36:41तो हाँ, विचार यह है कि हम सिर्फ
00:36:45लिंटिंग और फॉर्मेटिंग से कहीं ज्यादा हल करना चाहते हैं।
00:36:48यह पूरे वर्कफ़्लो के बारे में है, जैसे वे सभी सामान्य चीजें जिनकी आपको
00:36:49अपने जॉब के वर्कफ़्लो में जरूरत पड़ती है, है ना?
00:36:51हम इन आम समस्याओं को खत्म करना चाहते हैं ताकि
00:36:56एक शुरुआत करने वाले को इसके बारे में सोचना भी न पड़े, समझे?
00:36:58तो जब आप पहली बार कोई प्रोजेक्ट तैयार करते हैं,
00:37:01तो हम नोड के नवीनतम LTS का उपयोग करेंगे और pnpm की सलाह देंगे।
00:37:03और यह उन जानकारियों को आपके प्रोजेक्ट में भी लिख देगा।
00:37:07ताकि अगली बार जब आप इस प्रोजेक्ट में आएं,
00:37:08तो यह हमेशा चीजों के सही तालमेल का उपयोग करे।
00:37:12- उत्सुकतावश पूछ रहा हूँ, आप pnpm की सलाह क्यों देते हैं?
00:37:14- इसमें फीचर्स के सेट, सटीकता,
00:37:16डिस्क की बचत, स्पीड
00:37:20और वर्कस्पेस सपोर्ट का सही संतुलन है, जैसे 'कैटलॉग' जैसी चीजें,
00:37:25आप जानते ही हैं, जब हम,
00:37:31जब हमने सभी वर्कस्पेस फीचर्स की तुलना की,
00:37:34तो हमें pnpm में ही इनका सबसे अच्छा संतुलन मिला।
00:37:36और ऐसा है कि, हम जानते हैं कि BUN बहुत ज्यादा तेज है,
00:37:40लेकिन हम में से बहुतों के लिए pnpm काफी तेज रहा है।
00:37:43और साथ ही, हम अपने रनटाइम और पैकेज मैनेजर वर्जन
00:37:45मैनेजमेंट में BUN को सपोर्ट करने की संभावना को पूरी तरह से नकार नहीं रहे हैं, ठीक है?
00:37:50तो आप कह सकते हैं कि 'मैं BUN का उपयोग करना चाहता हूँ'
00:37:53और हम चीजों को BUN के साथ चलाएंगे।
00:37:55- तो Vite 8 के बारे में, शायद आपने कहा था कि यह
00:37:59'लूनर न्यू ईयर' के बाद रिलीज होने वाला है, है ना?
00:38:02- हाँ।
00:38:06- हाँ, तो बीटा में ऐसी कौन सी कुछ चीजें हैं
00:38:10जिन पर आप इसे रिलीज करने से पहले ध्यान दे रहे हैं?
00:38:15- यह पूरी तरह से स्थिरता (stability) पर आधारित है।
00:38:19तो इकोसिस्टम CI,
00:38:21जैसे हमारे पास एक बहुत ही बड़ा इकोसिस्टम CI सिस्टम है
00:38:25जहाँ हम Vite 8 को उन प्रोजेक्ट्स में चलाते हैं जो इस पर निर्भर हैं।
00:38:29तो हाल ही में हमने जो किया वो ये है कि,
00:38:33SvelteKit के सभी टेस्ट अब Vite 8 पर पास हो रहे हैं।
00:38:35तो, आप जानते हैं, यह हमारे लिए बड़ी बात है
00:38:37क्योंकि स्थिरता ही सबसे महत्वपूर्ण चीज है
00:38:40क्योंकि अगर आप इसके बारे में सोचें,
00:38:42तो हम दो बंडलर्स को हटाकर
00:38:44एक नए बंडलर से बदल रहे हैं जिसे हमने एकदम शुरू से बनाया है।
00:38:49तो यह एक उड़ते हुए विमान के इंजन बदलने जैसा है
00:38:52और उम्मीद करने जैसा है कि उसके बाद भी वो सुचारू रूप से उड़ता रहेगा।
00:38:54इसके लिए बस बहुत ज्यादा सावधान रहने की जरूरत है।
00:38:58- दरअसल मैं पहले पूछने ही वाला था, Rust को चुनने की वजह,
00:39:00क्या वो बस इसलिए था क्योंकि आपकी टीम के लोगों को
00:39:04Rust की जानकारी थी?
00:39:06क्योंकि मैं देखता हूँ कि TypeScript की दुनिया में बहुत से लोग
00:39:10Go को पसंद करते हैं क्योंकि मुझे लगता है कि इसे अपनाना आसान है
00:39:15और शायद इसीलिए TypeScript भी उस कंपाइलर
00:39:17के लिए Go की ओर जा रहा है।
00:39:21- हाँ, तो मुझे लगता है कि TypeScript टीम द्वारा
00:39:24Go को चुनने की वजह, जैसा कि मैंने कहा,
00:39:27Go एक ऐसी भाषा है जिसमें TypeScript को पोर्ट करना कहीं ज्यादा आसान है, है ना?
00:39:28क्योंकि दोनों का काम करने का तरीका (mental model) काफी मिलता-जुलता है।
00:39:30मुझे लगता है कि हमारे लिए एक बड़ी रुकावट यह थी कि
00:39:33Go का वेब असेंबली (web assembly) सपोर्ट थोड़ा कमजोर है।
00:39:36यह बहुत बड़े वेब असेंबली बाइनरी बनाता है
00:39:40और इसका वेब असेंबली परफॉरमेंस भी
00:39:43Rust की तुलना में उतना अच्छा नहीं है।
00:39:46और Rust के साथ बात यह है कि,
00:39:48हाँ, बहुत कुछ उपलब्ध टैलेंट पर निर्भर करता है,
00:39:49उन लोगों पर जो पहले से ही इस इकोसिस्टम
00:39:51को लेकर उत्साहित हैं और इसमें निवेश कर चुके हैं।
00:39:55उदाहरण के लिए, जब हमने काम शुरू करने के लिए
00:39:57बुनियादी ढांचों (foundations) की तलाश की,
00:39:58तो ऐसा कोई पार्सर या टूल चेन नहीं था
00:40:02जो इतनी अच्छी तरह से लागू किया गया हो और लचीला हो।
00:40:04और बुनियादी तौर पर OXC को इसके ऊपर ही बनाने के लिए बनाया गया है, है ना?
00:40:09ये निम्न-स्तरीय उपयोगिताएं (low level utilities) हैं।
00:40:13हमें Go की दुनिया में इसके बराबर कुछ नहीं दिखा।
00:40:17ES build का अपना पार्सर और बाकी सब कुछ है,
00:40:21लेकिन वो एक बहुत ही बड़ी और अखंड (monolithic) प्रणाली है।
00:40:26आप उसके पार्सर को अलग करके कहीं और इस्तेमाल नहीं कर सकते।
00:40:29साथ ही ES build के सभी फीचर्स,
00:40:32जैसे define, inject, transforms, modification।
00:40:35बेहतरीन परफॉरमेंस पाने के लिए,
00:40:39इसे तीन AST पास में लागू किया गया है,
00:40:41जिसका मतलब है कि एक ही AST पास में,
00:40:44आपके पास मिली-जुली चिंताएं (mixed concerns) हो सकती हैं,
00:40:46जैसे हम यहाँ कुछ ट्रांसफॉर्मेशन कर रहे हैं,
00:40:48हम यहाँ कुछ इंजेक्ट फीचर डाल रहे हैं,
00:40:54हम यहाँ कुछ मॉडिफिकेशन फीचर डाल रहे हैं।
00:40:59यह इसे एक एक्सटेंसिबल सिस्टम के लिए आदर्श नहीं बनाता
00:41:04जहाँ, उदाहरण के लिए,
00:41:08हम और भी ट्रांसफॉर्म्स भेजना चाहते हैं
00:41:11और लोगों को उन ट्रांसफॉर्म्स को चालू या बंद करने की अनुमति देना चाहते हैं।
00:41:14हम चाहते हैं कि लोग अपने खुद के ट्रांसफॉर्म्स लिख सकें।
00:41:18आप एक ऐसा लिंटर सिस्टम चाहते हैं जहाँ हम,
00:41:23हम चाहते हैं कि यह साफ परतों में हो
00:41:25ताकि एक ही समय में ज्यादा लोग इस पर काम कर सकें।
00:41:30तो यह बहुत कुछ इस पर निर्भर करता है कि हमारे पास क्या उपलब्ध है।
00:41:33Rust भी वाकई बहुत शक्तिशाली है।
00:41:36Rust के साथ अच्छे ट्रांसफॉर्म्स लिखना वास्तव में थोड़ा पेचीदा है।
00:41:37हमें विजिटर्स और ट्रांसफॉर्मर पाइपलाइन के लिए
00:41:39एक अच्छा आर्किटेक्चर तैयार करने में
00:41:41काफी समय बिताना पड़ा,
00:41:42क्योंकि मेमोरी ओनरशिप की समस्या होती है,
00:41:45जैसे जब आप पेड़ (tree) में बहुत गहराई तक जाते हैं
00:41:51और आपको मूल पेड़ (parent tree) को बदलना होता है,
00:41:54तो यह बहुत पेचीदा हो जाता है, है ना?
00:41:57लेकिन हमने इसका हल निकाल लिया।
00:42:01Go में यह कहीं ज्यादा आसान है, लेकिन जब हम सोचते हैं,
00:42:03तो हम चाहते हैं कि हमारी चीजें वेब असेंबली में
00:42:07कंपाइल हो सकें और ब्राउज़र में चल सकें।
00:42:09तो, Rolldown ब्राउज़र में चल सकता है
00:42:13और काफी अच्छी गति से काम करता है।
00:42:16मेरा मतलब है, ES build भी ब्राउज़र में चल सकता है,
00:42:22लेकिन Rust का वेब असेंबली बस बेहतर है।
00:42:26- अगला सवाल मैं टीम के Rust में काम करने
00:42:28और बाकी सब पर आधारित पूछने वाला था,
00:42:31टीम और आप खुद AI का उपयोग कैसे कर रहे हैं?
00:42:34आपने पहले जिक्र किया था कि टीम के बहुत से लोग
00:42:37AI का उपयोग कर रहे हैं।
00:42:39क्या आपको लगता है कि AI उस काम में अच्छा है जो आप कर रहे हैं?
00:42:42क्योंकि मुझे लगता है कि वेब डेवलपमेंट और वेबसाइट बनाने जैसी चीजों के
00:42:44GitHub पर इतने सारे उदाहरण मौजूद हैं।
00:42:45इसलिए AI को काफी अच्छे से ट्रेन किया गया है।
00:42:49लेकिन मुझे लगता है कि आप जो कर रहे हैं वो एक तरह से काफी गहरा
00:42:51या कम से कम काफी उच्च स्तर की तकनीकी का काम है।
00:42:53तो क्या AI वहाँ मददगार है या आप अभी भी
00:42:57खुद ही बहुत सारी कोडिंग कर रहे हैं?
00:42:59- यह निश्चित रूप से मददगार है।
00:43:01मुझे लगता है कि बात यह है कि यह क्षेत्र बहुत तेजी से बदल रहा है।
00:43:05मुझे लगता है कि पिछले साल इसी समय, मैं इसे लेकर संशयी था।
00:43:07मुझे लगता था, 'खैर, मैंने इसे आजमाया है, यह मेरे लिए काम नहीं करता'
00:43:09क्योंकि मैं जो काम कर रहा हूँ वो बहुत ही बुनियादी स्तर (low level) का है, ठीक है।
00:43:12और फिर मुझे लगता है, बोरशिन जो OXC के लीड हैं,
00:43:14वे शायद कंपनी में इस समय
00:43:16पूरी तरह से AI के रंग में रंगे हुए व्यक्ति हैं।
00:43:19तो उन्होंने प्रयोगों के साथ कुछ अनोखे काम करने शुरू किए।
00:43:21और जैसे, मुझे लगता है पिछले महीने एक हफ्ता ऐसा था
00:43:23जब उन्होंने AI की मदद से लगभग 60 PRs भेजे
00:43:25और बस एजेंट्स को एक साथ चला रहे थे।
00:43:28और फिर हमने कुछ अनोखे प्रयोग करने शुरू किए
00:43:30जैसे Angular कंपाइलर को Rust में पोर्ट करना और देखना,
00:43:32हमने बस इसे AI के सामने डाल दिया और देखा कि क्या यह काम करेगा।
00:43:34और किसी तरह यह काम कर रहा है।
00:43:38तो शायद भविष्य में हमारे पास उस दिशा में भी कुछ हो।
00:43:41लेकिन हाँ, मुझे लगता है कि हम लगातार अपडेट हो रहे हैं
00:43:45और AI की क्षमता को लेकर हमारी जो धारणा है
00:43:49वो हर कुछ महीनों में बदल रही है,
00:43:52जब भी नए मॉडल्स आते हैं,
00:43:59बेहतर सिस्टम लागू किए जाते हैं
00:44:03और नए तरीके अपनाए जाते हैं जैसे 'use plan mode'
00:44:04और फिर अपने एजेंट्स की MD लिखना।
00:44:07ये इन सुझावों और तरकीबों का उपयोग करने जैसा है।
00:44:11तो जब आप इन छोटी-छोटी चीजों को लागू करते हैं, तो आपको एहसास होता है, 'ठीक है',
00:44:13'यह वाकई दिन-ब-दिन बेहतर होता जा रहा है।'
00:44:16और वैसे, इसे अपनाना और इसका उपयोग अभी भी लोगों के हिसाब से अलग-अलग है, है ना?
00:44:19हम कंपनी में हर किसी को प्रोत्साहित करते हैं
00:44:24कि वे जहाँ तक उचित समझें इसका उपयोग करें, ठीक है?
00:44:27हम उन्हें एक मासिक क्रेडिट देते हैं
00:44:29ताकि अगर वे चाहें तो Claude Max का उपयोग कर सकें।
00:44:33तो मुझे लगता है कि कुछ लोग इसे लेकर बहुत खुश हैं
00:44:39और वास्तव में इसके बारे में काफी मुखर भी हैं।
00:44:43और जाहिर है कि वे बहुत अच्छे PRs भी भेज रहे हैं, है ना?
00:44:46मुझे लगता है कि यह वास्तव में इस पर निर्भर करता है कि आप इसका कितने अच्छे से उपयोग कर सकते हैं।
00:44:48इसका एक हिस्सा तो मॉडल की अपनी क्षमता है।
00:44:51एक हिस्सा वो सिस्टम है जिसका आप उपयोग कर रहे हैं,
00:44:55लेकिन मुझे लगता है कि वो सिस्टम वाली परत
00:45:00बिल्कुल पुराने जमाने के JavaScript फ्रेमवर्क्स की तरह है।
00:45:03ऐसा है कि हर कोई बस अपना वर्जन बनाने में लगा है।
00:45:06और वे कमोबेश एक ही काम कर रहे हैं।
00:45:08शायद किसी के पास कुछ अलग तरकीबें हों,
00:45:13लेकिन कुछ महीनों बाद, हर कोई वही कर रहा होता है, है ना?
00:45:18तो यह बस एक बहुत ही
00:45:22प्रतिस्पर्धी क्षेत्र होने वाला है और मॉडल का भी यही हाल है।
00:45:24जैसे हर कुछ महीनों में,
00:45:27जैसे अब Sonnet 3.5 आने वाला है।
00:45:33मुझे लगता है कि DeepSeek भी एक नया मॉडल लाने वाला है।
00:45:36यह बस बेहतर और बेहतर होता जाएगा।
00:45:40और मुझे लगता है कि यह बिल्कुल साफ है कि AI सही मार्गदर्शन के साथ
00:45:45बेहद सक्षम है,
00:45:49लेकिन मुझे लगता है कि वो मार्गदर्शन वाला हिस्सा आज भी बहुत महत्वपूर्ण है।
00:45:52आप यह उम्मीद नहीं कर सकते कि जिसे Rust की बिल्कुल भी जानकारी नहीं है,
00:45:54वो AI के साथ भी OXC कोडबेस में काम कर पाएगा।
00:45:57देखा जाए तो उसे शायद यह भी नहीं पता होगा कि प्रॉम्प्ट क्या देना है, है ना?
00:46:00लेकिन कोई ऐसा व्यक्ति जो पहले से ही OXC में कुशल है
00:46:03एक Rust इंजीनियर के तौर पर, वो AI के साथ
00:46:08कहीं ज्यादा उत्पादक (productive) बन जाता है
00:46:11और तेजी से ज्यादा फीचर्स भेज सकता है, ठीक है?
00:46:13तो इस पर मेरी यही सामान्य राय है।
00:46:17तो मैं कहूँगा कि मैं शायद वो हूँ,
00:46:18जो AI की मदद से बहुत ही कम कोड बनाता है,
00:46:21कंपनी के अन्य इंजीनियर्स की तुलना में बहुत ही कम।
00:46:23मैं इसका उपयोग शोध और बस विचारों को परखने के लिए ज्यादा करता हूँ।
00:46:26- पता है, यह वाकई एक अजीब दुनिया है,
00:46:32जिस ओर कोडिंग जा रही है
00:46:34और मुझे यह समझना मुश्किल लग रहा है कि
00:46:37आपको कितने 'सब-एजेंट्स' का उपयोग करना चाहिए,
00:46:41पैरेलल एजेंट्स, और अब आपको अपने रेपो में
00:46:45कौन सी मार्कडाउन फाइल रखनी चाहिए।
00:46:50हाँ, यह हर समय बदल रहा है।
00:46:54तो यह देखना दिलचस्प होगा कि भविष्य में
00:46:58हम इस बारे में कहाँ पहुँचते हैं।
00:47:00- अगर हम थोड़ी देर के लिए वापस Vite पर आएं।
00:47:03तो Vite 7 में, आपने React server component सपोर्ट जारी किया था।
00:47:08और मेरी राय में, React server components
00:47:13उतने सफल साबित नहीं हुए हैं जितना टीम ने सोचा था।
00:47:16मेरा मतलब है, कुछ ऐसे मेटा-फ्रेमवर्क्स हैं जो इसे स्वीकार नहीं कर रहे हैं,
00:47:20जैसे TanStack।
00:47:25और मुझे लगता है कि Remix तो अपनी एक बिल्कुल अलग दिशा में चला गया है।
00:47:27तो React server components पर आपके क्या विचार हैं
00:47:29और आपको क्यों लगता है कि यह उतनी अच्छी तरह से नहीं चल पाया जितना चलना चाहिए था?
00:47:32- हाँ, मैं इसे लेकर हमेशा बहुत रूढ़िवादी रहा हूँ
00:47:34या मैं पहले दिन से ही इसे लेकर संशयी रहा हूँ।
00:47:37यही कारण है कि हमने कभी Vue में
00:47:38ऐसी किसी चीज को लागू करने के बारे में नहीं सोचा।
00:47:40मुझे लगता है कि यहाँ बुनियादी सवाल यह है कि यह
00:47:43वास्तव में किस समस्या को हल करने की कोशिश कर रहा है?
00:47:43और मुझे लगता है कि इसे जिस तरह से बढ़ावा दिया गया, है ना?
00:47:47मुझे लगता है कि लोगों को उत्साहित करने की कोशिश में,
00:47:52इसे एक अचूक रामबाण (silver bullet) की तरह विज्ञापित किया गया।
00:47:54कि यह अब तक की सबसे बेहतरीन चीज होने वाली है।
00:47:57कि यह आपकी सभी वेबसाइट्स को तेज बना देगा।
00:48:00जब यह सामने आया, तो लोगों को एहसास हुआ, ठीक है,
00:48:01शायद मुझे इसे हर मामले में इस्तेमाल नहीं करना चाहिए।
00:48:04यह केवल कुछ खास तरह के मामलों में ही लागू होता है
00:48:07जहाँ यह आपको फायदा पहुँचाएगा।
00:48:10और बाकी मामलों में, यह बस समझौतों का एक पुलिंदा है।
00:48:14क्योंकि जो हिस्से सर्वर पर रहते हैं,
00:48:17अब उन सभी इंटरैक्शंस के लिए वास्तव में
00:48:20एक नेटवर्क राउंड ट्रिप करनी पड़ती है।
00:48:23और मेरी राय में 'ऑफलाइन-फर्स्ट' अनुभव के लिए
00:48:28यह काफी बुरा है।
00:48:30और फिर मेरी राय में आप पूरी तरह से
00:48:35'हाइड्रेशन कॉस्ट' (hydration costs) से नहीं बच सकते।
00:48:38और आप क्लाइंट-साइड हाइड्रेशन की बहुत सी लागत को कम कर रहे हैं।
00:48:40लेकिन आप वो बोझ सर्वर पर डाल रहे हैं, है ना?
00:48:42अब आप हर रिक्वेस्ट की लागत झेल रहे हैं
00:48:44और सर्वर पर ज्यादा काम कर रहे हैं।
00:48:48तो लोगों के पास ये थ्योरी है, साजिश वाली थ्योरी (conspiracy theory),
00:48:51कि Vercel अपनी 'कंप्यूट' सर्विस बेचने के लिए इसे बढ़ावा दे रहा है।
00:48:54मुझे नहीं लगता कि असल बात यह है, ठीक है?
00:48:56लेकिन यह भी सच है कि RSC का उपयोग करने का
00:48:59मतलब है कि सर्वर पर बोझ ज्यादा होगा।
00:49:04आप सर्वर पर ज्यादा चीजें चला रहे हैं,
00:49:06आप ज्यादा कंप्यूट मिनट इस्तेमाल कर रहे हैं।
00:49:08और अंततः इसके अन्य फायदे भी हैं जैसे कि,
00:49:10अगर आप अपनी चीज का एक हिस्सा सर्वर पर रखते हैं,
00:49:14तो आप बंडल साइज कम कर लेते हैं।
00:49:20उस समस्या को हल करने के और भी कई तरीके हैं,
00:49:21जिनमें अनिवार्य रूप से यह शामिल नहीं है कि
00:49:26आपको Node.js सर्वर ही चलाना पड़े, है ना?
00:49:29और इसमें से बहुत कुछ मेरी निजी राय है, ठीक है?
00:49:31फ्रंट एंड में, हम अक्सर कहते हैं, ठीक है,
00:49:33आर्किटेक्चर वास्तव में मायने रखता है।
00:49:38क्या आप SPA का उपयोग करना चाहते हैं?
00:49:44क्या आपको सर्वर-साइड रेंडरिंग की जरूरत है, है ना?
00:49:47RSC इससे भी ज्यादा विशिष्ट है।
00:49:51कि 'क्या आपको RSC की जरूरत है' एक बहुत महत्वपूर्ण सवाल है
00:49:52और इसका जवाब देना बहुत मुश्किल है।
00:49:54और जब आप 'हाँ' कहते हैं,
00:49:56तो आपको इसकी कीमत के बारे में भी पता होना चाहिए
00:49:59क्योंकि मुझे लगता है कि इसके बहुत अच्छे से न अपनाए जाने की
00:50:01एक वजह यह है कि सबसे पहले तो यह बहुत जटिल है।
00:50:02यह चीज खुद ही समझाने में मुश्किल है।
00:50:06यह कैसे काम करती है, यह समझाना मुश्किल है।
00:50:07हमें इसकी गहराइयों में जाना पड़ा
00:50:10क्योंकि पूरी प्रणाली को काम के लायक बनाने के लिए
00:50:14बिल्ड टूल स्तर के तालमेल की जरूरत होती है, है ना?
00:50:17और तो और, बहुत कम लोग वास्तव में यह समझते हैं
00:50:19कि रॉ RSC (raw RSC) कैसे काम करता है।
00:50:21ज्यादातर लोग इसके बारे में Next.js में इसके कार्यान्वयन
00:50:24के जरिए जानते हैं क्योंकि रॉ RSC एक ऐसी चीज है जिसे एक औसत यूजर
00:50:27अपने आप सेटअप नहीं कर पाएगा, है ना?
00:50:31आपको वाकई यह समझना होगा कि यह सब एक साथ कैसे फिट होता है
00:50:33ताकि आप साधारण React और Vite या Webpack के साथ
00:50:35इसे एकदम शुरू से खड़ा कर सकें, ठीक है?
00:50:37यह रोजमर्रा के डेवलपमेंट के लिए नहीं है, समझे?
00:50:39तो आप एक फ्रेमवर्क का उपयोग करना चाहते हैं।
00:50:43यह उसी के लिए बनाया गया है।
00:50:46लेकिन एक फ्रेमवर्क में RSC का उपयोग करने के लिए,
00:50:48फ्रेमवर्क को कुछ डिजाइन फैसले लेने पड़ते हैं
00:50:50कि आप RSC को इस तरह कैसे पेश करें
00:50:52जिससे आपको एक अच्छा डेवलपर अनुभव (DX) मिले?
00:50:56और मुझे लगता है कि Next.js इसे सही तरह से नहीं कर पाया, मैं यही कहूँगा, ठीक है?
00:50:58जैसे 'use server' और 'use client' को लेकर भ्रम,
00:51:02वो मिला-जुला ग्राफ जहाँ जब आप किसी चीज को 'use server' बनाते हैं
00:51:04तो कुछ चीजें काम करना बंद कर देती हैं।
00:51:07जैसे आप केवल इन चीजों का उपयोग करने तक सीमित रह जाते हैं
00:51:11और फिर आपको एक डिपेंडेंसी इम्पोर्ट करनी पड़ती है
00:51:14और वो डिपेंडेंसी 'use server' पर काम नहीं करती।
00:51:17अब आपको फिर से 'use client' का उपयोग करना होगा, है ना?
00:51:20तो इस तरह का आगे-पीछे होना,
00:51:23मुझे लगता है कि DX में ये छोटी-छोटी परेशानियां
00:51:27लोगों को यह सोचने पर मजबूर करती हैं, ठीक है,
00:51:29कथित लाभ पाने के लिए,
00:51:30अब मुझे DX की इस झुंझलाहट को भी झेलना होगा,
00:51:33वो भी हमेशा के लिए।
00:51:36क्या वाकई यह इसके लायक है, है ना?
00:51:39तो हाँ, मुझे लगता है कि यह वाजिब है कि लोग सोचें,
00:51:42'क्या मैं वाकई इसका उपयोग करना चाहता हूँ?'
00:51:47और साथ ही फ्रेमवर्क बनाने वालों के लिए भी, है ना?
00:51:51Vercel का React टीम के साथ बहुत करीबी रिश्ता था
00:51:55इसलिए वे इस पर मिल-जुलकर काम कर सकते थे और तेजी से बदलाव ला सकते थे।
00:51:58लेकिन दूसरों के लिए, मैं उन्हें थर्ड-पार्टी भी नहीं कहूँगा
00:52:01क्योंकि तकनीकी रूप से Vercel भी थर्ड-पार्टी ही है, है ना?
00:52:03लेकिन Remix और TanStack जैसे अन्य फ्रेमवर्क्स के लिए,
00:52:06इस समस्या पर काम करना इतना आसान नहीं है
00:52:08क्योंकि React टीम की ओर से होने वाले बहुत से API बदलाव
00:52:10Next.js को प्राथमिकता दे रहे हैं।
00:52:12तो मैं इसके लिए उनकी आलोचना नहीं कर रहा हूँ
00:52:15क्योंकि ऐसा ही है, ठीक है, Vercel उनका डिजाइन पार्टनर है।
00:52:20वे Vercel के साथ साझेदारी करना चाहते हैं
00:52:24ताकि इस फीचर को मांझकर जारी किया जा सके,
00:52:27जिसका मतलब बनता है, है ना?
00:52:28लेकिन मुझे लगता है कि इसकी वजह से,
00:52:35Next.js ही अनिवार्य रूप से लोगों के लिए
00:52:37RSC का उपयोग करने का एकमात्र वास्तविक तरीका था।
00:52:40और वो अनुभव बहुत शानदार नहीं रहा है।
00:52:42तो मुझे लगता है कि इसी वजह से यह उस तरह सफल नहीं हो पाया जैसा हो सकता था।
00:52:45और साथ ही, मुझे लगता है कि इसका जो सामान्य आधार है
00:52:49कि एक आदर्श दुनिया में भी जहाँ RSC का DX एकदम परफेक्ट हो,
00:52:52फिर भी मुझे नहीं लगता कि यह हर मामले में
00:52:57एक अचूक समाधान साबित होगा, है ना?
00:53:02तो आपको पूरी तरह से शिक्षित होने की जरूरत है
00:53:06कि यह कहाँ सही बैठता है और कहाँ नहीं।
00:53:08तो इसमें समझौते बहुत ज्यादा हैं।
00:53:13- मेरा मानना है कि Vue में ऐसी किसी चीज को लागू करने का
00:53:15कोई दबाव नहीं रहा होगा
00:53:17क्योंकि जाहिर तौर पर सब कुछ Vercel से जुड़ा है।
00:53:19उन्होंने Nuxt Labs को खरीद लिया,
00:53:21जो कि Vue के ऊपर सब कुछ जोड़ने वाला
00:53:25एक तरह का मेटा-फ्रेमवर्क है।
00:53:29तो अब Vercel द्वारा उन्हें खरीदे जाने के बाद,
00:53:31Nuxt और Vue के बीच संबंध कैसे रहे हैं?
00:53:33- ईमानदारी से कहूँ तो, इसमें ज्यादा कुछ नहीं बदला।
00:53:38मुझे लगता है कि अधिग्रहण के बाद से Vercel काफी दूर रहा है
00:53:41इसलिए Nuxt टीम अपना काम उसी तरह
00:53:46जारी रखने में खुश है जैसा वे करते आ रहे हैं।
00:53:49शायद ऐसी कुछ कोशिशें हो रही हों कि,
00:53:50Nuxt को Vercel पर बेहतर तरीके से चलाया जा सके,
00:53:52उसे एक 'फर्स्ट-क्लास' दर्जा दिया जा सके।
00:53:54लेकिन मुझे लगता है कि Vercel इस बात से वाकिफ है
00:53:57कि कम्युनिटी में उसकी क्या छवि है
00:53:59और वे इसे और ज्यादा नुकसान न पहुँचाने के लिए बहुत सावधान रहेंगे।
00:54:01और इसलिए Nuxt का अधिग्रहण करने के बाद, ठीक है,
00:54:03वे आखिरी चीज यही चाहेंगे कि
00:54:05Nuxt को वो सब करने के लिए मजबूर किया जाए जो लोगों को पसंद नहीं है।
00:54:08- दुर्भाग्य से, इवान को एक महत्वपूर्ण कॉल के लिए
00:54:09जल्दी निकलना पड़ा,
00:54:13लेकिन हमारे द्वारा पूछे गए सभी सवालों पर उनके समय
00:54:14और उनकी गहरी राय के लिए हम वाकई उनके आभारी हैं।
00:54:18अगर आप पॉडकास्ट पर किसी भविष्य के मेहमान को देखना चाहते हैं,
00:54:21तो कृपया हमें कमेंट्स में बताएं।
00:54:24और अगर आपकी सामान्य तौर पर कोई प्रतिक्रिया हो,
00:54:25तो वो भी हमें जरूर बताएं।
00:54:30हमें उसे सुनकर खुशी होगी।
00:54:32हमें आप कहीं भी सुन सकते हैं जहाँ आप पॉडकास्ट सुनते हैं
00:54:34जैसे Spotify या Apple Podcasts।
00:54:38और अगली बार तक के लिए, मेरी तरफ से विदा।
00:54:43- मेरी तरफ से विदा।
00:54:47- मेरी तरफ से विदा।
00:54:50- यह मेरे लिए सौभाग्य की बात रही, आप सभी का धन्यवाद।
00:54:52- हमसे जुड़ने के लिए आपका बहुत-बहुत धन्यवाद।
00:54:54- Unfortunately, Evan had to leave early
00:54:56to take an important call,
00:54:58but we really appreciate his time
00:55:00and all his insightful opinions on all the questions we asked.
00:55:04If you have any future guests you'd love on the podcast,
00:55:06please let us know in the comments.
00:55:08And if you have any feedback in general,
00:55:10also let us know too.
00:55:11We'd love to hear it.
00:55:12Find us on anywhere you listen to podcasts
00:55:15like Spotify or Apple Podcasts.
00:55:17And until next time, it's a bye from me.
00:55:20- Bye from me.
00:55:21- Bye from me.
00:55:21- It's a pleasure, thank you all.
00:55:23- Thank you very much for joining us.

Key Takeaway

इवान यू अपनी कंपनी Voice Zero के माध्यम से Rust-आधारित उच्च-प्रदर्शन टूलिंग का एक ऐसा वर्टिकल स्टैक विकसित कर रहे हैं, जो वेब डेवलपमेंट को तेज, सरल और AI-अनुकूल भविष्य की ओर ले जाएगा।

Highlights

इवान यू ने अपनी नई कंपनी Voice Zero और उसके अंतर्गत विकसित हो रहे Rust-आधारित आधुनिक टूल्स जैसे Rolldown और OXC का परिचय दिया।

Rolldown का लक्ष्य Vite के लिए एक ऐसा एकीकृत बंडलर बनना है जो विकास और उत्पादन (production) दोनों स्तरों पर गति और निरंतरता सुनिश्चित करे।

OXC टूलचेन ESLint और Prettier की तुलना में 50 से 100 गुना अधिक तेज प्रदर्शन प्रदान करती है, जिससे डेवलपर अनुभव में भारी सुधार होता है।

Vite+ एक नए 'जीरो-कॉन्फ़िग' दृष्टिकोण पर काम कर रहा है, जो Node.js और पैकेज प्रबंधकों के प्रबंधन को सरल बनाकर शुरुआती लोगों के लिए बाधाओं को कम करेगा।

इवान यू ने AI के प्रभाव पर चर्चा करते हुए बताया कि कैसे उनकी टीम Rust कोडिंग की गति बढ़ाने और पुराने कंपाइलरों को पोर्ट करने के लिए AI एजेंट्स का उपयोग कर रही है।

React Server Components (RSC) के प्रति संशय व्यक्त करते हुए इवान ने इसकी जटिलता, DX चुनौतियों और सर्वर पर बढ़ने वाले कंप्यूट बोझ की आलोचना की।

Timeline

Voice Zero और नई Rust टूलिंग का परिचय

इस शुरुआती खंड में इवान यू ने अपनी नई कंपनी Voice Zero और उसके द्वारा विकसित किए जा रहे विभिन्न ओपन सोर्स प्रोजेक्ट्स जैसे Vite, Vue, Rodeo और OXC के बारे में जानकारी साझा की। उन्होंने स्पष्ट किया कि OXC एक पूर्ण Rust टूलचेन है जिसमें पार्सर, रिज़ॉल्वर और मिनीफायर जैसे महत्वपूर्ण घटक शामिल हैं जो प्रदर्शन में क्रांतिकारी सुधार लाते हैं। इवान ने यह भी बताया कि कंपनी के इंजीनियर्स अब Rust कोड लिखने के लिए AI टूल्स का व्यापक उपयोग कर रहे हैं। उनका मुख्य काम अब कोडिंग के बजाय डेवलपर अनुभव (DX) से जुड़े रणनीतिक निर्णय लेना और प्रोजेक्ट्स की दिशा तय करना है। यह खंड स्पष्ट करता है कि कैसे एक आधुनिक टेक कंपनी ओपन सोर्स और कमर्शियल उत्पादों के बीच संतुलन बना रही है।

Vite की उत्पत्ति और Rolldown की आवश्यकता

इवान यू ने यहाँ Vite के विकास की यात्रा और बंडलिंग की चुनौतियों पर विस्तार से चर्चा की है। उन्होंने बताया कि कैसे esbuild और Rollup का संयोजन कुछ हद तक सफल रहा, लेकिन प्रदर्शन में विसंगतियों और Go और JS के बीच डेटा ट्रांसफर की लागत के कारण सीमाएं पैदा हुईं। esbuild की एक्सटेंसिबिलिटी की कमी और Rollup की गति संबंधी समस्याओं ने उन्हें 'Rolldown' बनाने के लिए प्रेरित किया, जो मूल रूप से Rollup का Rust पोर्ट है। लेखक ने बताया कि JavaScript के लचीलेपन के कारण इसे सीधे Rust में पोर्ट करना कठिन था, इसलिए इसे फिर से लिखना पड़ा। यह खंड तकनीकी गहराई के साथ समझाता है कि क्यों एक नया, तेज और अधिक एकीकृत बंडलर आधुनिक वेब एप्स के लिए अनिवार्य है।

OXC टूलचेन और वर्टिकल स्टैक का विजन

इस अनुभाग में OXC (Oceanic Next Compiler) की तकनीकी श्रेष्ठता और इसके 'arena allocator' जैसे अद्वितीय फीचर्स पर प्रकाश डाला गया है। इवान ने दावा किया कि OXC का पार्सर SWC से तीन गुना तेज है और यह पूरे टूलचेन के लिए एक मजबूत आधार प्रदान करता है। उनका विजन एक ऐसा वर्टिकल स्टैक बनाना है जहाँ पार्सर, लिंटर, फॉर्मेटर और बंडलर सभी एक ही आधार पर काम करें ताकि कॉन्फ़िगरेशन की जटिलता समाप्त हो सके। आँकड़ों के अनुसार, OX Lint और OX Format क्रमशः ESLint और Prettier से कई गुना अधिक तेज हैं। यह खंड भविष्य की उस टूलिंग की झलक देता है जहाँ डेवलपर्स को कई अलग-अलग टूल्स को जोड़ने की मशक्कत नहीं करनी पड़ेगी।

बंडलिंग का भविष्य और 'नो-बिल्ड' की बहस

यहाँ चर्चा Rails के 'import maps' और 'नो-बंडल' दृष्टिकोण की ओर मुड़ती है, जिसे DHH द्वारा बढ़ावा दिया जा रहा है। इवान ने स्वीकार किया कि छोटे प्रोजेक्ट्स के लिए 'अनबंडल' मोड अच्छा है, लेकिन बड़े एप्लिकेशंस में हजारों मॉड्यूल्स लोड करने पर नेटवर्क बाधाएं और खराब प्रदर्शन की समस्या आती है। उन्होंने तर्क दिया कि बंडलिंग एक मुफ़्त ऑप्टिमाइजेशन है जिसे बड़े स्तर पर हमेशा अपनाया जाना चाहिए ताकि यूजर्स को बेहतर अनुभव मिले। लोगों की बिल्ड टूल्स से चिढ़ का मुख्य कारण जटिल कॉन्फ़िगरेशन है, जिसे इवान अपनी नई टूलिंग के माध्यम से सरल बनाना चाहते हैं। यह खंड स्पष्ट रूप से समझाता है कि क्यों 'नो-बिल्ड' के विचार आकर्षक होने के बावजूद बड़े व्यावसायिक एप्स के लिए पूर्ण समाधान नहीं हैं।

Vite+ और सरल ऑनबोर्डिंग का अनुभव

इवान ने Vite+ के साथ अपने नए प्रयोगों के बारे में बताया, जिसका उद्देश्य नए डेवलपर्स के लिए Node.js और पैकेज मैनेजर्स की जटिलता को खत्म करना है। Vite+ एक ग्लोबल बाइनरी 'VP' के माध्यम से काम करेगा जो प्रोजेक्ट की आवश्यकताओं के अनुसार सही Node वर्जन और पैकेज मैनेजर को स्वचालित रूप से प्रबंधित करेगा। उन्होंने लाइसेंसिंग मॉडल पर भी बात की और स्पष्ट किया कि अधिकांश व्यक्तिगत यूजर्स के लिए यह मुफ्त रहेगा, जबकि केवल बड़ी कंपनियों को भुगतान करना होगा। इसके अलावा, उन्होंने चर्चा की कि कैसे AI एजेंट्स के साथ काम करने के लिए टूलिंग में बदलाव की जरूरत है ताकि तकनीकी ऋण (tech debt) को बढ़ने से रोका जा सके। यह हिस्सा भविष्य के एक सुव्यवस्थित और AI-सक्षम विकास वातावरण की रूपरेखा प्रस्तुत करता है।

Vite 8, Rust का चयन और AI की भूमिका

इस खंड में आगामी Vite 8 की स्थिरता और इकोसिस्टम CI पर चर्चा की गई है, जिसे 'उड़ते विमान का इंजन बदलने' जैसा संवेदनशील कार्य बताया गया है। इवान ने Go के बजाय Rust को चुनने के तकनीकी कारणों को साझा किया, जिसमें Rust का बेहतर WebAssembly सपोर्ट और OXC जैसी शक्तिशाली नींव की उपलब्धता शामिल है। उन्होंने AI के बारे में अपने बदलते विचारों को साझा करते हुए बताया कि कैसे उनकी टीम ने AI की मदद से Angular कंपाइलर को Rust में पोर्ट करने जैसे साहसी प्रयोग किए हैं। हालाँकि AI उत्पादकता बढ़ाता है, लेकिन इवान के अनुसार कुशल इंजीनियर्स का मार्गदर्शन अभी भी कोड की गुणवत्ता के लिए अनिवार्य है। यह खंड तकनीकी निर्णय लेने की प्रक्रिया और आधुनिक इंजीनियरिंग में मानवीय कौशल बनाम AI की भूमिका को उजागर करता है।

React Server Components और निष्कर्ष

अंतिम भाग में इवान यू ने React Server Components (RSC) के प्रति अपनी कड़ी और संशयपूर्ण राय साझा की। उनका मानना है कि RSC ने जिन लाभों का वादा किया था, वे DX की अत्यधिक जटिलता और सर्वर लागत के बोझ तले दब गए हैं। उन्होंने Next.js के कार्यान्वयन की आलोचना की और बताया कि कैसे Vue ने जानबूझकर इस जटिल रास्ते को नहीं चुना। इसके बाद पॉडकास्ट में Nuxt और Vercel के संबंधों पर संक्षिप्त टिप्पणी की गई और बताया गया कि अधिग्रहण के बाद भी Nuxt स्वतंत्र रूप से काम कर रहा है। अंत में, इवान के जल्दी जाने के बाद मेजबानों ने चर्चा को समाप्त किया और दर्शकों से फीडबैक माँगा। यह खंड पॉडकास्ट के मुख्य निष्कर्षों और आधुनिक फ्रेमवर्क की दिशा पर अंतिम विचार प्रस्तुत करता है।

Community Posts

View all posts