İçeriğe atla

Kapatmak için ESC tuşuna basın

Claude Code testinde sunucu tarafı JavaScript framework’leri önde

Claude Code ile yapılan testte 12 JavaScript framework kıyaslandı: sunucu tarafı yığınlar agent maliyetinde öne çıktı, Angular en pahalısı oldu.

Yazar
Sezer Şanlıkan
Yayın
4 Kasım 2026,
Okuma
4 dakika
Bu haberde
  1. htmx nedir, ne işe yarar?
  2. Hono nedir, ne işe yarar?
  3. Fark neden faturaya yansıyor
  4. Maliyet farkı nereden geliyor
  5. JavaScript framework seçiminde neyi değiştirmeli
  6. Aynı ölçümü kendi ekibinizde kurmak
  7. Testin kapsamadığı alanlar

Socket’te geliştirici olan Nolan Lawson, 12 JavaScript framework için aynı Claude Code agent’ına PokéAPI tabanlı bir Pokémon uygulaması yazdırıp maliyet ve performansı karşılaştırdı. En düşük medyan maliyet 2,67 dolarla Hono ve htmx ikilisinden geldi. Angular 4,97 dolarla en pahalısı oldu ve beş denemenin ikisinde çalışan uygulama çıkaramadı.

htmx nedir, ne işe yarar?

htmx, HTML öğelerine eklenen özniteliklerle sunucudan HTML parçaları çekip sayfanın bölümlerini güncelleyen küçük bir JavaScript kütüphanesidir. Uygulama mantığını sunucuda tutup client tarafında az JavaScript yazmak isteyen ekipler kullanıyor. Ağır SPA framework’lerine sade bir alternatif olarak görülüyor.

Hono nedir, ne işe yarar?

Hono, farklı JavaScript runtime’larında çalışabilen hafif bir web framework’üdür. HTTP endpoint’leri ve sunucu tarafı HTML üretmek için kullanılıyor. Express gibi klasik Node.js framework’lerine daha küçük ve taşınabilir bir alternatif olarak tercih ediliyor.

Fark neden faturaya yansıyor

AI agent’a kod yazdıran ekipler için JavaScript framework seçimi artık doğrudan maliyet kalemi. Aynı model, aynı talimat ve aynı uygulama: Hono/htmx 2,67 dolar, Angular 4,97 dolar. Arada neredeyse iki kat var.

Angular tarafında asıl sorun para değil. Agent beş denemenin ikisinde çalışan bir uygulama bile teslim edemedi. Süre 17,2 dakikaya, token tüketimi 9,76 milyona çıktı.

Agent’ı hızlı ama bağlamı sınırlı yeni bir ekip üyesi gibi düşünün. Ne kadar az karar verip ne kadar az kod yazarsa o kadar az hata yapıyor. Lawson’ın vardığı sonuç da bu yönde: kurallı, API’si sık değişmeyen ve kısa kod yazdıran araçlar agent’la daha verimli çalışıyor.

Maliyet farkı nereden geliyor

Kaynaktaki sayılar üç ayrı etkene işaret ediyor:

  • Client ile sunucu arasında bölünme yok. Hono/htmx ve Astro tamamen sunucuda çalışıyor. İki tarafı eşitlemek için yazılan ve kontrol edilen kod ortadan kalkıyor.
  • Az kod, az output token. Hono/htmx 1.370, Nuxt 1.415 satırda bitti. Claude input ve output token’larını farklı fiyatlandırıyor. Bu yüzden Nuxt en az token’ı (3,85 milyon) harcadığı halde en ucuz olmadı.
  • Değişen API. SvelteKit’te agent, Svelte’nin yakın zamanda güncellenen yapısını çözmek için dokümantasyona tekrar tekrar döndü. Sonuç 4,28 dolar.

Üçüncü madde çoğu ekibin hesaba katmadığı bir bedel. Projeyi yeni bir major sürüme taşıdığınızda agent’ın dokümantasyonla vakit geçirdiği adımlar artabilir. Her geri dönüş, faturada ek token demek.

JavaScript framework seçiminde neyi değiştirmeli

Bu sonuç, büyük bir React kod tabanını taşımak için gerekçe değil. İlk üç sıra (Hono/htmx, Astro, Nuxt) birbirinin hata payı içinde kaldı. Yani sıralama modelin o günkü performansına göre değişebilirdi. Test uygulaması da basit bir veri gösterme sitesi.

Karar verirken projeyi şu şekilde ayırın:

  • Yeni, küçük ve içerik ağırlıklı bir proje: sunucu tarafı bir JavaScript framework burada agent maliyetini ve client’a giden JavaScript’i birlikte düşürüyor. Astro’nun LCP (Largest Contentful Paint) değeri 810 ms, Next.js’in 2.090 ms, TanStack Start’ın 2.028 ms.
  • SPA (Single-Page App) davranışı gereken proje: bu testte en ucuz seçenek Nuxt oldu. Vue tabanlı ve kurallı yapısı, veri aktarımı ile dosya tabanlı routing’i kendisi üstlendiği için agent’ın yazdığı boilerplate kodu azalttı.
  • Ekibin yıllardır bildiği büyük bir kod tabanı: Hacker News’teki itirazlar burada haklı. Agent’ın çıktısını inceleyip debug edecek olan insan. Tanıdık bir araçta review hızı, uygulama başına birkaç dolarlık tasarruftan daha değerli olabilir.

Aynı ölçümü kendi ekibinizde kurmak

Lawson’ın yöntemi, sıralamadan daha kullanışlı. Bir araç seçimi yapacaksanız şu dört unsuru kopyalayabilirsiniz:

  • Her yığın için beş bağımsız sandbox çalıştırması. Tek çalıştırmayla karar vermek, modelin rastgeleliğini ölçmekten öteye geçmiyor.
  • Accessibility tree üzerinden test. LLM’ler zaman zaman gerçek bir buton ya da input yerine sahte öğe koyuyor. Bu kontrolü agent’ın yazdığı UI kodları için CI pipeline’ına eklemek mantıklı.
  • Google Lighthouse ile transfer boyutu ve runtime performansı.
  • Framework’ün resmi MCP (Model Context Protocol) sunucusu, Claude plug-in’i ya da agent skill dosyası varsa agent’a verildi. Agent bunlara her zaman başvurmadı.

Takip edilecek metrikler: medyan maliyet, toplam token, input ve output dağılımı, build ve test süresi, başarısız çalıştırma oranı. Angular örneği, başarısızlık oranının tek başına maliyetten daha çok şey anlattığını gösteriyor.

Testin kapsamadığı alanlar

Test tek bir agent ile, Claude Code ile yapıldı. Başka bir model ya da agent farklı sıralama verebilir. Uygulamaların hepsi Lighthouse erişilebilirlik ve performans testlerini geçti; son kullanıcının hissedeceği fark ağırlıklı olarak yükleme süresinde kaldı.

Haber, bakım kolaylığının da ölçüldüğünü söylüyor ama bu boyuta ait sonuçları aktarmıyor. Ayrıntılı tablo için Lawson’ın kendi yazısına bakın. Agent’la yeni bir dahili araç ya da prototip çıkaracaksanız ilk denemeyi Astro veya Hono/htmx ile yapıp maliyeti kendi API faturanızla karşılaştırmak düşük riskli bir başlangıç.

İlgili haberler

Tüm haberler

Yeni yazılardan haberdar olun

Sunucu, Kubernetes, DevOps ve güvenlik üzerine yeni yazılar ve site duyuruları e-postanıza gelsin. Reklam yok, adresiniz kimseyle paylaşılmaz.

© 2021–2026 Sezer Şanlıkan