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ın tümü sağlayıcının belirli senaryolardaki mikro benchmark’larından geliyor.

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.

Altı aracı doğrudan yapılandırmayı bırakıp tek ve tümleşik bir yığına güvenmeye başlıyorsun; asıl bedel de bu bağlanma (coupling): 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. Vite 8, Rolldown ve Vitest zaten 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.

Nub v0.4.x seviyesinde ve fiilen tek geliştiricili, gerçi güvenilir biri; risk de tam burada: transpile-ve-çalıştır yolundaki erken aşama hatalarında ve olgun sürüm yöneticilerine kıyasla boşluklarda. 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.

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ç.

Ç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ı ürettiğin çıktı belirliyor. Özellik listeleri yanıltacak kadar örtüşüyor; çıktılar ise asla örtüşmüyor.

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ı dispatch 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.

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 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 projeler 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’a ekliyor, sağlayıcıya özgü API yayımlamıyor ve mevcut lockfile’larınla çalışmaya devam ediyor; bu yüzden çıkış ucuz kalıyor.

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.

Ne zaman başka bir araca yönelmeli#

Varsayılanın dışında kalan birkaç 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.

Bu durumları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.

Ayrımın yanlış okunduğu yerler#

• 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 baseline’ına bağlı.

Sonuç#

Araç zinciri önemsizse, zaten Bun ya da Deno çalıştırıyorsan ya da o repo için 1.0 öncesi risk kabul edilemezse istisna geçerlidir.

Sonraki adım küçük 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.

Kaynaklar#

• Announcing Vite+ Beta (yeni sekmede açılır) - 2 Temmuz 2026 beta yazısı; yetkili vp komut yüzeyi, paketlenen araçlar ve benimsenme istatistikleri.
• Announcing Vite+ (yeni sekmede açılır) - 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 (yeni sekmede açılır) - Vite+ kaynak deposu; bileşenler, issue’lar ve sürümler.
• Vite+ documentation (yeni sekmede açılır) - Resmi kılavuz; vp migrate yolu ile elle takip uyarısı dahil.
• VoidZero is Joining Cloudflare (yeni sekmede açılır) - 4 Haziran 2026 sahiplik değişimi; Vite+‘ın stratejik desteğini ve kilitlenme profilini yeniden çerçeveliyor.
• Announcing VoidZero Inc. (yeni sekmede açılır) - 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 (yeni sekmede açılır) - Resmi ana sayfa; konumlandırma ve komut özeti.
• Introducing Nub (yeni sekmede açılır) - Komut başına benchmark’lar ve açık “mutlak sayı değil, oran” uyarısıyla lansman yazısı.
• nubjs/nub (yeni sekmede açılır) - Kaynak ve README; yer değiştirme tablosu, 18x kurulum iddiası ile sürüm ve yazar bilgisi.
• Rewriting Bun in Rust (yeni sekmede açılır) - 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 (yeni sekmede açılır) - Sağlayıcı çerçevesine karşı denge sağlayan şüpheci bir uygulamacı bakışı.
• I Tried Vite+ and Replaced My Entire Frontend Toolchain (yeni sekmede açılır) - Bir uygulamacının elle denemesi; tam bir geçişten çok vp create iskelesine odaklı.