Node API Uyumluluk Yüzeyi: Ne Kadar Gerçek?
Bun 1.4'ün en somut kanıtı: Node.js 26.3.0'ın kendi test paketinde 1.517 yeni test geçti (bun.sh/blog/bun-v1.4, 20 Ağustos 2026). Bu, "Bun artık Express/Fastify/NestJS/Next.js'i sorunsuz çalıştırıyor" iddiasının arkasındaki gerçek veri noktası — ama uyumluluk iki katmanlıdır. Birinci katman: saf JavaScript/TypeScript API yüzeyi (fs, http, path, stream, worker_threads). Bun bu katmanda hızla ilerliyor. İkinci katman: native N-API addon'ları — node-gyp ile derlenmiş sharp, native bcrypt, bazı veritabanı driver'ları. Bun, V8 değil JavaScriptCore (WebKit) kullandığı için bu katman yapısal bir sınır oluşturuyor; Rust rewrite JS-API uyumluluğunu artırdı ama native addon uyumsuzluğunu ortadan kaldırmadı. Sen kesin cevap istiyorsan: bağımlılık listeni bun install sonrası tek tek çalıştırıp test et, "muhtemelen çalışır" varsayımıyla production'a geçme. Node tarafında ise uyumluluk hiç sorun değil çünkü referans implementasyon o — ama bu, Node'un her API'sinin "modern" olduğu anlamına gelmiyor; bazı eski API'ler (örn. Callback tabanlı fs metodları) hâlâ destekleniyor ama önerilmiyor.
Native TypeScript: İki Farklı Yaklaşım
Bun'da TypeScript ve JSX dosyalarını doğrudan çalıştırırsın — bun run server.ts transpile adımı gerektirmez, tip kontrolü ayrı bir adımdır (bun tsc kullanmaz, sadece syntax'ı strip eder). Node.js tarafında native type-stripping v22.6'da deneysel olarak geldi, v24.12.0/v25.2.0'dan beri stabil — ama resmi dokümana göre (nodejs.org/api/typescript.html) bu yalnızca "erasable syntax" destekler ve tsconfig.json'u tamamen yok sayar. Yani enum, namespace, parameter properties gibi runtime-etkili TypeScript özellikleri veya path alias'ları Node'un native modunda çalışmaz; bunlar için hâlâ tsx veya ts-node gibi üçüncü-parti araçlara ihtiyaç var. Sonuç: küçük script'ler ve basit servisler için her iki runtime da "sıfır konfigürasyonla TS" vaadini büyük ölçüde tutuyor, ama karmaşık tsconfig ayarlarına (path mapping, decorators) bağımlı büyük kod tabanlarında Node'un native modu yetersiz kalıyor ve ek tooling gerekiyor — bu noktada Bun'ın deneyimi daha sürtünmesiz.
Paket Kurulumu ve HTTP: Hız Nerede Gerçek?
bun install, resmi dokümana göre npm'e kıyasla "25x'e kadar" daha hızlı kurulum vaat ediyor; Bun 1.4'te eklenen "global virtual store" ile ayrıca "7x faster installs" iyileştirmesi geldi — bunlar iki ayrı, birbirine karıştırılmaması gereken iddia (bun.sh/docs/cli/install). Pratikte bu fark en çok soğuk kurulumda (temiz node_modules, boş cache) hissediliyor; CI'daki warm-cache/lockfile senaryolarında npm/pnpm ile fark daralıyor. HTTP tarafında Bun.serve() v1.4.1'den (4 Eylül 2026) beri native HTTP/2 destekliyor — Node.js'in yerleşik http2 modülü yıllardır var ama Bun'ın entegrasyonu tek API yüzeyinde (fetch-uyumlu Request/Response) sunuluyor. Sentetik "echo" benchmark'ları (yalnız HTTP yanıtı, DB/ORM/auth katmanı yok) genelde Bun'ı öne çıkarıyor; ama gerçek bir production stack'e (veritabanı sorgusu, ORM, auth middleware, loglama) DB+ORM+auth eklendiğinde performans farkı ciddi şekilde daralıyor. Kapasite planlamasını yalnız sentetik "req/s" rakamına dayandırmak yanıltıcı olur — kendi endpoint'ini kendi yük profilinle test et.
Built-in Araçlar: Bun'ın Platform İddiası
Bun'ın en özgün yanı runtime'ın ötesine geçmesi: bun test yerleşik test runner, bun build yerleşik bundler, bun install yerleşik paket yöneticisi, yerleşik shell scripting API'si ve Bun 1.4'te eklenen Bun.WebView (headless tarayıcı otomasyonu), Bun.Image (görsel işleme), Bun.markdown ve cron API'leri (bun.sh/blog/bun-v1.4, 20 Ağustos 2026). Bu, ayrı ayrı jest/webpack/npm/node-cron/puppeteer kurmak yerine tek binary ile gelmesi anlamına geliyor — küçük ve orta projelerde bağımlılık sayısını gözle görülür şekilde azaltıyor. Node.js tarafında ise felsefe tam tersi: çekirdek küçük tutulur, node --test gibi minimal yerleşik araçlar dışında ekosistem (Jest/Vitest, webpack/esbuild, npm/pnpm, node-cron) üçüncü-parti paketlerle sağlanır. Bu, esneklik ve olgunlaşmış, birbirinden bağımsız güncellenen araçlar sunar ama daha fazla konfigürasyon ve bağımlılık yönetimi gerektirir. Hangisi doğru: hızlı prototipleme ve küçük ekiplerde Bun'ın "hepsi dahil" yaklaşımı zaman kazandırır; büyük kurumsal projelerde her katmanı ayrı ayrı seçip değiştirebilme esnekliği genelde tercih ediliyor.
Üretim Dağıtımı, Hosting ve Kurumsal Risk
Node.js, systemd/Docker/PaaS ekosisteminde 2009'dan beri süregelen birinci-sınıf destek görüyor: Vercel, AWS Lambda, Railway, Fly.io, Google Cloud Run — hepsi Node runtime'ını resmi olarak listeliyor ve LTS sürüm takvimine göre görüntü (image) güncelliyor. Bun tarafında resmi ve metrikli bir üretim vakası var: Bun'ın v1.4 duyurusundaki "Production" bölümü, Bun üzerine kurulu büyük ve uzun ömürlü bir uygulama olan Claude Code'da üretim CPU kullanımının 2× düştüğünü — p99 %24'ten %10'a, p50 %5,8'den %2,5'e — grafikle birlikte yazıyor (bun.sh/blog/bun-v1.4). Bunu tartarken kaynağın Bun'ın kendi blogu olduğunu, bağımsız bir üçüncü-parti denetim olmadığını unutma. Node.js'in resmi LTS modeli (Active + Maintenance toplam 30 ay, v27'den itibaren yıllık-LTS planı) güvenlik yaması takvimini öngörülebilir kılıyor; Bun tarafında v1.4 → v1.4.1 → v1.4.2'nin iki hafta içindeki hızlı ardışıklığı, aktif geliştirmenin kanıtı olduğu kadar henüz "kur ve unut" seviyesinde oturmadığının da işareti.
Bellek, Soğuk Başlatma ve Gerçekçi Beklentiler
Bun'ın JavaScriptCore temeli soğuk başlatmada ölçülebilir avantaj sağlıyor: Linux'ta hello.js Bun 1.4'te 5,1 ms'de, Node.js 26'da 27,2 ms'de açılıyor; tepe bellek 14,6 MB'a karşı 44,5 MB. Windows'ta aynı test 15,5 ms'e karşı 40,1 ms. Yük altında tepe bellekte (1.000.000 istek, 64 bağlantı) fastify Bun'da 120 MB, Node'da 156 MB; Express 92 MB'a karşı 145 MB; node:http 81 MB'a karşı 107 MB; Next.js 285 MB'a karşı 342 MB. Next.js App Router SSR'da 4.000 sayfa boyunca Bun 238 MB'da oturuyor, Node 410 MB'da. Tabloyu tersine çeviren satır da var: Vite dev sunucusunda Bun 233 MB, Node 214 MB — orada Node kazanıyor. Kritik uyarı: bu rakamların tamamı Bun'ın kendi (vendor) ölçümü, tarafsız bir üçüncü-parti benchmark değil; ölçüm koşulları senin iş yükünle birebir örtüşmeyebilir. Pratik sonuç: kısa ömürlü, sık yeniden başlayan iş yüklerinde (CLI, cron, serverless) Bun'ın başlatma avantajı gerçek ve büyük; native modül bağımlılığı olan uzun ömürlü API sunucularında ise geniş native modül desteğini ve olgun ekosistemi Node lehine tartmalısın.