Bun.Image Membuat Seluruh Image Pipeline Anda Menjadi Usang
BBetter Stack
Computing/SoftwareInternet Technology
Transcript
00:00:00Ini adalah Bun Image, sebuah API pemrosesan gambar bawaan yang dirilis pada Bun 1.3.14 yang dapat mengubah ukuran,
00:00:06memotong, dan mengonversi gambar antar format yang berbeda tanpa dependensi native,
00:00:10dan semuanya berjalan di luar thread utama, artinya hal ini tidak akan memblokir server Anda saat sedang
00:00:14memproses. Tapi Bun sudah menjadi runtime, manajer paket, bundler, penguji kode,
00:00:19dan sekarang menjadi pemroses gambar? Apakah itu terlalu berlebihan, atau justru menandakan sesuatu
00:00:24yang lebih besar tentang arah tujuan Bun? Tekan subscribe dan mari cari tahu.
00:00:30Jika Anda pernah memproses gambar di server dengan JavaScript, Anda mungkin pernah menggunakan pustaka bernama
00:00:35Sharp bahkan tanpa menyadarinya, yang memiliki lebih dari 55 juta unduhan di npm setiap minggu, dan bahkan
00:00:41digunakan oleh Next.js di baliknya untuk optimasi gambar. Namun Sharp mengandalkan biner native bernama libvips,
00:00:47yang berarti setiap instalasi harus menarik build yang tepat untuk platform Anda. Dan jika Anda pernah mengalami
00:00:51build Docker atau pipeline CI yang gagal karenanya, Anda tahu persis betapa menyebalkannya hal ini. Jadi Bun memutuskan
00:00:57untuk langsung memasukkan pemrosesan gambar ke dalam runtime itu sendiri, dan kinerjanya sebenarnya lebih cepat daripada Sharp di
00:01:02sebagian besar tolok ukur. Pembacaan metadata tercatat 70 kali lebih cepat, dan pengubahan ukuran sekitar 30% lebih cepat. Sekarang banyak
00:01:08pengembang yang sangat bingung mengapa Bun menambahkan fitur ini, tetapi saya rasa saya paham arah tujuannya,
00:01:13dan saya akan menceritakannya sedikit nanti. Namun untuk sekarang, mari kita bahas beberapa demo tentang cara menggunakan
00:01:17API gambar Bun. Dan kita akan mencobanya pada blog saya, yang merupakan situs Waku statis, yang memiliki
00:01:22beberapa gambar berukuran sangat besar. Sebagai permulaan, mari kita lihat skrip sederhana yang mengoptimalkan satu gambar,
00:01:27yaitu foto profil dengan wajah saya, dan skrip ini mampu mengurangi ukurannya sebesar 99%, yang luar biasa.
00:01:33Mari kita lihat caranya. Pertama, kita ambil gambarnya, dan perhatikan kita menggunakan Bun.image di sini, tetapi Anda juga bisa menggunakan
00:01:37Bun file dengan fungsi image. Kemudian kita ubah ukuran gambar untuk memperkecil ukurannya, dengan memberikan lebar 800
00:01:43piksel, dan tingginya dihitung secara otomatis berdasarkan rasio aspek. Tetapi jika Anda mau,
00:01:47kita juga dapat menambahkannya di sini. Kita kemudian memberikan format keluaran WebP dengan kualitas yang dikurangi. Tentu saja,
00:01:52format keluaran lainnya didukung, dan kemudian kita mengeluarkan gambar baru ke sebuah file,
00:01:56yang berupa promise, sehingga memerlukan kata kunci await. Dan Anda bisa melihat betapa sederhananya ini.
00:02:01Faktanya, semua kode di sini tidak diperlukan, jadi kita bisa menghapusnya dan membuat kodenya menjadi lebih sederhana.
00:02:06Kita juga dapat mengatur filter pengubahan ukuran, mengubah kernel resampling, untuk semakin mengurangi ukuran gambar.
00:02:10Kita bisa memutar atau membalik gambar, dan ini sangat keren. Kita bahkan bisa mengubah tingkat kecerahan atau
00:02:15saturasi, yang dapat menghasilkan beberapa gambar dengan tampilan yang aneh. Tapi ada sesuatu yang sangat cerdas yang
00:02:19dapat Anda lakukan dalam hal koneksi lambat, yaitu menggunakan fungsi placeholder untuk otomatis
00:02:23menampilkan gambar buram sementara gambar utama sedang dimuat. Dan untuk melakukannya, saya memiliki perulangan for yang
00:02:29menelusuri setiap file yang berisi ekstensi ini di dalam direktori yang menampung semua
00:02:34gambar blog. Jadi setiap gambar diubah ukurannya, diskalakan turun tanpa dipotong, dan tidak
00:02:39diperbesar. Kemudian kita membuat placeholder untuk setiap gambar, yang menghasilkan thumb hash, artinya kode ini mengenkode
00:02:45gambar apa pun menjadi hash 28-byte, sangat sempurna sebagai placeholder gambar buram.
00:02:49Hash ini ditambahkan ke objek placeholder, lalu ditulis ke dalam file,
00:02:53yang tampak seperti ini. Alasan mengapa placeholder tersebut berupa gambar base64 alih-alih
00:02:58gambar WebP terpisah yang lebih kecil adalah agar jaringan tidak perlu membuat permintaan untuk mengambilnya.
00:03:02Jadi yang bisa saya lakukan adalah mengimpor semua placeholder dan menambahkannya sebagai gambar latar belakang di CSS,
00:03:07sambil menunggu gambar utama selesai dimuat, yang akan berfungsi untuk setiap gambar di blog saya.
00:03:11Namun jika Anda ingin melakukannya untuk satu gambar di file MDX, Anda bisa langsung menambahkan kode base64 tersebut
00:03:16secara manual, yang bekerja sama baiknya. Perhatikan, Anda juga bisa mendapatkan perilaku serupa menggunakan
00:03:20gambar JPEG dengan mengatur progressive ke true. Tentu saja, ada begitu banyak hal lain yang didukung oleh BUN image
00:03:24yang belum saya bahas, seperti kemampuan mengambil gambar dari bucket yang kompatibel dengan S3,
00:03:28atau menulis gambar ke bucket, menggunakan pipeline gambar sebagai isi respons yang valid,
00:03:33dan mengonfigurasi format cadangan jika OS tertentu tidak mendukung suatu format.
00:03:37Jadi, apakah ini layak digunakan? Nah, jika Anda sudah menggunakan BUN, maka ya, ini adalah pilihan yang sangat mudah.
00:03:41Tetapi jika Anda menggunakan Node, maka Sharp bekerja dengan sangat baik dan telah diuji di berbagai medan,
00:03:45dan tidak perlu beralih ke runtime yang sepenuhnya berbeda hanya untuk pemrosesan gambar.
00:03:49Ingatkah saat saya bilang ada alasan yang lebih besar mengapa BUN menambahkan ini? Nah, jika Anda melihat apa yang telah dilakukan BUN
00:03:54selama tahun lalu, SQLite bawaan, S3, Postgres, dan sekarang Gambar, dan itu pada dasarnya adalah
00:03:59semua yang Anda butuhkan untuk aplikasi full-stack, kecuali mungkin autentikasi dan email. Tapi ini membuat saya berpikir,
00:04:04apakah BUN sedang mencoba membangun Laravel atau Rails untuk JavaScript, tetapi di tingkat runtime? Jika ya,
00:04:11maka hal berikutnya yang akan mereka kerjakan adalah autentikasi. Dan jika itu benar, ingatlah, Anda mendengarnya di sini pertama kali.
00:04:15Namun sayangnya, saat ini, Anda tidak bisa membahas BUN tanpa menyebutkan penulisan ulang besar-besaran dari Zig ke Rust,
00:04:20yang semoga saja akan dirilis pada versi berikutnya. Mari kita harapkan semuanya berjalan lancar.
00:04:25Berbicara tentang Zig, jika Anda ingin mempelajari lebih lanjut tentang Language Zero Vercel yang mirip Zig,
00:04:29tetapi bukan Zig, dan dibangun untuk agen AI, tonton video dari James ini.