{post.title}
{post.excerpt}
--- title: "React'a İhtiyacın Olmayabilir 🤔" description: "React'in ne zaman gereksiz olduğunu ve içerik odaklı web siteleri için daha basit teknolojilerin gücünü yeniden keşfetmeyi konuşuyoruz." slug: "reacte-ihtiyacin-olmayabilir" date: 2026-02-23 tags: ["react", "web-geliştirme", "performans", "vanilla-js", "astro", "ssr"] imageURL: "" lang: "tr" social_post: | React her frontend projesi için varsayılan cevap oldu ama çoğu zaman gereksiz. jQuery'den sonra aynı döngüyü tekrarlıyoruz. Blog, landing page, içerik sitesi yapıyorsan vanilla JS, Astro veya htmx yeterli. Basitliği yeniden keşfetmenin zamanı geldi. --- React, frontend geliştirmede varsayılan cevap haline geldi. Web sitesi mi yapacaksın? React. Biraz etkileşim mi lazım? React. Blog mu açıyorsun? O bile bir şekilde React. Ama bu arada daha basit ve birçok durumda daha uygun çözümleri gözden kaçırdık 🤔 İçerik sektöründe çalışırken, Server-Side Rendering (SSR), minimal JavaScript ve Astro gibi hafif, hızlı yüklenen sayfalara öncelik veren framework'lere doğru ciddi bir kayma yaşadım. React'in ne zaman gereksiz olduğu hakkında dürüst bir konuşma yapmanın zamanı geldi. ## React Varsayılan Tuzağı Bu durum bana on yıl önceki "No jQuery" hareketini hatırlatıyor. [youmightnotneedjquery.com](https://youmightnotneedjquery.com/) bize vanilla JavaScript'in jQuery'nin yaptığı çoğu şeyi yapabildiğini göstermişti, hatırlıyor musunuz? Tarayıcılar native API'ler sunuyorken jQuery'nin 30kb yükünü taşımanın mantıksız olduğunu topluca fark etmiştik. Aynı patern şimdi React ile tekrarlanıyor. jQuery nasıl her JavaScript ihtiyacı için varsayılan cevap olduysa, React de her frontend gereksinimi için öyle oldu. Tek fark şu: bu sefer maliyet jQuery'nin 30kb'ı kadar masum değil, çok daha yüksek. React gerçek bir sorunu çözdü (Facebook için). Milyonlarca kullanıcıyla devasa uygulamalarda karmaşık state yönetimi. Ama çoğumuz Facebook yapmıyoruz. Yaptığımız şeyler genelde: - Bir iletişim formu olan pazarlama siteleri - Biraz etkileşim içeren bloglar - Hızlı yüklenmesi gereken içerik siteleri - Minimum etkileşimli landing page'ler Ama biz yine de varsayılan olarak React'e uzanıyoruz ve yanında şunları da getiriyoruz: - Karmaşık build araçları - Büyük bundle boyutları (kendi kodunuzdan önce 45kb+) - Basit problemler için gereksiz mühendislik - Bağımlılık yönetimi baş ağrıları ## Daha Basit Alternatiflerin Gücü ### Vanilla JavaScript Düşündüğünüzden Güçlü Modern JavaScript, framework olmadan bile bileşen benzeri pattern'leri kaldırıyor: ```javascript function createComponent(name, onClick) { return ` `; } document.getElementById("app").innerHTML = createComponent( "World", "handleClick()" ); ``` JSX kadar şık olmayabilir ama basit etkileşimler için hızlı, hafif ve sıfır bağımlılık. ### Web Components: Framework'den Bağımsız Yapı Taşları Web Components tarayıcı-native ve her yerde çalışıyor: ```javascript class ToggleButton extends HTMLElement { connectedCallback() { this.innerHTML = ``; this.querySelector("button").onclick = () => this.toggle(); } toggle() { this.classList.toggle("active"); } } customElements.define("toggle-button", ToggleButton); ``` Build adımı yok, virtual DOM yükü yok. Sadece native tarayıcı API'leri. ### SSR Rönesansı Astro, Eleventy ve SvelteKit gibi framework'ler, minimal JavaScript ile sunucu tarafında render edilen HTML'in mükemmel kullanıcı deneyimleri sunabildiğini kanıtlıyor: - **Daha hızlı ilk yükleme**: HTML anında render oluyor - **Daha iyi SEO**: Arama motorları gerçek içeriğe ulaşıyor - **İyileştirilmiş Core Web Vitals**: Daha az JavaScript = daha iyi performans skorları - **Daha kolay deployment**: Statik dosyalar cache'lemesi ve sunması daha kolay ## React'e Gerçekten Ne Zaman İhtiyacın Var? React kötü bir şey değil, çoğu zaman gereksiz. React'e muhtemelen şu durumlarda ihtiyacın var: ### Karmaşık State Yönetimi - Birden fazla bileşenin state paylaşması - Gerçek zamanlı veri senkronizasyonu - UI'ın birçok yerini etkileyen karmaşık kullanıcı etkileşimleri ### Büyük Geliştirme Ekipleri - Geliştiriciler arasında tutarlı pattern'lere ihtiyaç duyulması - React'in ekosisteminden ve araçlarından faydalanılması - Dedicated frontend uzmanlarının olması ### Gerçek Web Uygulamaları - Çok sayıda etkileşimli element içeren dashboard'lar - Gerçek zamanlı işbirliği araçları - Birden fazla adım içeren karmaşık iş akışları ## İçerik Sektöründeki Dönüşüm İçerik odaklı işlerde fark ettiğimiz bazı gerçekler var: **Performans, geliştirici deneyimini yener.** Hızlı yüklenen bir blog yazısı, etkileşimli hale gelmesi 3 saniye süren React destekli bir yazıdan daha iyi dönüşüm sağlıyor. **SEO gerçekten önemli.** Sunucu tarafında render edilen içerik, özellikle içerik siteleri için arama görünürlüğünde hala kazanıyor. Üstelik bu artık Answering Engine Optimization'a evriliyor. LLM'ler sitenizi tüketirken gerçek içeriğe ihtiyaç duyuyor, bu da SSR'ı AI çağında daha da önemli kılıyor. **Basitlik daha iyi ölçekleniyor.** Daha az bağımlılık, daha az güvenlik güncellemesi, daha az uyumluluk sorunu ve daha az build hatası demek. ## Kullanım Senaryosuna Göre Pratik Alternatifler ### Statik Siteler İçin - **Astro**: Bileşen tabanlı, minimum JS - **Eleventy**: Basit, hızlı statik site üreticisi - **Hugo**: İçerik siteleri için çok hızlı build ### Hafif Etkileşim İçin - **Alpine.js**: 4kb'lık reaktif davranış - **htmx**: Özel JavaScript yazmadan dinamik HTML - **Vanilla JS**: Artık çok daha cross-browser standardize ve kararlı. Üstelik AI kod üreticileri gayet iyi vanilla JavaScript kodu üretebiliyor ### Performans Kritik Uygulamalar İçin - **Preact**: %90 uyumlulukla 3kb'lık React alternatifi - **Svelte**: Derleme zamanı optimizasyonu - **Vanilla JS**: Maksimum performans ve kontrol ## Astro Yaklaşımı Astro bu felsefeyi güzel bir şekilde örnekliyor. Bileşen benzeri kod yazıyorsunuz ama minimum JavaScript gönderiyorsunuz: ```astro --- // Bu build zamanında çalışır const posts = await getPosts(); ---
{post.excerpt}