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 एजेंट्स के लिए बना है, तो जेम्स का यह वीडियो देखें।
Community Posts
No posts yet. Be the first to write about this video!
Write about this video