- Baru-baru ini muncul kritik dan kekhawatiran tentang momentum Deno Deploy, KV, Fresh, serta perusahaan dan proyek secara keseluruhan
- Sebagian kritik tersebut valid, dan karena progres internal tidak cukup dibuka secara transparan, kebingungan pun ikut membesar; namun banyak dari rumor dan kritik ini hanyalah spekulasi tanpa dasar atau informasi yang tidak sesuai fakta
- Sejak peluncuran Deno 2 (setelah Oktober 2023), tingkat adopsi berdasarkan metrik pengguna aktif bulanan telah naik lebih dari 2x lipat
- Kompatibilitas Node yang kuat di Deno 2 menghilangkan hambatan besar dalam penerapan nyata, dan platform kini menjadi lebih cepat, lebih kuat, dan lebih sederhana
Perubahan dan evolusi Deno Deploy
- Salah satu pertanyaan yang paling sering muncul adalah alasan di balik pengurangan region yang tersedia di Deno Deploy baru-baru ini
- Di balik pengurangan ini, selain biaya, ada juga perubahan pada pola penggunaan dan kebutuhan nyata
- Untuk sebagian besar aplikasi, yang penting bukan semua region, melainkan kecepatan, debug, dan kepatuhan di wilayah yang dekat dengan data
- Sejak Deploy dirilis, jumlah region berubah dari 25 menjadi 35, dan kini menjadi 6 region
- Banyak region yang nyatanya hampir tidak digunakan, dan penyebaran yang terlalu luas justru menurunkan performa (latensi, masalah kapasitas)
- Tim sedang membangun kembali visi “edge” yang lebih realistis dan sesuai dengan kebutuhan pengguna
- Versi baru Deploy sedang dikembangkan, dan platform berevolusi untuk mengarah ke hosting aplikasi secara penuh
- Akan mendukung subproses, background job, OpenTelemetry, build pipeline, region self-hosted, dan lainnya
- Dalam waktu dekat akan disediakan fitur untuk mengunci aplikasi ke region tertentu atau menjalankannya di cloud milik sendiri
Arah Deno KV (penyimpanan key-value)
- Deno KV adalah store dengan API sederhana yang menyediakan tanpa perlu konfigurasi, konsistensi global terjamin, serta fitur real-time
- Cocok untuk data sesi, feature flag, status kolaborasi, dan sebagainya, tetapi bukan untuk database serbaguna
- Untuk kebutuhan pengelolaan data yang lebih luas, ada dua upaya yang sedang dijalankan
- Memperkuat integrasi database relasional yang sudah ada di dalam Deno Deploy
- Mendorong proyek baru untuk menyederhanakan keterkaitan compute dan state (terinspirasi dari Cloudflare Durable Objects)
- Sesuai arah tersebut, KV akan tetap berstatus beta, dan hanya bug besar/isu keamanan yang akan terus ditangani
- Peran sebagai pusat solusi manajemen state secara keseluruhan atau peran yang lebih berkembang ke depannya kemungkinan akan diambil alih oleh proyek lain
Status framework Fresh
- Fresh masih menjadi fondasi semua aplikasi dan web internal, dan tetap dipelihara/dikembangkan secara aktif
- Tim menyadari ekspektasi besar dan masa tunggu yang panjang untuk Fresh 2
- Alih-alih merilisnya dengan tergesa-gesa, prioritas diberikan pada pemantapan kualitas dasar dan perapian strukturnya
- Silakan lihat tulisan blog terkait rincian peningkatan yang diumumkan baru-baru ini
- Rilis Fresh 2 yang stabil dijadwalkan pada tahun ini
Deno, platform yang lebih dari sekadar runtime
- Deno bukan sekadar runtime, melainkan platform sistem JavaScript yang lengkap
- Dengan satu rangkaian alat, berbagai hal seperti menulis, menjalankan, menguji, menerapkan, dan memantau dapat dilakukan secara terpadu
- Integrasi, konfigurasi bawaan, flag, dan konektivitas antaralat terus diperkuat
- Tujuannya bukan sekadar kesetaraan fitur, melainkan membangun ekosistem yang terintegrasi
- Deno mengarah pada peningkatan kualitas esensial dalam pengembangan JavaScript, dan menantang perluasan cakupan untuk mewujudkannya
Tujuan dan alasan platform ini
- Bahasa skrip memainkan peran yang tak tergantikan dalam pengembangan praktis yang cepat
- Masa depan JavaScript semakin cerah dari sisi standardisasi, ekosistem besar, dan skalabilitas serbaguna
- Diperlukan platform “battery-included”, dan Deno mengarah ke sana (manajemen izin, web server, observability, lint, type check, dll. disediakan secara bawaan)
- Deno memberikan pengalaman yang terpadu alih-alih alat yang terpecah-pecah
Rencana ke depan dan penguatan komunikasi
- Deno sedang memasuki fase ekspansi, bukan penyusutan
- Kecepatan, kompatibilitas, dan kematangan platform terus ditingkatkan, dan tata kelola independen JSR juga terus tumbuh
- Berbagai aktivitas untuk ekosistem JavaScript juga dijalankan bersamaan, termasuk kolaborasi komunitas seperti TC39/ WinterTC
- Berdasarkan pengalaman dari Deploy dan KV, pengembangan produk baru yang berkelanjutan dan terdistribusi sedang berlangsung, dan kabar tambahan akan segera diumumkan
- Untuk mengurangi kontroversi atau ketidakpercayaan, komunikasi akan lebih diperkuat, dan kepercayaan dengan para developer akan menjadi prioritas
3 komentar
Kalau begitu, apakah bun lebih baik daripada deno?
Rumor tentang kemunduran Deno sangat dibesar-besarkan
Sepertinya ini adalah tanggapan terhadap tulisan itu.
Saya juga mengunggah penjelasan terpisah tentang mengapa update Fresh terlambat: Update Fresh 2, framework web Deno
Komentar Hacker News
Tampaknya sudah jelas sejak awal bahwa kebanyakan developer tidak hanya men-deploy fungsi stateless sederhana, melainkan umumnya membangun aplikasi nyata yang berkomunikasi dengan database seperti aplikasi full-stack. Rasanya agak wajar kalau kesadaran ini baru datang sekarang
Ada persepsi bahwa belakangan muncul opini kritis terhadap Deno, Deploy, KV, Fresh, dan laju pertumbuhannya secara umum. Untuk kritik soal pertumbuhan, saya tidak melihat ada penyebutan atau jawaban khusus, jadi saya bertanya-tanya apakah itu disengaja. Karena mereka mengatakan sebagian kritik itu valid, menurut saya tingkat kepercayaannya akan lebih tinggi kalau mereka juga mengungkap kritik mana yang valid dan bagaimana rencana mereka menanganinya. Saya justru melihat perusahaan yang jujur mengakui kekurangannya sebagai nilai positif dalam pengambilan keputusan. Saya pernah menyukai pendekatan Migadu yang secara transparan menjelaskan kelebihan/kekurangan lewat halaman pro/con mereka
Alasan saya dulu menaruh harapan pada Deno adalah karena ia bisa memulai ulang dengan bersih dan kompleksitas yang lebih rendah tanpa terobsesi pada kompatibilitas dengan yang lama. Memang ada beberapa hal baru yang kurang nyaman dibanding Node, tetapi rasanya masih bisa ditoleransi. Namun, alih-alih menghadirkan solusi khasnya sendiri, Deno makin terikat pada kompatibilitas dengan Node, dan sekarang menurut saya malah menjadi struktur ganda yang terasa lebih rumit daripada Node. Paket Node memang seharusnya bisa berjalan mulus di Deno, tetapi ada banyak edge case yang tidak bekerja karena API tertentu belum diimplementasikan atau karena bug. Framework pengujian favorit saya, AVA, juga masih belum didukung. Dulu saya bisa mengabaikan lapisan kompatibilitas npm dan hanya memakai Deno itu sendiri, tetapi sekarang makin merepotkan. Hanya dengan melihat opsi command line saja, kompleksitasnya meningkat drastis dalam beberapa tahun terakhir, dan sebagian besar itu demi integrasi npm sehingga bagi saya hanya menjadi informasi yang tidak perlu. Hal yang paling saya inginkan dari kompatibilitas Node justru dukungan konfigurasi ESLint di Deno linter, tetapi tampaknya itu tidak menjadi perhatian. Meski begitu, saya tetap ingin Deno berhasil karena ia mendorong perbaikan di Node. Hanya saja, arah Deno saat ini tidak terasa konsisten dengan tujuan awalnya
Saya merasa Deno telah kehilangan arah. Awalnya posisinya sederhana: runtime JS/TS yang aman dan cepat, dibuat dengan Rust. Sekarang, di dropdown ‘Products’ pada situs webnya, berbagai produk ditambahkan secara semrawut. Rasanya seperti mencoba meniru cara Vercel membangun platform deploy setelah NextJS
Sejak Deno menambahkan kompatibilitas dengan Node dan meninggalkan janji awalnya, ekspektasi saya lenyap. Bagi saya, daya tarik inti Deno adalah menghapus kompleksitas yang tidak diinginkan dan warisan masa lalu dari Node, tetapi sekarang tidak banyak yang membedakannya dari Node selain beberapa hal kecil seperti built-in TypeScript dan permission. bun.sh juga menyediakan kompatibilitas Node. Saya penasaran apakah ada yang tahu mesin scripting TypeScript sisi server yang tidak mengejar kompatibilitas Node
Kompatibilitas npm adalah penambahan fitur, jadi saya tidak merasa kita benar-benar kehilangan sesuatu karenanya. Kita tetap tidak harus memakai API Node, dan cukup menggunakan library yang diinginkan dari jsr.io saja. Dalam praktiknya, pengalaman pengembangan yang berbeda dari Node masih bisa dinikmati di Deno. Namun, tidak banyak orang yang menginginkan ‘kemurnian’ sepenuhnya, jadi menurut saya lebih baik memilih popularitas dan kepraktisan
Ada keraguan mengapa seseorang mencari runtime TypeScript yang tidak mengejar kompatibilitas Node. Node memang punya banyak masalah, tetapi tetap cukup layak sehingga dipakai luas secara umum. Untuk membuat alternatif yang praktis, harus ada (1) keunggulan yang cukup besar sampai layak menanggung migrasi skala besar, atau (2) setidaknya biaya migrasi minimal dengan peningkatan yang jelas dalam performa, keandalan, atau usability. Namun Deno justru serba tanggung dalam dua hal itu. Ia tidak bisa menjalankan kode Node lama apa adanya, sementara keunggulan inovatifnya juga tidak cukup kuat, sehingga pendekatan ini terasa terbatas hanya menarik ‘idealis’ atau ‘developer hobi’
Sebagai runtime TypeScript yang tidak mengejar kompatibilitas Node, yang terlintas adalah Cloudflare Workers workerd, tetapi pada dasarnya itu bukan runtime backend serbaguna, dan secara praktis hampir tidak menyediakan paket dasar atau fitur bawaan
Saya pribadi lebih suka memakai JSDoc. Itu tidak terkait Node, tetapi memberi manfaat serupa tanpa kompleksitas rantai kompilasi
Jika di backend tidak perlu terikat pada JS, maka cukup masuk akal untuk mempertimbangkan alternatif yang lebih baik daripada TypeScript. Jika seluruh stack bisa dikendalikan, tidak ada alasan kuat untuk tetap bertahan pada bahasa compile-to-JS
Saya rasa tulisan terbaru ini mungkin merupakan respons terhadap https://news.ycombinator.com/item?id=43863937
Ini memang tulisan yang dibuat CEO, tetapi lebih berfokus pada pembenaran keputusan internal daripada kritik spesifik terhadap Deno. Meski begitu, kesannya lini produk Deno bekerja cukup baik di lingkungan Deno
Saya masih belum punya rasa percaya atau keyakinan. Kita sepertinya akan segera tahu bagaimana hasil Deploy, tetapi kalau KV memang tidak ada niat pengembangan lebih lanjut setelah tahap beta, menurut saya sama sekali tidak ada alasan memakainya untuk proyek baru. Fresh katanya akan di-refactor menjadi alpha sekitar akhir Q3, tetapi pada dasarnya framework itu selama ini hanya menyediakan hal-hal dasar, dan bahkan struktur tanpa build/compile yang dulu cukup menonjol pun akan hilang. Runtime-nya memang masih terus dikembangkan, tetapi menarik bahwa release note-nya sangat berfokus pada kompatibilitas Node/NPM, sampai terasa bertolak belakang dengan pernyataan bahwa mereka “tidak mengejar kesetaraan fitur dengan runtime lain”
Keputusan menghentikan pengembangan KV secara berkelanjutan menurut saya benar-benar pilihan yang buruk. Masalah perusahaan tidak memakai KV bukan karena fiturnya jelek, melainkan karena label beta-nya. Saya sendiri cukup banyak memakai Cloudflare Workers KV dan tidak terlalu tertarik pada Durable Objects, jadi dulu saya menaruh harapan pada Deno KV, tetapi sekarang tampaknya harus dikeluarkan dari daftar pertimbangan. Mengumumkan produk baru lalu langsung membiarkannya terbengkalai juga memberi kesan yang sangat buruk secara strategis
Saya sempat mempertimbangkan memakai KV, tetapi karena tidak melihat prospeknya, akhirnya mulai mencari alternatif lain
Saya penasaran apakah fakta bahwa kebanyakan developer men-deploy bukan fungsi stateless sederhana melainkan aplikasi full-stack yang terhubung erat dengan database sebenarnya berlaku untuk kubu serverless secara umum. Kalau memang begitu, apakah itu sesuai dengan niat awal gerakan serverless, atau sebenarnya hanya dipilih untuk menghindari infrastruktur rumit seperti Docker/Kubernetes
Dijelaskan bahwa Deno Deploy sering mendapat pertanyaan tentang berkurangnya jumlah region. Pihak Deno menjelaskan arah optimasinya dengan mengatakan bahwa sebagian besar aplikasi tidak perlu berjalan di semua tempat di dunia; yang penting cepat di dekat data, mudah di-debug, dan cukup sesuai dengan regulasi lokal. Namun saya sendiri tidak memakainya karena lokasi region Deno Deploy pada praktiknya tidak cukup dekat sehingga saya khawatir soal performa. Sudah ada banyak opsi yang lebih dekat dengan data dan pengguna, dan kepatuhan regulasi pun di kebanyakan kasus cukup dipenuhi pada tingkat negara, jadi menurut saya arah optimasi ini tidak terlalu meyakinkan