2026'da Frontend Stack'im: Üretkenlik, Tip Güvenliği ve Üretim Gözlemi

Frontend tarafında her yıl yeni araçlar çıkıyor, ama üretim projelerinde kalıcı olanlar genellikle en çok konuşulanlar değil; günlük işi sessizce kolaylaştıranlar oluyor.

Benim için iyi bir frontend stack'i üç şeyi aynı anda çözmeli: hızlı başlamalı, büyüdükçe dağılmamalı ve üretimde hata olduğunda bana yeterli iz bırakmalı. Sadece "developer experience" iyi diye bir aracı seçmek artık yetmiyor. Araç, ekip büyüdüğünde, veri akışı karmaşıklaştığında, tasarım sistemi genişlediğinde ve gerçek kullanıcılar hatayla karşılaştığında da değer üretmeli.

Bu yazı bir "en iyi araçlar" listesi değil. Daha çok 2026'da üretim uygulaması geliştirirken tekrar tekrar döndüğüm frontend araçlarının kısa bir envanteri.

Temel Seçim: Next.js mi Vite mı?

Artık her proje için tek bir framework seçmeye çalışmıyorum. Projenin doğası karar veriyor.

İçerik ağırlıklı siteler, bloglar, dokümantasyonlar, SEO beklentisi yüksek sayfalar ve pazarlama siteleri için Next.js hâlâ çok güçlü bir varsayılan. Dosya tabanlı routing, SSR, image optimization, metadata yönetimi ve Vercel ile dağıtım akışı bu tür projelerde işleri ciddi şekilde sadeleştiriyor.

Ama her React uygulaması Next.js olmak zorunda değil. Yönetim paneli, müşteri portalı, iç araç, SaaS dashboard'u veya tamamen auth arkasında çalışan bir SPA geliştiriyorsam, çoğu zaman Vite + React + TypeScript daha temiz bir başlangıç sağlıyor.

Vite 8 ile Rolldown'ın tek ve Rust tabanlı bundler olarak gelmesi bu ayrımı daha da belirginleştirdi. Daha hızlı production build'leri, daha tutarlı geliştirme/production pipeline'ı ve düşük konfigürasyon ihtiyacı özellikle klasik SPA projelerinde hissediliyor.

Buradaki pratik soru şu: Gerçekten sunucu tarafı rendering'e, framework seviyesinde routing'e ve platform özelliklerine ihtiyacınız var mı? Yoksa hızlı, sade ve iyi tiplenmiş bir istemci uygulaması mı geliştiriyorsunuz?

İkinci senaryoda Vite genellikle daha az sürtünmeyle ilerliyor.

TypeScript ve pnpm: Tartışmasız Varsayılanlar

Yeni projelerde TypeScript'i strict: true olmadan başlatmak bana artık teknik borcu en baştan kabul etmek gibi geliyor. TypeScript mükemmel değil, ama refactor yaparken, API sözleşmeleri değişirken veya büyük bir form akışını düzenlerken sağladığı güven maliyetinden çok daha yüksek.

Özellikle frontend'de hataların önemli bir kısmı "bu değer burada gerçekten var mı?", "bu alan string mi number mı?", "bu mutation hangi sonucu döndürüyor?" gibi küçük belirsizliklerden çıkıyor. Strict TypeScript bu belirsizlikleri derleme aşamasına çekiyor.

Paket yöneticisi tarafında ise pnpm benim varsayılanım. Hızlı kurulum, content-addressable store sayesinde düşük disk kullanımı ve workspace desteği onu uzun ömürlü projeler için çok mantıklı yapıyor. Bir proje ileride monorepo'ya dönüşürse araç değiştirmek gerekmiyor.

Bun da ciddi bir alternatif hâline geldi, özellikle runtime ve test tarafındaki hızıyla dikkat çekiyor. Yine de üretim projelerinde paket yönetimi için bugün hâlâ pnpm'e daha çok güveniyorum.

Tailwind CSS ve shadcn/ui

CSS yazmayı tamamen bırakmadım, ama artık daha az özel CSS yazıyorum.

Tailwind CSS, arayüzü dosya değiştirmeden hızlıca şekillendirme imkânı veriyor. Utility class yaklaşımı ilk bakışta gürültülü görünebilir; fakat ekip içinde tutarlılık sağlama, responsive davranışları görünür kılma ve tasarım kararlarını bileşenin yanında tutma açısından pratik.

shadcn/ui ise bambaşka bir avantaj sunuyor: bileşeni npm paketi olarak tüketmiyorsunuz, kodu projenize alıp sahipleniyorsunuz. Button, Dialog, Dropdown, Command, Tabs gibi temel parçalar erişilebilirlik ve kompozisyon açısından iyi bir başlangıç veriyor; ama nihai karar sizin repoda kalıyor.

Bu yaklaşım özellikle ürün ekiplerinde çok değerli. Bir bileşenin davranışını değiştirmek için dış paketin kararını beklemiyorsunuz. Dosyayı açıp düzenliyorsunuz. Tasarım sistemi büyüdükçe bu sahiplik hissi daha da önemli hâle geliyor.

Storybook: Her Proje İçin Değil, Doğru Proje İçin Çok Güçlü

Storybook'u küçük ve tek seferlik projelere otomatik olarak eklemiyorum. Çünkü her hikâyenin bakım maliyeti var.

Ama uygulama 20-30 tekrar kullanılabilir bileşeni geçtiyse, bir tasarım sistemi oluşmaya başladıysa veya tasarımcılarla sürekli varyant konuşuluyorsa, Storybook ciddi zaman kazandırıyor.

Bir Button bileşeninin tüm variant, size, disabled, loading ve error durumlarını tek yerde görmek; bir Dialog'un uzun metinle, küçük ekranda veya boş veriyle nasıl davrandığını hızlıca kontrol etmek; tasarım ve geliştirme arasındaki iletişimi iyileştiriyor.

shadcn/ui ile birlikte kullanıldığında Storybook yalnızca demo ortamı değil, yaşayan dokümantasyon hâline geliyor.

TanStack Query ve TanStack Router

React uygulamalarında en çok karmaşa çıkaran alanlardan biri server state. Veriyi useEffect ile çekmek, loading/error durumlarını manuel taşımak, cache invalidation'ı elle yönetmek ve yarış koşullarını temizlemek bir noktadan sonra sürdürülemez hâle geliyor.

TanStack Query bu yüzden frontend stack'imin ana parçalarından biri. useQuery, useMutation ve useInfiniteQuery ile okuma, yazma ve sayfalama akışları aynı zihinsel modele oturuyor. Cache, background refetch, optimistic update ve retry davranışları uygulama genelinde tutarlı hâle geliyor.

SPA tarafında routing için de TanStack Router giderek daha cazip. En güçlü tarafı tip güvenliği. Route parametreleri, search parametreleri ve loader dönüşleri TypeScript tarafından uçtan uca görülebiliyor. URL'den gelen id değerini her yerde elle cast etmek yerine route tanımı zaten doğru şekli söylüyor.

Eğer mevcut bir React Router projesi sağlıklı ilerliyorsa değiştirmek şart değil. Ama sıfırdan bir SPA başlatıyorsam TanStack Router bugün daha iyi bir varsayılan gibi duruyor.

Zustand: Gerektiğinde Küresel State

Client state için yaklaşımım basit: önce component state, ihtiyaç büyürse store.

Bir state tek bir bileşende yaşıyorsa useState yeterli. Birkaç yakın bileşen arasında paylaşılıyorsa state'i yukarı taşımak çoğu zaman daha doğru. Ama state route'lar arasında dolaşıyorsa, farklı ekranlarda aynı anda okunup yazılıyorsa veya uygulama davranışının merkezi bir parçasıysa Zustand devreye giriyor.

Zustand'ın sevdiğim tarafı törensiz olması. Store bir fonksiyon, okumak bir hook, provider zorunluluğu yok. Sepet, auth kullanıcı özeti, sidebar açık/kapalı durumu, filtre tercihleri, undo/redo geçmişi gibi state'ler için yeterince sade ve güçlü.

Kural şu: global store'u erken kurmayın. Ama gerçekten ihtiyaç olduğunda da fazla ceremony ile uğraşmayın.

Zod: TypeScript'in Bittiği Yerde

TypeScript kod yazarken çok değerli, ama runtime'da ortadan kayboluyor. Bu yüzden güven sınırlarından geçen her veriyi doğrulamak gerekiyor.

API response'ları, form input'ları, environment variable'ları, localStorage'dan dönen değerler, URL search parametreleri ve webhook payload'ları benim için doğrulama gerektiren alanlar.

Zod burada en pratik çözüm olmaya devam ediyor. Aynı şemadan hem runtime validation hem de TypeScript tipi üretmek, özellikle form ve API katmanlarında ciddi güven sağlıyor.

Önemli nokta şu: Zod'u her objeye serpmek değil, güven sınırlarında kullanmak. İçeride zaten doğrulanmış veriyle çalışıyorsanız her fonksiyonda tekrar doğrulama yapmak gereksiz yük oluşturur.

Oxlint ve Oxfmt: Hız Alışkanlık Değiştirir

Lint ve format araçları yavaş olduğunda ekipler onları daha az çalıştırır. CI'da bekler, editörde kapatır, commit öncesi geçiştirir.

Oxlint ve Oxfmt bu yüzden ilginç. Rust tabanlı araç zinciri sayesinde büyük kod tabanlarında bile lint ve format süresi hissedilir biçimde düşüyor. Bu yalnızca "daha hızlı komut" meselesi değil; araç yeterince hızlı olduğunda onu kaydetme anında, commit öncesinde ve lokal geliştirme sırasında daha sık kullanıyorsunuz.

Prettier ve dprint hâlâ çok iyi seçenekler. Özellikle farklı dosya formatları, ekip alışkanlıkları veya mevcut konfigürasyonlar varsa onları değiştirmek gerekmeyebilir. Ama yeni ve büyük bir frontend kod tabanında hızlı lint/format hattı kuracaksam Oxc ekosistemini ciddi şekilde değerlendiririm.

Vitest, Playwright ve MSW

Test stratejisinde tek araçla her şeyi çözmeye çalışmıyorum.

Vitest, unit ve component testleri için yeterince hızlı ve Vite ekosistemiyle doğal çalışıyor. TypeScript, JSX ve ESM tarafında ekstra konfigürasyon yükü az. Küçük testler hızlı döndüğü için geliştirme sırasında gerçekten kullanılabiliyor.

Playwright, uçtan uca testlerde benim varsayılanım. Tarayıcı otomasyonu, trace viewer, ekran görüntüsü/video desteği ve debugging deneyimi E2E testleri daha az korkutucu hâle getiriyor. Her şeyi E2E ile test etmek yerine kritik akışları seçmek daha sağlıklı: login, ödeme, kayıt, ana kullanıcı yolculuğu gibi.

MSW ise bu iki katmanı birbirine bağlayan parça. Fetch seviyesinde istekleri yakalayabildiği için aynı handler'lar Vitest'te, Playwright'ta, Storybook'ta ve lokal geliştirme ortamında kullanılabiliyor. TanStack Query kullanan bir uygulamada gerçek backend'e bağımlı kalmadan güvenilir test yazmayı kolaylaştırıyor.

Benim ideal ayrımım şöyle: Vitest her commit'te ve geliştirme sırasında çalışır. Playwright PR'da küçük bir smoke suite, geceleri veya release öncesi daha geniş bir suite koşar. MSW handler'ları ise fixture ve schema'lara yakın durur.

Sentry: Üretimde Gerçek Kullanıcı Ne Yaşadı?

Uygulama yayına çıktıktan sonra soru değişiyor. Artık "kod doğru mu?" değil, "gerçek kullanıcılar nerede zorlanıyor?" sorusunu cevaplamak gerekiyor.

Sentry, hata izleme tarafında zaten güçlü: stack trace, breadcrumb, release bilgisi, tarayıcı ve kullanıcı bağlamı, frontend hatalarını anlamak için gerekli temel izleri sağlıyor.

Benim için asıl farkı yaratan taraf ise Session Replay. Bir hatanın hangi kullanıcı adımlarından sonra oluştuğunu, tıklamaları, scroll davranışını, console çıktısını ve network isteklerini aynı zaman çizgisinde görmek debugging süresini ciddi şekilde kısaltıyor.

Log tek başına bazen "ne oldu?" sorusunu cevaplar. Replay ise "kullanıcı oraya nasıl geldi?" sorusunu cevaplar. Frontend hatalarında genellikle eksik olan parça tam olarak budur.

Kısa Özet

2026'da benim üretim frontend stack'im kabaca şöyle şekilleniyor:

• Next.js: İçerik, SEO, SSR ve platform özellikleri gereken projeler
• Vite + React + TypeScript: Auth arkasındaki SPA'lar, dashboard'lar ve iç araçlar
• pnpm: Hızlı, disk dostu ve workspace uyumlu paket yönetimi
• Tailwind CSS + shadcn/ui: Hızlı, sahiplenilebilir ve erişilebilir arayüz temeli
• Storybook: Bileşen sayısı büyüyen ürünlerde yaşayan UI dokümantasyonu
• TanStack Query + TanStack Router: Server state ve tip güvenli routing
• Zustand: Gerçekten paylaşılan client state için sade store
• Zod: Runtime doğrulama gereken güven sınırları
• Oxlint + Oxfmt: Hızlı lint ve format deneyimi
• Vitest + Playwright + MSW: Unit, component, E2E ve network mocking hattı
• Sentry: Üretimde hata, replay ve kullanıcı bağlamı

Bu araçların ortak noktası tek başlarına büyük platform olmaya çalışmamaları. Her biri belirli bir problemi çözüyor ve diğerleriyle iyi birleşiyor.

İyi stack biraz da budur: geliştirme sırasında yolunuza çıkmaz, uygulama büyüdüğünde dağılmaz ve üretimde bir şey kırıldığında sizi karanlıkta bırakmaz.