Nub vs Vite+: JS Yığınının Zıt Uçları İçin İki Rust Araç Zinciri

JavaScript araç zinciri hâlâ ayrı parçalardan oluşan bir yığın: paket yöneticisi, runtime, TypeScript çalıştırıcısı, bundler, test çalıştırıcısı, linter ve formatlayıcı; her birinin kendi config dosyası ve kendi sürüm kayması var. 2026’nın iki projesi bu yığını tek ve hızlı bir Rust ikilisine indirmeyi vaat ediyor: Nub ve Vite+. İkisi de oxc tabanlı, tek ikilili ve haftalar arayla çıktı; bu yüzden geliştiriciler onları sürekli rakip diye sınıflandırıyor. Değiller. Vite+, tarayıcıya bakan uygulama hattının sahibi; Nub ise stok Node sürecinin sahibi. Kural bu kadar basit: derleme çıktın tarayıcıda yükleniyorsa Vite+ üzerinde standartlaş; bir Node süreci olarak çalışıyorsa Nub’a uzan. Aşağıdaki sayılar sağlayıcının belirli senaryolardaki mikro benchmark’ları; bağımsız ölçümler değil.

Vite+ neyin sahibi

Vite+, web geliştirme akışını birleştiren tek bir vp komutu. 2 Temmuz 2026’da beta’ya ulaştı (alpha 13 Mart 2026’daydı). Komut yüzeyi, tarayıcıya bakan hattın tamamını kapsıyor:

vp dev        # Vite 8 üzerinde HMR geliştirme sunucusu
vp check      # tek geçişte Oxlint + Oxfmt + tip kontrolü
vp test       # Vitest
vp build      # üretim derlemesi (Rolldown)
vp pack       # bir kütüphaneyi paketle (tsdown)
vp run build  # önbellekli, monorepo farkındalı görev çalıştırıcısı

Kaputun altında Vite, Vitest, Rolldown, tsdown, Oxlint ve Oxfmt’i o tek ikilinin arkasında topluyor; ayrıca runtime’ı ve paket yöneticisini de yönetiyor. Tamamen açık kaynak ve MIT lisanslı; vp create ve vp migrate ise iskeleti kurma ile mevcut bir Vite projesini taşıma işini üstleniyor.

Ödünleşim, bağlanma (coupling). Altı aracı doğrudan yapılandırmayı bırakıp tek ve tümleşik bir yığına güvenmeye başlıyorsun. Bir plugin ya da framework’te sınır durumu çıktığında, aracın değil soyutlamanın içinden hata ayıklıyorsun. Pratikte vp migrate düz Vite geçişinin çoğunu yapıyor, ama kılavuz açıkça karmaşık projelerin hâlâ elle takip gerektirdiğini söylüyor. Kazancı ise derinlik: Vite 8, Rolldown ve Vitest ekosistemin varsayılanları, yani ikilinin içindeki parçalar çoğu ekibin zaten ürettiği parçalar.

Nub neyin sahibi

Nub, stok node üzerine kurulu, Rust ile yazılmış Bun benzeri bir geliştirici deneyimi. Tasarım duruşu yeni bir runtime’ın tam tersi: Node’u değiştirmek yerine ona ekliyor. @nubjs/nub olarak yayımlanıyor, Haziran 2026’da çıktı ve haftalar içinde v0.4.x’e ulaştı. Yazarı, Zod’un yaratıcısı ve eski Bun ekibinden Colin McDonnell.

nub server.ts        # projenin sabitlediği Node üzerinde TypeScript çalıştır
nub watch server.ts  # aynı şey, Node'un yerleşik --watch'u üzerinde
nub install          # pnpm uyumlu kurulum, mevcut lockfile'lar çalışır
nubx tsc --noEmit    # global kurulum olmadan bir bin çalıştır
nub node 22          # sürüm yöneticisi, nvm/fnm/n/volta yerine

Başrol komutu nub <file>. TypeScript’i oxc üzerinden bellekte transpile ediyor, .env yüklüyor, tsconfig yol aliaslarını çözüyor ve sonucu projenin sabitlediği stok Node üzerinde çalıştırıyor. Bu tek komut node, tsx, ts-node ve dotenv-cli’nin yerine geçiyor. Etrafında bir script çalıştırıcısı (nub run), bir bin çalıştırıcısı (nubx / nub dlx), pnpm uyumlu bir paket yöneticisi (nub install), Node’un kendi --watch’u üzerine kurulu bir watch modu ve nvm, fnm, n ile volta’nın yerini alan bir sürüm yöneticisi (nub node) yer alıyor. Belirtilen tasarım hedefi: yeni runtime yok, sağlayıcıya özgü API yüzeyi yok ve kilitlenme (lock-in) yok; mevcut npm, pnpm ve yarn lockfile’larıyla uyumlu kalıyor.

Ödünleşim, kilitlenme değil olgunluk. Nub v0.4.x seviyesinde ve fiilen tek geliştiricili, gerçi güvenilir biri. Değiştirmek yerine eklediği için çıkış maliyeti neredeyse sıfır: lockfile’ların çalışmaya devam ediyor ve onu kaldırdığında hiç göç etmeden node, tsx ve pnpm’e geri düşüyorsun. Risk, terk edemeyeceğin bir runtime’da değil; transpile-ve-çalıştır yolundaki erken aşama hatalarında ve olgun sürüm yöneticilerine kıyasla boşluklarda.

Buradaki haklı bir itiraz, neden doğrudan Bun kullanılmasın. Nub, Bun’un runtime bahsi olmadan Bun’un geliştirici deneyimi: aynı tek ikili rahatlığı, kodunu neyin çalıştıracağına dair ters karar. Bun runtime’ı değiştiriyor. JavaScriptCore üzerinde, kendi transpiler ve bundler’ıyla çalışıyor; 2026’daki Rust yeniden yazımı da, artık Anthropic çatısı altında, onu bir başka tek ve hızlı Rust ikilisi yapıyor, ama oxc tabanlı değil ve stok Node değil. Nub ise üretimin zaten çalıştırdığı Node’u koruyup yalnızca ona ekliyor: oxc bellekte transpile ediyor, sonra sabitlediğin tam stok V8 sonucu çalıştırıyor. Stok Node’da kalmanın tüm nedeni işte bu tek fark. Bir Node dağıtımının runtime semantiğine uyması gereken bir servis, Node’un ABI’sine karşı derlenmiş yerel bir eklenti ya da yalnızca daha hızlı bir kurulum için runtime’ı yeniden onaylamak istemeyen bir ekip, hepsi Nub’a geri işaret ediyor. Bunlardan hiçbiri seni bağlamıyorsa istisna geçerli: Bun ya da Deno’ya geç, Nub artık yaşamadığın bir sorunu çözer.

Çakıştıkları tek yuva

İki komut yüzeyini yan yana okuyunca kafa karışıklığı dağılıyor. Neredeyse her yerde zıt yönleri gösteriyorlar.

Yetenek	Vite+	Nub
Tarayıcı geliştirme sunucusu (HMR)	Evet (vp dev)	Hayır
Üretim tarayıcı paketi	Evet (vp build)	Hayır
Kütüphane paketleme	Evet (vp pack)	Hayır
Test çalıştırıcısı	Evet (vp test)	Hayır
Lint ve format	Evet (vp check)	Hayır
Monorepo görev çalıştırıcısı	Evet (vp run)	Kısmen (nub run dispatch)
Stok Node’da backend TS çalıştırma	Hayır	Evet (nub <file>)
Paket yöneticisi	Evet	Evet (nub install)
Runtime ve sürüm yönetimi	Evet	Evet (nub node)

İkisinin de evet dediği tek satırlar son ikisi: paket yöneticisi ile runtime ya da sürüm yönetimi. İşte tesisat (plumbing) bu. Onun üstündeki her şey Vite+ için yukarı, tarayıcı çıktısına; Nub için aşağı, Node sürecine doğru bakıyor. Yani tek gerçek çakışma, hem frontend hem backend içeren bir repoda tesisat yuvasının kime ait olduğu. Full-stack bir monorepo’da, ortak tesisatı daha olgun ve ekosistem destekli seçenek yönetsin. Bugün bu Vite+; çünkü Vite 8 ve geniş Vite ekosistemi üzerinde oturuyor ve artık Cloudflare desteğinde. Nub ise yerini özellikle backend ve CLI TypeScript’ini stok Node üzerinde çalıştırıp izlemekle kazanıyor.

Çıktı merkezli karar

Kararı, özellik listesine değil ürettiğin çıktıya göre kök al. Özellik listeleri yanıltacak kadar örtüşüyor; çıktılar ise asla örtüşmüyor.

Varsayılan iki satırda net okunuyor. Çıktı tarayıcıda yükleniyorsa araç zincirinin sahibi Vite+. Çıktı stok Node’da kalması gereken bir Node süreciyse run, watch ve install’ın sahibi Nub. Dallar yalnızca istisnaları adlandırmak için var: runtime’ı değiştirmeye açıksan Nub yerine Bun ya da Deno’yu, 1.0 öncesi risk kabul edilemezse iki tarafta da sıkıcı ve birleştirilmiş yığını işaret eder.

Sağlayıcı sayılarını dürüstçe okumak

Buradaki her sayı, sağlayıcının belirli bir mikro senaryoda yayımladığı bir değer. Hiçbirini yeniden üretmedim. Bir oranı tekrarlamadan önce kaynağını belirt ve senaryosunu adlandır.

• Üretim derlemesi. VoidZero, Vite+ derlemelerinin Vite 7’ye göre kabaca 1.6x ile 7.7x arası daha hızlı olduğunu bildiriyor ve Linear’ın derlemesinin 46 saniyeden 6 saniyeye düştüğünü aktarıyor. Aralık geniş, çünkü hızlanma projeye bağlı.
• Lint ve format. Oxlint, 600’den fazla ESLint uyumlu kuralla ESLint’ten yaklaşık 100x’e kadar; Oxfmt ise yaklaşık %99 Prettier uyumluluğuyla Prettier’dan yaklaşık 30x’e kadar hızlı gösteriliyor.
• Script dispatch. Nub, run dispatch’ini (sıcak, işlemsiz bir echo) pnpm run’a göre yaklaşık 24x, ama Node’un kendi node --run’ına göre yalnızca yaklaşık 2.2x olarak bildiriyor. Nub açıkça mutlak sayıların makineye özgü olduğunu, yalnızca oranların taşınabilir olduğunu söylüyor.
• Bin çalıştırıcısı. nubx, npx’e göre yaklaşık 19x ile 20x arası gösteriliyor.
• Kurulum. Nub’un README’si pnpm install’a göre 18x daha hızlı olduğunu iddia ediyor; ikincil yazılar ise 2.5x’e daha yakın bir değer veriyor. Aynı araç, farklı önbellek durumu (sıcak işlemsiz vs soğuk). Senaryoyu belirt ya da sayıyı kullanma.

En net uyarı kurulum sayısı. “pnpm run’dan 24x hızlı” başlığı, Node 22 ve sonrasında node --run ile kıyaslandığında sessizce yaklaşık 2.2x’e iniyor. Alıntıladığın oran, ancak seçtiğin temel çizgi kadar dürüst; o yüzden ekibinin bugün gerçekten çalıştırdığı temel çizgiyi seç.

Her şey için tek ikili

Yedi aracı tek ikiliye indirmek, JavaScript ekosisteminin on yıl boyunca kaçtığı bağlanmayı yeniden getiriyor. Bunun ilerleme mi yoksa yeni bir monolit mi olduğu tek soruya bağlı: ayrılmak ne kadar pahalı?

Vite+ tümleşikliğe tamamen yaslanıyor. Geliştirme sunucusunun, bundler’ın, test çalıştırıcısının, linter’ın, formatlayıcının, görev çalıştırıcısının ve paket yöneticisi ile runtime yuvalarının sahibi. Stratejik desteği de değişti: VoidZero, 4 Haziran 2026’da Cloudflare’e katıldığını duyurdu. Aynı zamanda daha az değil, daha açık hâle geldi. Ekim 2025’teki ilk plan ticari ve kaynağı görünür bir modeldi; yalnızca bireyler, açık kaynak ve küçük işletmeler için ücretsizdi. Bu, Mart 2026 alpha’sında geri alındı ve beta da tamamen MIT. Yani lisans riski düşerken sahip olduğu yüzey alanı büyüdü.

Nub tam tersi bahsi oynuyor. Stok Node’u değiştirmek yerine ona ekliyor, sağlayıcıya özgü API yayımlamıyor ve mevcut lockfile’larınla çalışmaya devam ediyor. Onu kaldırıp hiç göç etmeden node, tsx ve pnpm’e geri dönebilirsin.

Monolit sorusunu dürüstçe okumanın yolu bu. Konsolidasyon, ikili hiç sahip olmak istemediğin yapılandırmayı üstlendiğinde ilerlemedir; örneğin yalnızca birbiriyle çekişen altı lint, format ve bundler config’i. Geri döndürülebilir tutmak istediğin kararları üstlendiğinde ise monolit riskidir; örneğin üretim servisini hangi runtime’ın çalıştırdığı ya da paket grafiğinin kime ait olduğu. Her ikiliyi kurulum hızı grafiğine göre değil, çıkış maliyetine göre değerlendir.

Ne zaman başka bir araca yönelmeli

Varsayılanın dışında kalan üç durum var.

• Önemsiz bir araç zincirine sahip saf statik bir site. Hiçbir ikili yerini hak etmiyor; düz bir bundler ya da framework’ün yerleşik araçları yeter.
• Zaten üretimde Bun ya da Deno çalıştırıyorsun. Nub’un tüm önermesi stok Node paritesi, yani sende olmayan bir sorunu çözüyor; runtime’ın araç zincirini zaten indirgemiş.
• Bugün olgun bir monorepo görev grafiği lazım. vp run, Turborepo ya da Nx’ten daha yeni ve daha basit. Ölçekte uzak önbellekli, kanıtlanmış bir görev grafiğine bağımlıysan güvendiğin aracı koru ve Vite+‘ın yalnızca açıkça öne çıktığı parçalara sahip olmasına izin ver.

Üçünün altında da 1.0 öncesi sorusu duruyor. Vite+ beta’da ve Nub 1.0 öncesi (v0.4.x). Söz konusu repo için 1.0 öncesi risk kabul edilemezse, yedek plan sıkıcı ve gayet iyi: frontend’de birleştirilmiş araçlarla düz Vite 8, backend’de tsx artı pnpm artı fnm.

Sık yapılan hatalar

• Onları kafa kafaya rakip sanıp kazananı bir kurulum hızı sayısına seçtirmek. Farklı katmanlarda duruyorlar.
• Nub’u alıp ondan bir tarayıcı geliştirme sunucusu ya da üretim tarayıcı paketi beklemek. İkisi de yok.
• Tarayıcı için hiç paketlemediğin bir backend servisi çalıştırmak için Vite+ almak. vp bunun için değil.
• Bir sağlayıcı benchmark’ını ölçülmüş gerçek gibi tekrarlamak. Her sayı tek bir mikro senaryoya bağlı, o yüzden kaynağını belirt.
• Nub’un 24x run değerini, node --run’a karşı yaklaşık 2.2x olduğunu fark etmeden alıntılamak. Başlık tamamen mevcut temel çizgine bağlı.

Sonuç

Kural yaygın durumlar için geçerli. Derleme çıktısı tarayıcıda yükleniyorsa ya da full-stack bir monorepo’nun paket yöneticisi ile runtime yuvasına tek bir araç sahip olsun istiyorsan Vite+ üzerinde standartlaş. Derleme çıktısı bir Node süreciyse (backend servisi, CLI, kütüphane ya da bir yığın script) ve stok Node’da kalmalıysa; run, watch ve install için Nub’a uzan. Birbirinin yerine geçmiyorlar, o yüzden kararı çıktı versin ve hiçbirini diğerinin işini yapmaya zorlama. Araç zinciri önemsizse, zaten Bun ya da Deno çalıştırıyorsan ya da o repo için 1.0 öncesi risk masada değilse bir istisnaya uzan.

Bu karşılaştırma araçları haritalıyor; onları benchmark etmiyor. Sonraki adım küçük ve kavramsal bir POC: bir TypeScript servisini nub altında, bir web uygulamasını vp altında çalıştırıp her soyutlamanın nerede sızdığını kaydetmek. O çalışana kadar yukarıdaki her oranı, ölçülmüş bir sonuç değil, belirli bir senaryoya bağlı bir sağlayıcı iddiası olarak gör.

Kaynaklar

• Announcing Vite+ Beta - 2 Temmuz 2026 beta yazısı; yetkili vp komut yüzeyi, paketlenen araçlar ve benimsenme istatistikleri.
• Announcing Vite+ - 13 Ekim 2025 ilk duyurusu; Oxlint ve derleme benchmark rakamlarının kaynağı ve sonradan geri alınan ticari, kaynağı görünür lisanslama planı.
• voidzero-dev/vite-plus - Vite+ kaynak deposu; bileşenler, issue’lar ve sürümler.
• Vite+ documentation - Resmi kılavuz; vp migrate yolu ile elle takip uyarısı dahil.
• VoidZero is Joining Cloudflare - 4 Haziran 2026 sahiplik değişimi; Vite+‘ın stratejik desteğini ve kilitlenme profilini yeniden çerçeveliyor.
• Announcing VoidZero Inc. - Kuruluş yazısı ve sonraki lisans dönüşünü değerlendirmede kullanılan açık kaynak taahhüdü.
• Nub: all-in-one toolkit for Node.js - Resmi ana sayfa; konumlandırma ve komut özeti.
• Introducing Nub - Komut başına benchmark’lar ve açık “mutlak sayı değil, oran” uyarısıyla lansman yazısı.
• nubjs/nub - Kaynak ve README; yer değiştirme tablosu, 18x kurulum iddiası ile sürüm ve yazar bilgisi.
• Rewriting Bun in Rust - Bun’un 2026’daki Zig’den Rust’a geçişini Anthropic çatısı altında anlatan kendi yazısı; oxc yerine JavaScriptCore’da kaldığını doğruluyor.
• Vite+: 7.7x Faster Builds, Why You Should Wait - Sağlayıcı çerçevesine karşı denge sağlayan şüpheci bir uygulamacı bakışı.
• I Tried Vite+ and Replaced My Entire Frontend Toolchain - Bir uygulamacının elle denemesi; tam bir geçişten çok vp create iskelesine odaklı.