Saya khawatir dengan Bun

 (wwj.dev)
4 poin oleh GN⁺ 7 jam lalu | 3 komentar | Bagikan ke WhatsApp
  • Bun adalah runtime JavaScript yang cepat sekaligus alat yang memudahkan pekerjaan TypeScript, tetapi setelah diakuisisi Anthropic pada Desember 2025, kekhawatiran makin besar bahwa ia bisa terdampak oleh kebijakan produk dan cara operasional Anthropic
  • Dalam pengumuman akuisisi disebutkan bahwa Bun akan tetap open source dengan lisensi MIT, dikembangkan oleh tim yang sama, dan karena Claude Code didistribusikan sebagai executable Bun, Anthropic disebut punya insentif langsung untuk menjaga Bun tetap stabil
  • Sejak April 2026, Claude Code menuai masalah seperti penurunan kualitas, perilaku yang dibatasi, pembatasan harness pihak ketiga, kebingungan penagihan, dan komunikasi yang lambat; engineering postmortem milik Anthropic menyebut penyebabnya sebagai masalah di lapisan produk seperti penurunan nilai effort penalaran default dan perubahan prompt
  • Menurut laporan TechCrunch dan Gigazine, Claude Code dapat meminta biaya tambahan untuk dukungan harness pihak ketiga seperti OpenClaw, atau bahkan menolak permintaan maupun memicu biaya tambahan hanya karena ada penyebutan OpenClaw di riwayat git, sehingga memperlihatkan perilaku tak terduga
  • Kecemasan ini bukan karena kualitas Bun sendiri atau tim Bun, melainkan kemungkinan bahwa kebijakan Anthropic akan meresap ke Bun; akibatnya, sebagian proyek mulai beralih ke pnpm untuk manajemen paket dan kini lebih cenderung merekomendasikan pnpm untuk proyek JavaScript dan TypeScript baru

Latar belakang meningkatnya kekhawatiran terhadap Bun

  • Bun adalah runtime JavaScript yang cepat dan praktis, yang memudahkan pekerjaan TypeScript untuk skrip kecil, aplikasi, pengujian, dan alat
  • Karena instalasi cepat, pengujian cepat, bundling yang lebih baik, dan beban toolchain yang lebih ringan, Bun diharapkan sukses sebagai alternatif Node.js
  • Inti kekhawatiran bukan pada kualitas Bun itu sendiri, melainkan pada kemungkinan Bun terdampak oleh Anthropic setelah masuk ke dalam perusahaan tersebut, baik dari sisi kebijakan produk maupun cara operasionalnya

Akuisisi Anthropic dan harapan awal

  • Anthropic mengakuisisi Bun pada Desember 2025
  • Menurut pengumuman akuisisi, Bun akan tetap open source dengan lisensi MIT, terus dikembangkan oleh tim yang sama, dan roadmap-nya tetap berfokus pada alat JavaScript berperforma tinggi serta kompatibilitas Node.js
  • Pengumuman itu memuat kalimat: “Claude Code ships as a Bun executable to millions of users. If Bun breaks, Claude Code breaks. Anthropic has direct incentive to keep Bun excellent.”
  • Saat itu, karena Claude Code berjalan di atas Bun, masuk akal untuk melihat bahwa Anthropic memiliki insentif langsung untuk menjaga Bun tetap cepat dan stabil
  • Logika itu masih berlaku sekarang, tetapi mulai muncul kekhawatiran karena terlihat retakan dalam cara Anthropic mengoperasikan produk perangkat lunaknya

Perubahan penilaian terhadap Claude Code

  • Kualitas model Anthropic sendiri bukan kekhawatiran utamanya
  • Keluarga model yang diperkirakan sebagai Claude Opus 4.6 masih dinilai bagus untuk coding, menulis, penalaran, dan tugas pengembangan umum
  • Masalahnya ada pada lapisan produk di sekitar model, dan penilaian utamanya adalah bahwa pengalaman menggunakan Claude Code kini jauh memburuk
  • Sekitar setahun lalu, Claude Code terasa seperti alat yang bisa membaca proyek, membuat perubahan yang terfokus, menjalankan perintah, memperbaiki kesalahan, lalu terus melanjutkan pekerjaan
  • Saat itu, Claude Code adalah salah satu alat coding AI awal yang memberi keyakinan bahwa workflow developer bisa bergeser dari berpusat pada autocomplete menjadi berpusat pada agen
  • Bahkan pada Desember 2025, Claude Code sebenarnya sudah mulai memburuk, tetapi masih cukup berguna; akuisisi Bun juga masih dapat dipahami dari sudut pandang bahwa Anthropic sedang membangun masa depan alat coding

Masalah Claude Code sejak April 2026

  • Sejak April 2026, developer mulai mempermasalahkan kualitas Claude Code, perilaku pembatasan, pembatasan harness pihak ketiga, penagihan yang membingungkan, dan komunikasi yang lambat
  • Anthropic merilis engineering postmortem, dan menyebut penyebabnya sebagai masalah lapisan produk seperti penurunan nilai effort penalaran default, bug sesi lama, dan perubahan prompt yang merusak kualitas coding
  • Analisis pasca-insiden ini dinilai lebih baik daripada berpura-pura tidak terjadi apa-apa, dan dipandang sebagai salah satu kasus langka ketika Anthropic mengakui tanggung jawabnya sendiri
  • Menurut laporan TechCrunch, Anthropic memberi tahu pelanggan Claude Code bahwa mereka harus membayar biaya tambahan untuk dukungan OpenClaw dan harness pihak ketiga lainnya
  • Menurut laporan Gigazine, hanya dengan adanya OpenClaw di riwayat git saja, Claude Code dapat menolak permintaan atau memicu biaya tambahan
  • Laporan tersebut mengutip pernyataan Theo bahwa hanya karena OpenClaw disebut dalam commit terbaru di dalam JSON blob, perilaku itu bisa terpicu bahkan saat memanggil claude -p "hi" secara langsung di repositori kosong
  • Adegan terkait juga bisa dilihat dalam klip video
  • Perilaku seperti ini membuat produk tersebut tampak seperti perubahan yang dirilis tanpa benar-benar cukup dipakai secara internal pada level pengalaman penggunaan kode yang nyata
  • Dari luar, Claude Code tampak bergerak ke arah yang salah: lebih banyak pembatasan, penagihan aneh, dan perilaku tak terduga yang berubah tergantung teks commit
  • Arus seperti ini digambarkan sebagai enshittification

Kecemasan yang merambat ke Bun

  • Bun tertanam cukup dalam di Claude Code, dan karena Claude Code tampak memburuk, muncul kekhawatiran bahwa Bun bisa mengikuti arah yang sama
  • Ini bukan berarti Bun buruk atau tim Bun kehilangan minat
  • Masalahnya adalah semakin Bun dan tim Bun terintegrasi dengan Anthropic, semakin mungkin kebijakan Anthropic ikut masuk bersamanya
  • Jika kebijakan yang tampaknya merusak Claude Code juga memengaruhi Bun, maka di Bun pun bisa muncul masalah yang membuat timnya terlihat seperti tidak benar-benar memakai produknya sendiri
  • Hanya kemungkinan itu saja sudah membuat sebagian proyek sulit merasa yakin untuk terus memakai Bun

Untuk sementara berpindah ke pnpm

  • Bun menyediakan lebih banyak fungsi dalam satu alat dibanding pnpm
  • Bun mendukung TypeScript tanpa tahap build terpisah, menyediakan bundler sebagai pengganti Vite, dan menyediakan fitur testing sebagai pengganti vitest
  • Fakta bahwa semua fungsi itu disatukan dalam satu toolchain memang merupakan keunggulan besar
  • pnpm bukan pengganti Node.js maupun Bun; ia hanyalah package manager
  • Namun jika dalam pekerjaan sehari-hari bagian Bun yang paling sering dipakai adalah manajemen paket, maka instalasi cepat, dukungan monorepo yang baik, dan penggunaan disk yang masuk akal sama-sama disediakan oleh Bun maupun pnpm
  • Karena itu, sebagian proyek yang saat ini memakai Bun memilih keluar dari Bun dan berpindah ke pnpm
  • Untuk pertanyaan tentang apa yang direkomendasikan saat ini bagi proyek JavaScript atau TypeScript, jawabannya adalah pnpm

Ini bukan anjuran untuk meninggalkan Bun

  • Meskipun beberapa proyek dipindahkan dari Bun, ini tidak perlu dianggap sebagai jawaban umum yang berlaku untuk semua orang
  • Untuk proyek baru, pnpm masuk akal
  • Untuk proyek yang sudah ada, tetap memakai Bun juga merupakan pilihan yang valid sampai ada alasan yang cukup kuat untuk pindah

Kemungkinan yang tersisa dan kesimpulan

  • Harapannya adalah Bun tetap luar biasa, tim Bun terus menghasilkan kerja yang baik, dan Anthropic memberi mereka otonomi agar bisa mengambil keputusan yang sesuai dengan ekosistem JavaScript
  • Anthropic memiliki uang, kemampuan distribusi, dan alasan nyata untuk peduli pada performa serta stabilitas Bun
  • Bun masih bisa saja menjadi lebih kuat setelah melewati situasi ini
  • Namun, tingkat kepercayaan terhadap situasi saat ini lebih rendah dibandingkan pada Desember 2025
  • Dulu Claude Code tampak seperti bukti bahwa Anthropic memahami alat developer, tetapi sekarang ia lebih terlihat sebagai peringatan bahwa Anthropic mungkin tidak memahami apa yang dibutuhkan untuk menjaga dan meningkatkan produk dalam jangka panjang
  • Bun masih luar biasa, tetapi sulit mengetahui ke mana arahnya nanti
  • Karena situasinya bisa berubah total dalam satu tahun, ada rencana untuk meninjau lagi nanti apakah prediksi ini terbukti benar

Bacaan terkait

3 komentar

 
click 3 jam lalu

Saya akui berkat bun, node juga banyak berubah, tetapi melihat AI saling bikin PR dan saling meramaikan di repositori membuat saya takut menginjak ranjau regresi yang membuat hal yang tadinya jalan jadi tidak jalan.
Sebelum diakuisisi anthropic saya sempat memakai bun sebagai yang utama, tetapi sekarang saya kembali lagi ke node.
Saya masih menganggap fitur sfx sebagai killer feature, tetapi kalau itu tidak dibutuhkan, saya kurang paham alasan untuk harus langsung memakai bun.
 
GN⁺ 7 jam lalu
Opini Hacker News

  • Saya tidak setuju dengan premis keseluruhannya: bahkan sebelum diakuisisi, Bun pada akhirnya memang harus mencari cara monetisasi
    Hanya karena perusahaan induknya menunjukkan praktik buruk pada perangkat lunak lain, yaitu Claude Code, bukan berarti Bun otomatis akan menjadi lebih buruk juga. Kekhawatiran itu bisa dipahami, tetapi saya masih optimistis soal Bun
    Claude Code adalah produk inti Anthropic dan pertumbuhannya sangat cepat, jadi perubahan kecil pun bisa langsung menimbulkan masalah penagihan. Sementara itu, Bun adalah runtime JavaScript yang bisa fokus menjadi runtime terbaik, dan tidak berdampak langsung pada pendapatan atau laba-rugi Anthropic, jadi tidak terlalu perlu mengeluarkan patch tergesa-gesa karena penyalahgunaan seperti Claude Code
    Masih belum jelas akan seperti apa beberapa tahun ke depan, tetapi tepat setelah akuisisi ini saya tidak terlalu khawatir

    • Menarik melihat orang begitu cepat menerima penjelasan soal penyalahgunaan. Sudah lama diketahui bahwa lab AI besar tidak bisa memperoleh keuntungan secara finansial dari pengguna langganan berat, terlepas dari agen atau alat eksekusi apa yang dipakai. Harga yang adil dan menguntungkan adalah penagihan token berbasis pemakaian
      Lab-lab ini ingin mematikan persaingan karena alat eksekusi pihak ketiga berisiko mengubah model bahasa besar dasar menjadi komoditas umum, dan pada saat yang sama mereka sedang bermain chicken game untuk melihat siapa yang bisa paling lama menanggung rugi
      Pada akhirnya mereka harus menetapkan harga produk dengan benar, dan sampai saat itu mereka hanya bisa berharap semua pesaing sudah dimatikan. Namun tampaknya mereka sudah kalah dalam permainan itu. Model yang berguna makin kecil tiap tahun dan biaya menjalankannya juga turun, sehingga sudah melewati titik kritis di mana alat eksekusi pihak ketiga bisa terus dikembangkan bahkan tanpa basis pengguna langganan
      Taruhan inti mereka, yaitu bahwa “AI yang berguna memerlukan perangkat keras yang sangat mahal”, sudah gagal, dan taruhan kedua—mengunci pengguna ke dalam ekosistem lalu memonetisasinya nanti—juga akan gagal. Pada akhirnya mereka harus bersaing hanya lewat kemampuan produknya sendiri, dan itu jauh kurang menguntungkan
    • Saya rasa gagasan bahwa “bahkan sebelum akuisisi, Bun pada akhirnya harus mencari cara monetisasi” sendiri tidak masuk akal. Sudah aneh bahwa orang menjadi bergantung pada runtime JavaScript yang suatu hari harus dimonetisasi, dan lebih aneh lagi bahwa ia diakuisisi oleh salah satu perusahaan paling merugi di bidang yang paling besar ruginya di industri ini, tetapi orang masih tetap berharap
    • Anda tampaknya meremehkan dampak kebijakan dan budaya perusahaan terhadap produk
      Sekarang ada tim-tim yang sepenuhnya bertaruh pada AI dan bergerak dengan pola pikir seolah kode tidak perlu dilihat langsung lagi. Saya pernah melihatnya, dan hasilnya ya seperti yang bisa diduga. Sampai tingkat tertentu memang berjalan, tetapi terutama ketika tiap tim punya istilah teknis dan pemahaman yang berbeda, kompleksitas menumpuk, kesalahan ikut terakumulasi, dan akhirnya tidak ada lagi orang atau tim yang benar-benar tahu bagaimana perangkat lunak itu bekerja
      Ada juga arus kerja di mana tidak ada manusia yang mengetes atau melakukan quality assurance, dan selain unit test serta integration test, AI juga dibiarkan mengendalikan browser atau alat. Budaya Anthropic bisa mengubah cara tim Bun beroperasi dan berpikir
      Jika budaya dan pola pikir seperti ini menjadi standar, maka model harus jauh lebih baik, atau kualitas perangkat lunak akan menurun
      Ada presentasi bagus dari Matt Pocock: https://youtu.be/v4F1gFy-hqg
      “Code tidak murah. Code yang buruk kini menjadi yang paling mahal sepanjang masa. Karena kalau Anda punya codebase yang sulit diubah, Anda tidak bisa memanfaatkan kelimpahan yang ditawarkan AI. Pada codebase yang bagus, AI bekerja sangat, sangat baik.”
      Begitu code buruk mulai menumpuk dengan sendirinya, akan sangat sulit untuk keluar dari situ
    • Dengan logika yang sama, sebelum diakuisisi GitHub juga pada akhirnya harus mencari cara monetisasi. Menganggap GitHub pasti akan memburuk hanya karena perusahaan induknya, Microsoft, pernah menunjukkan praktik buruk seperti Embrace, Extend, Extinguish atau di MS Windows, tidak beda jauh dari berkata bahwa kekhawatiran itu bisa dipahami tetapi tetap optimistis soal GitHub
    • Anthropic mengakuisisi Bun bukan demi seluruh komunitas JavaScript, tetapi untuk melindungi dan mengembangkan investasinya pada Claude Code. Ini terlihat jelas, tetapi tetap perlu ditegaskan. Dalam jangka panjang, hasilnya akan mengikuti insentif

  • Saya tidak paham kenapa orang memakai Deno atau Bun alih-alih Node. Bagus memang ada pesaing runtime JavaScript, tetapi saya kurang melihat manfaat yang didapat dari pindah dari Node
    Bun tidak punya REPL dan engine JavaScript-nya juga lebih buruk, sementara Deno terasa seperti Node dengan sistem izin yang terbatas dan merepotkan, dan saya juga sempat mengira tidak ada sqlite. Keduanya katanya cepat, tetapi sepertinya hanya pada benchmark yang dipilih-pilih; pada beban kerja yang saya coba sendiri sekitar setahun lalu, keduanya lebih lambat daripada Node
    Meski begitu, dulu saat mengirim alat ERP kecil, saya ingat memakai Bun karena alat untuk membungkus proyek menjadi *.exe adalah yang paling matang. Karena JavaScript-nya tanpa dependensi, keseluruhan dibuat dengan Node dan hanya deployment-nya memakai Bun, dan pengalaman itu memang jelas lebih baik daripada Node

    • Deno juga punya sqlite: https://docs.deno.com/examples/sqlite/
    • Pengalaman developer di Bun jauh lebih baik daripada Node, terutama pada proyek TypeScript
    • Deno bagus karena pengguna bisa langsung menjalankannya tanpa langkah instalasi terpisah

  • Bun dari awal juga tidak pernah terlalu dikelola dengan baik. Banyak bug dan celah di tiap fitur, dan setiap kali beberapa hal diperbaiki dalam rilis, hal lain malah rusak
    Satu patch release terakhir bahkan memasukkan fitur besar dan perubahan yang merusak sebanyak yang biasanya dialami kebanyakan perangkat lunak dalam dua major version
    Bahkan ketika saya pada dasarnya hanya memakainya sebagai runner skrip dan pengelola paket npm, jumlah kerja untuk menemukan versi yang “bagus” benar-benar mengejutkan. Saya beberapa kali mengalami instalasi yang tiba-tiba macet di patch version, dan karena itu sempat tidak bisa upgrade selama beberapa waktu
    Sekitar dua minor version lalu, sepertinya mereka benar-benar merusak skrip postinstall bersama trustedDependencies. Tidak ada satu kata pun di release note, dan tampaknya tidak ada yang melaporkannya di GitHub issue. Sekitar versi 1.1, Bun masih bisa dibuat agar melakukan build trustedDependency pada postinstall, tetapi sejak itu tidak bisa lagi, dan sudah rusak berbulan-bulan

    • Ada GitHub issue tentang masalah macet saat instalasi. Pemindai keamanan mengirim seluruh daftar dependensi sebagai argumen command line, dan pada monorepo Linux yang besar itu melewati ARG_MAX
      spawn diam-diam macet tanpa error, dan karena pemindainya terpisah dari postinstall, --ignore-scripts juga tidak membantu. Setidaknya sudah rusak sejak 1.3.5

  • Saya bekerja di Bun, dan tulisan ini agak membingungkan. Saya pribadi dan tim Bun sendiri memakai Bun setiap hari sambil terus memperbaikinya, dan kecepatan pengembangan justru makin cepat. Sejak bergabung dengan Anthropic, stabilitas Bun juga meningkat pesat
    Hal-hal yang akan masuk ke versi Bun berikutnya antara lain pengurangan 17MB pada biner Windows x64 [0], pengurangan 8MB pada biner Linux [1], flag CLI --no-orphans untuk mematikan proses anak yang tersisa secara rekursif [3], caching konteks SSL untuk klien TCP dan Unix socket yang sangat mengurangi penggunaan memori pada klien database seperti Mongoose/MongoDB [4], klien HTTP/3 dan HTTP/2 eksperimental untuk fetch [5], dukungan HTTP/3 eksperimental untuk Bun.serve() [6], pustaka pemrosesan gambar bawaan Bun.Image [7], dan lainnya
    Selain itu juga ada peningkatan keandalan untuk node:fs, Worker, BroadcastChannel, dan MessagePort
    Berkat akuisisi Anthropic, Bun tidak lagi harus menjadi bisnis yang menghasilkan pendapatan. Claude Code bergantung pada Bun, dan banyak software engineer bergantung pada Claude Code untuk bekerja, jadi ada insentif kuat untuk membuat Bun menjadi lebih baik
    [0]: https://github.com/oven-sh/bun/pull/30219
    [1]: https://github.com/oven-sh/bun/pull/30098
    [2]: https://github.com/oven-sh/WebKit/pull/211
    [3]: https://github.com/oven-sh/bun/pull/29930
    [4]: https://github.com/oven-sh/bun/pull/29932
    [5]: https://github.com/oven-sh/bun/pull/29863
    [6]: https://github.com/oven-sh/bun/pull/30032

    • Akuisisi di industri ini biasanya memang berujung pada akhir yang sampai tingkat tertentu terasa tak terelakkan. Perangkat lunak yang diakuisisi memburuk karena anggota tim awal mengambil hasilnya lalu pergi, dan budaya lama digantikan budaya pemilik baru
      Bun mungkin bisa jadi pengecualian, tetapi kekhawatiran ini bukan tanpa dasar
      CEO Anthropic sering membuat prediksi berlebihan seolah AI akan hampir menggantikan programmer manusia, dan Anthropic sedang menerapkan keyakinan itu pada Claude Code hingga berubah menjadi spaghetti yang mustahil dirawat
    • Fitur terbaik yang diberikan Bun belakangan ini adalah biner portabel. Banyak pengguna memakai distro Linux lama, jadi portabilitas sangat penting. Node dan Deno menuntut Linux yang lebih baru, tepatnya glibc yang lebih baru
    • Mengatakan “saya bekerja di Bun” adalah pernyataan yang sangat meremehkan. Saya tetap punya kekhawatiran soal Anthropic, tetapi selama Jarred yang memimpin, rasanya Bun tidak akan melenceng. Menurut saya mereka memanfaatkan stabilitas dan dana dari organisasi yang lebih besar dengan baik

  • Saya menghabiskan beberapa jam memindahkan backend situs web pisau asah dari Bun ke Node, dan rasanya menyenangkan bisa menghindari efek penguncian. Awalnya saya cukup antusias dengan Bun, tetapi lama-lama keyakinan saya berkurang
    Fitur yang akan saya rindukan adalah query sqlite dengan tagged template literal, Bun.password.verify yang memakai argon2 secara default, import HTML, transformasi JSX, dan pemuatan otomatis file .env
    https://burlyburr.com memanggil https://backend.burlyburr.com

    • Node juga mendukung query sqlite dengan tagged template literal
      https://nodejs.org/api/sqlite.html#databasecreatetagstoremax...
    • Saya rasa Anda cukup memakai pustaka helper kecil untuk mengembalikan fitur-fitur yang dirindukan itu. Di Node setidaknya sudah ada SQLite dan Argon2, jadi kalau masalahnya ada di antarmuka, itu mudah diperbaiki
    • Node juga mendukung pemuatan otomatis .env dan sqlite

  • Saya juga tidak merasa Bun bekerja baik sebelum diakuisisi. Saya terus memakainya untuk skrip kecil, tetapi saya tidak akan pernah men-deploy layanan kerja dengan Bun
    Karena masalah memori dan inkompatibilitas yang tidak kunjung diperbaiki, saya melihatnya hanya sebagai mainan yang lumayan karena menunjukkan bahwa Node.js masih punya ruang untuk perbaikan
    Misalnya saya terus mengikuti https://github.com/oven-sh/bun/issues/14102, dan akhirnya pustaka-pustaka mulai menambahkan percabangan “kalau Bun maka lakukan x”, padahal itu justru kebalikan dari kompatibilitas

    • Saya pernah mencoba memakainya di lingkungan produksi pada beberapa proyek, tetapi keduanya harus dikembalikan dari Bun ke Node. Yang satu mengalami kebocoran memori besar seperti yang disebutkan, dan yang lainnya error karena perbedaan API di tempat seperti TextDecoderStream. Saya memutuskan tidak akan mencoba lagi sebelum Bun v2

  • Arah Claude Code dan Anthropic tampak seperti berusaha menyembunyikan sesuatu dari pengguna secara paksa. Mungkin ada yang masih ingat kekacauan saat perilaku membaca xxx.yy berubah dari membaca 1 file menjadi 2 file
    Perubahan seperti ini terus berlanjut, dan tidak bisa dikonfigurasi atau sangat sulit dikonfigurasi. Saya paham niat bisnisnya: memakai AI semaksimal mungkin, mengeluarkan manusia dari loop, serta mendapatkan lebih banyak data pelatihan dan lebih banyak penggunaan token
    Tetapi akibatnya, menurut saya Claude Code menjadi jauh lebih buruk dan jauh kurang bisa diandalkan. Rasanya seperti upaya diam-diam merebut kemudi dari tangan pengguna. Kalau logika itu diteruskan, makin banyak hal yang bisa dibenarkan
    Untuk sekarang, hasil utamanya justru hanya ketidakpercayaan yang makin besar

  • Saya setuju dengan penulis aslinya, dan saya juga paham bahwa bagi sebagian orang ini mungkin terasa seperti reaksi yang masih terlalu dini
    Kita hidup di dunia yang sangat berbeda dibanding dulu, dan orang kini lebih sadar akan kekhawatiran etis serta lebih kuat keinginannya untuk bertahan agar tidak mengulangi kesalahan masa lalu
    Dari standar teknis mungkin ini penilaian yang terlalu cepat, tetapi dari standar kekhawatiran etis ini tetap masuk akal. Kecurangan tidak lagi mudah dibalikkan seperti dulu, dan diperlukan langkah pencegahan untuk menghindari dampak besar yang ditimbulkan keputusan semacam itu

    • Saya penasaran apa dasar untuk mengatakan orang sekarang lebih sadar terhadap kekhawatiran etis dibanding dulu. Saya tidak melihat orang tampak lebih sadar secara etis. Misalnya saya melihat ada sedikit peningkatan jumlah orang di kubu BDS, tetapi selain itu saya kurang tahu
    • Kalau melihat keluhan bahwa Firefox dan Safari tidak mengadopsi API platform Chrome OS, atau realitas Chrome didistribusikan di mana-mana, saya rasa sulit bilang orang benar-benar bertahan sambil menjaga pertimbangan etis

  • Di bagian akhir, penulis menyebutkan hal-hal yang ia sukai di Bun tetapi tidak ada di pnpm. Daftarnya umumnya dukungan TS native, bundler ala Vite, dan runner pengujian ala Vitest/Jest
    Selain bundler, semuanya sebenarnya sudah ada di Node. Sintaks runner pengujiannya mungkin berbeda, tetapi TypeScript pada dasarnya sudah “langsung jalan” secara bawaan dan runner pengujian bawaannya juga cukup layak dipakai. Saya tidak yakin Bun perlu begitu diratapi

    • Kalau mau adil, Node tidak punya hal-hal ini sampai Deno dan Bun menantangnya. Deno saja, entah kenapa, tidak cukup memicu perubahan besar, tetapi keberadaan Bun benar-benar memberi dampak pada Node Technical Steering Committee
      Bisa juga dibilang bahwa pemasaran media sosial Jarred Sumner yang cerdik menciptakan banyak momentum saat ini. Ia membuat orang membicarakannya, dan berkat itu Node juga ikut membaik
      Selain itu, karena Bun mendorong dukungan sebanyak mungkin untuk API Node, Deno pun bergerak ke tingkat kompatibilitas yang sama, dan sekarang kebanyakan code pada praktiknya jadi kurang terikat pada runtime. Saya tidak tahu apakah saya akan memakai Bun di lingkungan produksi nyata, tetapi saya senang karena hanya dengan keberadaan Bun saja, ekosistem JavaScript sudah banyak membaik
    • Kapan Node menambahkan TypeScript native? Apakah sekarang bisa langsung menjalankan node main.ts tanpa dependensi?
    • Kalau mempertimbangkan penulisan ulang compiler TypeScript juga, relevansi Bun jadi makin kecil

  • Sejujurnya saya tidak terlalu sering memakai Bun selain sesekali untuk menguji modul. Untuk penggunaan sehari-hari saya lebih banyak memakai Deno, dan selama beberapa tahun terakhir saya juga menulis banyak shell script dengan Deno
    Kegunaan terbarunya cukup saya sukai, dan cara langsung merujuk modul di repositori sangat bagus terutama untuk shell script
    Tetapi saya khawatir apakah mereka bisa melakukan monetisasi yang memadai sambil tetap membuka fitur-fitur itu, atau setidaknya memungkinkan orang lain menirunya. Jadi saya bisa memahami sebagian kekhawatiran ini
 
jjpark78 3 jam lalu

https://github.com/oven-sh/bun/issues/17723

Kalau ini saja diperbaiki, rasanya saya bakal coba jalankan sekali di backend...