Bun.Image आपके पूरे इमेज पाइपलाइन को बेकार बना देता है
BBetter Stack
Computing/SoftwareInternet Technology
Transcript
00:00:00यह Bun Image है, जो Bun 1.3.14 के साथ आया एक इन-बिल्ट इमेज प्रोसेसिंग API है जो रिसाइज कर सकता है,
00:00:06क्रॉप कर सकता है, और जीरो नेटिव डिपेंडेंसी के साथ अलग-अलग फॉर्मेट्स में इमेज कन्वर्ट कर सकता है,
00:00:10और यह पूरा काम मेन थ्रेड से हटकर चलता है, जिसका मतलब है कि यह आपके सर्वर को ब्लॉक नहीं करेगा
00:00:14जब यह प्रोसेसिंग कर रहा होगा। लेकिन Bun तो पहले से ही एक रनटाइम, पैकेज मैनेजर, बंडलर, टेस्ट रनर है,
00:00:19और अब यह एक इमेज प्रोसेसर भी है? क्या यह सब कुछ बहुत ज्यादा है, या यह हमें कुछ
00:00:24बड़ा बता रहा है कि Bun किस दिशा में जा रहा है? सब्सक्राइब करें और आइए पता करते हैं।
00:00:30अगर आपने कभी सर्वर पर JavaScript के साथ इमेज प्रोसेस की है, तो शायद आपने Sharp नाम की एक लाइब्रेरी का
00:00:35इस्तेमाल किया होगा, जिसके npm पर हर हफ्ते 55 मिलियन से ज्यादा डाउनलोड्स हैं, और यह
00:00:41Next.js द्वारा भी इमेज ऑप्टिमाइज़ेशन के लिए हुड के नीचे इस्तेमाल किया जाता है। लेकिन Sharp एक नेटिव बाइनरी पर निर्भर है जिसे libvips कहते हैं,
00:00:47जिसका मतलब है कि हर इंस्टाल को आपके प्लेटफॉर्म के लिए सही बिल्ड खींचना पड़ता है। और अगर आपने कभी
00:00:51Docker बिल्ड या CI पाइपलाइन फेल होते देखी है, तो आप जानते हैं कि यह कितना निराशाजनक है। इसलिए Bun ने फैसला किया
00:00:57कि इमेज प्रोसेसिंग को सीधे रनटाइम में ही डाल दिया जाए, और यह वास्तव में Sharp से ज्यादा तेज है
00:01:02ज्यादातर बेंचमार्क में। मेटाडेटा रीड 70 गुना तेज है, और रिसाइजिंग लगभग 30% तेज है। अब बहुत से
00:01:08डेवलपर्स वाकई हैरान हैं कि Bun ने इसे क्यों जोड़ा, लेकिन मुझे समझ आ रहा है कि यह सब कहाँ जा रहा है,
00:01:13और मैं आपको बाद में इसके बारे में थोड़ा बताऊंगा। लेकिन अभी के लिए, आइए कुछ डेमो देखते हैं कि कैसे इस्तेमाल करें
00:01:17Bun इमेज API का। और हम इसे मेरे ब्लॉग पर आजमाएंगे, जो एक स्टैटिक Waku साइट है, जिसमें
00:01:22कुछ बहुत बड़ी इमेजेस हैं। शुरुआत करने के लिए, आइए एक सरल स्क्रिप्ट देखते हैं जो एक इमेज को ऑप्टिमाइज़ करती है,
00:01:27जो मेरे चेहरे वाली प्रोफाइल पिक्चर है, और यह इसके साइज को 99% कम करने में सक्षम है, जो पागलपन है।
00:01:33आइए देखें कैसे। पहले, हम इमेज लेते हैं, और ध्यान दें कि हम यहाँ Bun.image का उपयोग कर रहे हैं, लेकिन आप
00:01:37इमेज फंक्शन के साथ Bun file भी कर सकते हैं। फिर हम इमेज का साइज घटाने के लिए उसे रिसाइज करते हैं, उसे 800 पिक्सल की चौड़ाई देते हैं,
00:01:43और ऊँचाई अपने आप आस्पेक्ट रेशियो के आधार पर कैलकुलेट हो जाती है। लेकिन अगर आप चाहें,
00:01:47तो हम यहाँ वह भी जोड़ सकते हैं। फिर हम इसे कम क्वालिटी के साथ WebP का आउटपुट फॉर्मेट देते हैं। बेशक,
00:01:52दूसरे आउटपुट फॉर्मेट्स भी सपोर्टेड हैं, और फिर हम नई इमेज को एक फाइल में आउटपुट करते हैं,
00:01:56जो एक प्रॉमिस है, और इसलिए इसके लिए await कीवर्ड की आवश्यकता होती है। और आप देख सकते हैं कि यह कितना सरल है।
00:02:01वास्तव में, यहाँ का सारा कोड अनावश्यक है, तो हम इसे हटाकर कोड को और भी सरल बना सकते हैं।
00:02:06हम एक रिसाइज फिल्टर भी सेट कर सकते हैं, रीसैंपलिंग कर्नल को बदलकर, इमेज के साइज को और कम कर सकते हैं।
00:02:10हम इमेज को रोटेट या फ्लिप कर सकते हैं, और यह वास्तव में कूल है। हम चमक (ब्राइटनेस) या
00:02:15सैचुरेशन भी बदल सकते हैं, जिससे कुछ अजीब दिखने वाली इमेजेस बन सकती हैं। लेकिन कुछ बहुत चतुर है जो
00:02:19आप धीमे कनेक्शन के मामले में कर सकते हैं, जो कि प्लेसहोल्डर फंक्शन का उपयोग करना है ताकि
00:02:23मुख्य इमेज लोड होने के दौरान अपने आप एक धुंधली इमेज दिखाई दे। और ऐसा करने के लिए, मेरे पास यह फॉर लूप है जो
00:02:29हर उस फाइल से गुजर रहा है जिसमें ये एक्सटेंशन हैं उस डायरेक्टरी के अंदर जिसमें
00:02:34सारी ब्लॉग इमेजेस हैं। तो हर इमेज रिसाइज हो रही है, बिना क्रॉप हुए स्केल डाउन की जा रही है, और
00:02:39अपस्केल नहीं की जा रही है। फिर हम हर इमेज के लिए एक प्लेसहोल्डर बनाते हैं, जो थंब हैश बनाता है, जिसका अर्थ है
00:02:45कि यह किसी भी इमेज को 28-बाइट हैश में एनकोड करता है, जो धुंधली इमेज प्लेसहोल्डर के रूप में एकदम सही है।
00:02:49यह हैश एक प्लेसहोल्डर ऑब्जेक्ट में जोड़ा जा रहा है, और फिर इसे एक फाइल में लिखा गया है,
00:02:53जो इस तरह दिखता है। अब, कारण यह है कि प्लेसहोल्डर एक बेस64 इमेज है न कि एक
00:02:58अलग छोटी WebP इमेज, ताकि नेटवर्क को इसे लाने के लिए कोई रिक्वेस्ट न करनी पड़े।
00:03:02तो मैं क्या कर सकता हूँ कि सभी प्लेसहोल्डर्स को इम्पोर्ट करूँ और उन्हें CSS में बैकग्राउंड इमेज के रूप में जोड़ दूँ,
00:03:07मुख्य इमेज के लोड होने का इंतज़ार करते हुए, जो मेरे ब्लॉग की हर इमेज के लिए काम करेगा।
00:03:11लेकिन अगर आप इसे MDX फाइल में एक सिंगल इमेज के लिए करना चाहते हैं, तो आप बस बेस64 कोड को
00:03:16मैन्युअली जोड़ सकते हैं, जो बिल्कुल वैसे ही काम करता है। ध्यान दें, आप इसी तरह का व्यवहार पा सकते हैं
00:03:20JPEG इमेजेस का उपयोग करके, progressive को true सेट करके। बेशक, और भी बहुत सी चीजें हैं जो BUN इमेज
00:03:24सपोर्ट करता है जिन्हें मैंने अभी तक नहीं देखा है, जैसे S3 कम्पैटिबल बकेट से इमेजेस पाना,
00:03:28या बकेट में इमेजेस लिखना, इमेज पाइपलाइन को वैध रिस्पॉन्स बॉडी के रूप में उपयोग करना,
00:03:33और फॉलबैक फॉर्मेट कॉन्फ़िगर करना अगर कोई विशिष्ट OS किसी एक को सपोर्ट नहीं करता है।
00:03:37तो क्या यह इस्तेमाल करने लायक है? खैर, अगर आप पहले से ही BUN पर हैं, तो हाँ, यह तो सोचने वाली बात ही नहीं है।
00:03:41लेकिन अगर आप Node का उपयोग कर रहे हैं, तो Sharp बहुत अच्छा काम करता है और पूरी तरह आजमाया हुआ है,
00:03:45और सिर्फ इमेज प्रोसेसिंग के लिए पूरी तरह से अलग रनटाइम पर बदलने की कोई जरूरत नहीं है।
00:03:49याद है जब मैंने कहा था कि एक बड़ा कारण है कि BUN ने इसे जोड़ा? खैर, अगर आप देखें कि BUN क्या कर रहा है
00:03:54पिछले साल से, इन-बिल्ट SQLite, S3, Postgres, और अब इमेजेस, और यह मूल रूप से
00:03:59वह सब कुछ है जो आपको फुल-स्टैक ऐप के लिए चाहिए, सिवाय शायद ऑथ और ईमेल के। लेकिन यह मुझे सोचने पर मजबूर करता है,
00:04:04क्या BUN, JavaScript के लिए Laravel या Rails बनाने की कोशिश कर रहा है, लेकिन रनटाइम लेवल पर? अगर वे ऐसा कर रहे हैं,
00:04:11तो अगली चीज जिस पर वे काम करेंगे वह है ऑथ। और अगर ऐसा है, तो याद रखें, आपने इसे यहाँ सबसे पहले सुना।
00:04:15लेकिन दुर्भाग्य से, आजकल, आप Zig से Rust के बड़े रीराइट का जिक्र किए बिना BUN के बारे में बात नहीं कर सकते,
00:04:20जो, उम्मीद है, अगले वर्ज़न में आ जाएगा। चलो आशा करते हैं कि सब कुछ ठीक हो जाए।
00:04:25Zig की बात करें तो, अगर आप Vercel के लैंग्वेज जीरो के बारे में और जानना चाहते हैं जो Zig जैसा दिखता है,
00:04:29पर Zig नहीं है, और AI एजेंट्स के लिए बना है, तो जेम्स का यह वीडियो देखें।