Nub - Node.js için Bun benzeri hepsi bir arada araç seti

• Node.js’in yerini almadan onu güçlendiren hepsi bir arada bir araç seti; Rust ile yazılmış olup standart node üzerinde Bun’a benzer bir geliştirme deneyimi sunar
• Dosya ve script çalıştırma, bağımlılık kurma ve Node sürüm yönetimini tek bir araçta birleştirir; yeni runtime, tedarikçiye bağlı API veya lock-in yoktur
• File runner nub <file> — .ts, .tsx vb. dosyaları build adımı olmadan çalıştırır; node ile flag-for-flag ve var-for-var uyumludur; startup’ta tsx’e göre 2,9× daha hızlıdır
  • Tam TypeScript desteği (enum, namespace), JSX/TSX, Decorators, .env* otomatik yükleme, .yaml·.toml·.json5 gibi yerleşik loader’lar
  • Projenin beklediği Node sürümünü otomatik algılayıp kurma (.node-version, .nvmrc, package.json#engines vb. referans alınır)
• Script runner nub run — npm/pnpm run için drop-in; kendi JS startup’ı olmayan Rust binary’siyle pnpm run’a kıyasla yaklaşık 24× daha hızlı dispatch (14,7 ms’ye karşı 442,7 ms)
  • pre/post hook’ları, pnpm workspace --filter·--parallel vb. için tam destek
• Package runner nubx — npx·pnpm dlx için drop-in; çift Node spawn cezasını ortadan kaldırarak npx’e kıyasla yaklaşık 19× daha hızlı çalıştırma (11 ms’ye karşı 226 ms)
• Package manager nub install — Aube motoru tabanlıdır, pnpm ile flag uyumludur; pnpm’e göre 2,5×, npm’e göre 3,7× daha hızlıdır
  • Yerleşik varsayılan güvenlik politikası — postinstall engelleme, osv.dev kötü amaçlı paket denetimi, provenance downgrade reddi, 24 saatlik minimumReleaseAge
  • npm/pnpm/Yarn/Bun lockfile ve ayarlarını otomatik algılayan compat-mode davranışı
• Node version manager nub node — sürüm install·ls·uninstall·pin gibi manuel yönetim komutları sağlar
• Package meta-manager nub pm — Corepack rolünü native Rust ile yerine getirir; npm·yarn·pnpm için global shim kaydı yapar
• MIT lisansı

[GN⁺]

Hacker News görüşleri

• Fikir çok iyi ve mantıklı. Bun, DB sürücüleri gibi daha fazla şey sunuyor ama geliştirici deneyiminin de çekiciliğin büyük bir parçası olduğu kesin
  Bu arada Nub’ın baş yazarı, Zod’u yaratan Colin McDonnell ve bir dönem Bun’da da çalışmış

  • Evet. Nub, bilerek Nub’a özel API’ler hiç eklemiyor: Nub global nesnesi yok, nub: önekli yerleşik modüller yok, Nub adlı yapılandırma dosyası/kilit dosyası yok, package.json içinde nub alanı yok, NUB_ ortam değişkenleri yok
    Bun’ın eklediği şeylerin çoğunun düzgün bağımlılıklar olarak tutulmasının daha iyi olduğunu düşünüyorum

• --import yerine --require hook kullanması şaşırtıcı. Benzer bir özellik yapmaya çalışırken buna bakmıştım; o zamandan beri büyük şeyler değişmiş olabilir ama Nub’ın ESM desteğinde ince bir nokta olup olmadığını merak ediyorum
  O zamanlar Node’un --import özelliği çok yeniydi ve tipik ESM-to-CJS yaklaşımıyla ele almak istediğimiz çeşitli istisnalar vardı. Çoğu çok niş vakalardı ama top-level await’in anlamlı bir kullanıcı kitlesini etkileyeceğini düşünüyordum

  • Bu, preload kaydı için tamamen performans nedeniyle kullanılıyor. Bu durumda ve başka birçok durumda CommonJS hâlâ ESM’den daha hızlı. --require yaklaşık 0.5ms ek yük getirirken, --import M1 Macbook Pro’da yaklaşık 4.6ms
    Bununla bağlantılı olarak Node.js, yakın zamanda 2025’te eski asenkron module.register() API’sine göre performansı artırmak için resolver hook kayıt API’sinin senkron sürümü olan module.registerHooks()u ekledi. Bu, Nub için büyük bir engelin kalkması oldu. İlgilenenler için ekleyeyim: asenkron API, sabit 19ms kayıt ek yüküne ve her import başına yaklaşık 130us ek yüke neden oluyordu
    Nub’ın burada hangi bayrağı kullandığının kullanıcı koduna hiçbir etkisi yok ve top-level await, Node.js’in zaten desteklediği yerlerde destekleniyor

• Tüm monorepomuzu nub’a migrate eden PR’ı az önce merge ettim
  Sıfır sorun çıktı ve inanılmaz hızlı

  • Bu gönderi yayımlandıktan sonraki bir saat içinde paylaşımlı monorepoyu buna migrate eden bir PR mı merge ettin?

• Node birkaç sürümdür TypeScript çalıştırabiliyor değil miydi? Neden bir dönüştürücü gerekiyor?

  • Node’un yerleşik TypeScript desteği sadece type stripping yapıyor. TypeScript sözdiziminin oldukça büyük bir kısmında işe yarıyor ama hepsinde değil. Gerçek anlamda type checking de yapmıyor; sadece çalışsın diye tipleri kaldırıyor. tsconfig gibi şeyler de kayboluyor
    Görünüşe göre bu, hem yerleşik kaldırma yöntemini hem de gerçek TypeScript işlemeyi destekliyor
  • Node.js ekibi, Node.js v26’da --experimental-transform-types seçeneğini kaldırdı. Bu da yerel tam TypeScript desteğini imkânsız hâle getiriyor
    https://github.com/nodejs/typescript/issues/51#issuecomment-...
  • Gerektiğinde Worker, Temporal gibi API’lere polyfill enjekte ettiği yazıyor

• README’de WebSocket desteğinin Node 22’den itibaren yerel olduğu yazıyor ama Node’da yerel bir WebSocket kütüphanesi yok. WebSocket standardı bağlantısı MDN’e gidiyor; orası da sadece WHATWG kullanıcı arayüzünü anlatıyor, protokolü veya WebSocket’in nasıl çalıştığını değil
  Bir şey eksik gibi ya da yardımcı olarak yerel olmayan bir kütüphane kullanıyormuş hissi veriyor

  • Node, 22’den beri yerleşik WebSocket istemcisini destekliyor ama sunucuyu desteklemiyor

• Mevcut teknolojiyi benimsemesi ve onun daha kötü bir sürümünü yeniden yapmaması saygı duyulacak bir şey. Alternatifler üretmeye harcanan tüm çaba Node’a gitseydi, doğru liderlik altında bugün nereye gelmiş olurdu merak ediyorum

  • 2014’teki Node.js io.js fork’unu hatırlıyor olabilirsiniz. Node duraklayınca birçok kişi io.js’e fork etti; sonunda tekrar Node’a birleştirildi ve Node’u yeniden rayına oturttu. Daha da geriye gidersek, JS’in bir “fork”u sayılabilecek CoffeeScript’in en iyi fikirleri de ES5 tarafından emildi
    Küçük ve çevik ekipler, başarısızlık ölümcül bir risk olmadığı için iyi fikirleri kanıtlayabilir. Kısacası fork’lar sağlıklı bir ekosistemin parçasıdır
  • Temelde bu yaklaşımla düzeltilemeyecek çok şey var
    Basit bir örnek olarak, Node bildiğim ciddi açık kaynak yazılımlar arasında yapılandırma dosyası içinde yapılandırmayı belgelemenin bir yolu olmayan tek şey. Bu saçma. Node tarafı düşünmeden JSON’ı benimsedi ve sonrasında “yorumlu JSON” dahil hiçbir alternatifi değerlendirmeye yanaşmadı
    Bir organizasyon kötü kararlara saplanıp kaldığında, bunu düzeltmenin tek yolu yeniden başlamaktır. Herkes Node’un üstüne bir şeyler yığmaya devam ettikçe, tüm JS ekosistemi yapılandırmanın içine dokümantasyon bırakamayacak
    Node ekosisteminde bunun gibi birçok sorun var ve yapılandırmayı belgelendirememek gibi tam bir absürtlük sadece benim kişisel takıntı noktalarımdan biri

• Nub’ın ve maskotu nubnub’ın hayranıyım. Ciddi söylüyorum, harika bir proje ve oldukça ilginç; geçen haftadan beri, en azından duyurulduğundan beri, kullanıp deniyorum

• Zekice. En azından zaten Rust ile yazılmışsa, Rust’a migrate etmeyi vibe coding ile yapıp tüm müşterileri kaybetmezsin ;)

  • OpenAI tarafından satın alındıktan sonra projeyi Zig’e geçirirler herhâlde
  • Bu proje zaten epey vibe coding içeriyor. Deponun en büyük ikinci katkıcısı Claude
  • “Zaten Rust ile vibe coding yapıldıysa” demek daha iyi olabilir. Nub genel olarak biraz öyle kokuyor. Sorun değil ama Bun’la karşılaştırınca komik
    Ek olarak, Bun’a yönelik AI karşıtı histeri çok üzücü; bazen örgütlü bir kampanya gibi bile hissettiriyor
  • Zaten baştan vibe coding ile yapılmışsa ve müşterisi de yoksa daha da yardımcı olur
  • Evet. Burada “Rust ile yazılmış” olmasının ne kattığından pek emin değilim. Aynı işin birkaç shell script ve package.json ile de yapılabileceğini düşünmüştüm