Deno 2.8

• deno add dan deno install kini secara default memperlakukan nama paket tanpa prefiks di CLI sebagai paket npm:, sehingga lebih mudah digunakan sebagai pengganti npm install, yarn, atau pnpm install pada proyek Node yang sudah ada
• deno audit fix secara otomatis meningkatkan paket npm yang rentan dalam dependensi ke versi patch terdekat yang masih memenuhi batasan versi, dan menampilkan secara terpisah item yang memerlukan perubahan versi mayor
• Subperintah baru deno ci, deno pack, deno transpile, deno why, dan deno bump-version ditambahkan untuk mendukung instalasi yang dapat direproduksi, pembuatan tarball untuk publikasi npm, konversi TS→JS, pelacakan jalur dependensi, dan pembaruan versi workspace
• Kompatibilitas API Node.js meningkat dari sekitar 42% pada Deno 2.7 menjadi 76.4% (3.405/4.457) pada Deno 2.8 berdasarkan test suite Node, dan banyak modul node: kini dimuat secara lazy sehingga startup program yang tidak memakai modul tersebut menjadi lebih cepat
• Performa dibandingkan Deno 2.7.1 menunjukkan instalasi npm cold meningkat 3,66x lebih cepat dari 3.319ms menjadi 906ms, node:buffer base64 membaik 3,07x, throughput node:http 2,21x, dan node:crypto scrypt 2,12x
• Perubahan kompatibilitas membuat global setTimeout dan setInterval mengembalikan objek Timeout milik Node alih-alih angka, sehingga kode yang menyimpan nilai kembalian sebagai number atau menggunakannya untuk pemeriksaan tipe maupun operasi aritmetika perlu diubah ke NodeJS.Timeout atau sejenisnya
• TypeScript 6.0.3 kini dibundel, dan deno check serta LSP secara default menyertakan lib.node sehingga tipe Node seperti NodeJS.*, Buffer, dan process dapat dikenali tanpa konfigurasi tambahan
• Dalam debugging, tab Network di Chrome DevTools kini menampilkan trafik fetch(), node:http/node:https, dan WebSocket milik Deno, sementara --cpu-prof, --cpu-prof-flamegraph, dan --cpu-prof-md dapat menghasilkan profil V8, flamegraph SVG, dan laporan Markdown
• Untuk manajemen paket dan workspace, ditambahkan protokol catalog:, deno install --os --arch, --prod, nodeModulesLinker: "hoisted", min-release-age di .npmrc, dan --package-json untuk membantu penyatuan versi monorepo, instalasi lintas platform, instalasi produksi, dan migrasi dari proyek Node lama
• deno compile dapat mendeteksi proyek Next.js, Astro, Fresh, Remix, SvelteKit, Nuxt, SolidStart, TanStack Start, dan Vite SSR untuk menjalankan deno task build serta membuat entry point yang sesuai, sekaligus menampilkan progres saat memproses pohon dependensi npm yang besar
• Pada pengujian dan Web API, nilai default sanitizeOps dan sanitizeResources di Deno.test() berubah menjadi false, ditambahkan timeout per test dan coverage tingkat fungsi, serta dukungan untuk OffscreenCanvas, Headers/Request/Response/Streams yang bisa ditransfer, digest SHA3, dan Web Crypto P-521
• Pada upgrade dan fondasi runtime, deno upgrade kini dapat memakai pembaruan delta untuk mengurangi ukuran unduhan dari sekitar 48MB menjadi 3~6MB jika memungkinkan, deno upgrade pr <number> dapat memasang build PR, dan V8 naik dari 14.6 ke 14.9

[GN⁺]

Komentar Hacker News

• Deno berguna karena punya model izin bawaan, ditulis dengan Rust, dan mendukung TypeScript secara native
  Saya tidak terlalu mendalami ekosistem web development/Node/Bun, tetapi selama beberapa tahun saya cukup puas memakai Deno untuk layanan kecil. Saya penasaran kenapa Bun tampak tumbuh begitu cepat. Saya tidak tahu apakah Bun terutama dipakai sebagai bundler dan lebih jarang dipakai sebagai runtime JavaScript
  Sistem izinnya saja sudah membuat Deno menarik, jadi saya kurang paham kenapa orang yang pindah dari Node ke Bun tidak sekalian ke Deno

  • Deno dan Bun punya fokus yang cukup berbeda saat dirilis. Deno adalah upaya Ryan, kreator asli Node, untuk memperbaiki banyak hal yang menurutnya salah di Node, sementara Bun sejak awal berfokus pada kompatibilitas Node dan menjalankan framework populer seperti Next.js
    Untuk waktu yang lama, banyak dependensi dan framework tidak berjalan dengan baik di Deno, dan pada awalnya bahkan belum ada fitur untuk memasang dependensi dari npm. Kalau melihat kembali berbagai serangan pada rantai pasok npm, bisa jadi Ryan memang benar
    Karena itu, Bun terlihat seperti Node yang lebih baik dengan lebih banyak fitur praktis, membutuhkan jauh lebih sedikit konfigurasi, dan langsung jalan. Tim Deno tampaknya juga menyadari bahwa untuk berhasil mereka butuh kompatibilitas Node, dan selama beberapa tahun terakhir mereka fokus ke sana. Menurut saya sekarang Deno bahkan lebih kompatibel dengan Node dibanding Bun
  • Saat memulai side project TypeScript kecil, Anda cukup memakai Bun saja alih-alih tenggelam di lautan npm/yarn/berry/pnpm/bubble/vite/webpack/rollup/rolldown/rollout/swc/esbuild/teatime
    Sebagai catatan, hanya sebagian dari daftar itu yang merupakan jurus Pokémon, sisanya adalah alat sungguhan di ekosistem JS/TS
  • Saya memakai dan menyukai keduanya. Bun lebih mendekati pengganti drop-in untuk Node
    Kalau saya tidak ingin repot mengutak-atik pengaturan test, tsconfig, atau ES module, biasanya Bun langsung jalan. Deno punya standard library yang bagus dan dukungan CLI yang sangat baik; dulu saya juga suka deno deploy, tetapi belakangan ini terasa cukup merepotkan
  • Saya kebanyakan developer backend, tetapi saat sesekali menyentuh frontend untuk proyek pribadi, Deno tampak seperti pilihan yang paling masuk akal
    Sangat menyenangkan untuk dipakai, dan sayang sekali belum lebih luas diadopsi di kalangan orang JS
  • Saya memakai Deno sekitar setahun dan menyukainya karena kelebihan-kelebihan yang disebut tadi, tetapi masalah kompatibilitas dengan paket seperti Astro, Prisma, dan Vite terlalu banyak
    Jadi saya pindah ke Bun, dan semuanya terasa jauh lebih mulus

• Saya penasaran bagaimana kondisi Deno belakangan ini
  Node adalah solusi yang stabil dan akan tetap ada. Sekarang TypeScript juga sudah bisa dipakai, dan tampaknya sebentar lagi aplikasi akan bisa dibangun menjadi satu executable tunggal, bahkan termasuk dependensi native
  Bun terasa kacau tetapi cepat, dan pendekatannya yang memasukkan segalanya ke standard library cukup menarik. Selain itu, perusahaan ini juga diakuisisi oleh Anthropic
  Deno dulu punya narasi menarik soal sandbox dan kemudahan mengimpor dependensi pihak ketiga, tetapi sekarang sandbox terasa sudah cukup umum, dan saya juga tidak yakin model import-nya pada akhirnya jauh lebih baik daripada npm add

  • Deno memecat sekitar setengah karyawannya kira-kira 2 bulan lalu: https://news.ycombinator.com/item?id=47467746
  • Siapa yang menganggap diakuisisi Anthropic itu hal positif?
  • Agar ekosistem tidak stagnan, bagus jika ada beberapa pilihan
  • Distribusi single executable sebenarnya sudah memungkinkan. CLI produk saya adalah aplikasi single executable Node
  • Saya tidak tahu kalau build single executable yang menyertakan dependensi native akan jadi mungkin. Itu fitur yang sangat kuat

• Deno itu luar biasa. Saya menulis layanan web kecil dan menengah dengan Deno
  Semuanya berjalan seperti jam Swiss, dan filosofi proyeknya juga sangat cocok dengan semangat Unix
  Secara pribadi saya merasa orang-orang yang membuat Deno agak terlalu rendah hati. Bahkan ketika pengguna yang berterima kasih menawarkan donasi ke proyek, mereka menolaknya dengan sopan. Saya paham alasannya, tetapi dalam jangka panjang ini bisa menimbulkan tekanan finansial yang tidak perlu bagi proyek
  Langganan bulanan semacam “tolong terima uang saya” untuk pengguna yang bergantung pada keberhasilan jangka panjang proyek mungkin sangat cocok

  • Benar-benar menyenangkan untuk dipakai. Rasanya hampir seperti campuran JavaScript dan Go
    Cepat dan fleksibel, dengan manajemen paket yang sedikit lebih waras dan lebih kuat daripada alternatif JS/TS lain, model keamanan yang lebih baik, standard library yang lebih baik, dan juga sangat cepat

• Untuk yang belum akrab dengan nama Deno, Deno adalah runtime JavaScript dan TypeScript
  Ada ulasan yang membandingkan Deno 2.6 dengan pesaingnya Bun 1.3 dan Node.js 25: https://www.devtoolreviews.com/reviews/bun-vs-node-vs-deno-2...

  • Mengejutkan bahwa Bun bisa jauh lebih cepat dalam menangani web request. Artikel itu menyebut Zig sebagai faktor, tetapi saya penasaran apakah kontrol memori yang lebih rinci saja bisa memberi keuntungan lebih dari 2x dibanding Node
    Mirip dengan itu, meski tidak dijelaskan secara eksplisit, Bun tampaknya dijalankan dengan package cache yang sudah hangat. Saya penasaran apakah runtime lain juga punya cache saat diuji

• Siklus rilis yang konsisten dari Deno mengesankan. Saya menantikan peningkatan performa apa saja yang masuk di versi ini

• Perintah baru deno pack adalah tambahan yang bagus untuk packaging yang aman dan sederhana
  Jika memakai Node.js, perintah tunggal serupa bisa dilakukan dengan https://www.npmjs.com/package/ts-node-pack
  Sekarang karena Node.js mendukung import modul .ts, lebih banyak repositori bisa memakainya tanpa tahap build atau tanpa menyertakan hasil build di checkout

  • Membaca posting blog ini langsung membuat saya berpikir. deno pack mungkin bisa menggantikan alur npm publish yang sudah ada untuk paket open source saya, dan cocok untuk terus menggeser pekerjaan menjadi Deno-first / Deno-centric
    Di sisi lain, karena dukungan TypeScript di Node makin besar, beralih ke paket npm khusus TypeScript juga bisa menjadi sinyal kecil yang saya kirim ke ekosistem
    Meski begitu, saya tetap senang JSR ada sebagai ekosistem yang relatif lebih bersih
  • Kedengarannya cukup mirip dengan DNT yang sudah ada sejak lama (https://github.com/denoland/dnt)
    Hanya saja, ketika masuk ke Deno CLI, visibilitasnya meningkat jauh

• Kalau Deno sedikit lebih lama mempertahankan nilai awalnya, tekanan untuk kompatibilitas Node mungkin bisa sedikit tertutupi oleh AI agent
  Sebagian besar tekanan itu muncul dari masalah familiaritas. Jika Anda hanya tahu cara mengatur semuanya dengan express.js, Anda akan merasa bahwa alat atau runtime apa pun setelahnya juga harus menyediakan abstraksi yang serupa agar transisinya terasa “mulus”. Terlepas dari seberapa buruk solusi pertama itu sebenarnya
  Sekarang kita bisa memperkenalkan teknologi baru kepada developer sambil mengirimkan bundel teknis yang diperlukan bersama produknya, dan ini kadang benar-benar bisa menggantikan dokumentasi serta cukup baik dalam menunjukkan pendekatan alternatif yang lebih baik

  • Jika SDK JS/TS yang saya terima dari vendor SaaS tidak bisa berjalan di Deno tanpa modifikasi, saya tidak akan menghabiskan satu detik pun untuk memperbaikinya

• Dari pengalaman memakai Deno di berbagai proyek hobi, saya yakin Deno adalah arah yang seharusnya dituju ekosistem JS
  Hanya saja, untuk direkomendasikan di pekerjaan di luar use case tertentu yang mayoritas cakupannya sempit, situasinya rumit. Pada titik tertentu, kalau arah proyek berubah karena alasan bisnis, pada akhirnya Anda akan butuh Node

• Sejak peluncuran Edge.js [1], senang melihat Deno mulai menangani kompatibilitas Node.js dengan lebih serius
  Dalam sekitar 2 bulan saja naik dari kisaran 40% ke sekitar 75%, jadi entah kebetulan atau tidak, ini jelas langkah ke arah yang benar
  Kerja bagus untuk seluruh tim Deno
  [1] https://edgejs.org/

  • Tidak bosan ya promosi diri terus?

• Saya membungkus sebagian besar idiom ala Node dan memakai Deno sebagai runtime. Berjalan dengan baik
  Jika proyeknya pure TypeScript, saya langsung menjalankannya dengan Deno. Opsi tambahan untuk keamanan juga bagus, dan saya suka bahwa script instalasi dinonaktifkan secara default
  Kalau Anda masih memakai Node secara langsung, sebaiknya berhenti. Minimal pakai Bun menurut saya lebih baik
  Untuk pekerjaan berbasis agent, hampir tidak ada alasan memakai selain Rust dan TypeScript. Orang boleh tidak setuju, tetapi type safety, memory safety, dan korpus kerja yang besar itu penting. Agent lebih mudah menavigasi bila ada error yang tegas dan pola-pola bawaan. Untuk UI, TypeScript paling masuk akal karena contoh desainnya sangat banyak