- View Transitions API gibi modern CSS özelliklerinin ortaya çıkmasıyla, artık akıcı sayfa geçişleri için SPA yapısına ihtiyaç kalmayan bir döneme girildi
- Çoğu SPA sitesi, gerçekte beklenen düzeyde performans veya akıcı deneyim sunamıyor; aksine ağır JavaScript kodu kullanıcı deneyimini kötüleştirme eğiliminde
- Chromium tabanlı tarayıcılarda yerel sayfa geçişleri ve Speculation Rules kullanılarak, JavaScript olmadan da hızlı ve doğal gezinme deneyimi oluşturmak mümkün
- SPA’nın karmaşık yapısı tarayıcı optimizasyonlarını engellediğinden, gerçek web sitelerinde HTML ve CSS merkezli MPA yapısı daha hızlı ve yönetimi daha kolay
- Bundan sonra gereksiz SPA kullanımından kaçınıp, modern CSS ve yerel özelliklerden yararlanarak verimli ve bakımı kolay web siteleri geliştirmek gerekiyor
Giriş: SPA’nın sonu ve modern CSS’in yükselişi
- Son dönemde View Transitions API gibi modern CSS özelliklerinin kullanıma girmesiyle, geleneksel SPA’ların (single-page application) sunduğu temel avantajlar artık gerekli olmaktan çıktı
- Hâlâ birçok geliştirme ekibi React, Vue gibi SPA framework’lerini seçiyor; ancak bu kararın temelinde performans değil, etkileşim ve akıcı gezinme deneyimi konusundaki yanlış kanılar yatıyor
- Akıcı gezinme için SPA’nın zorunlu olduğuna inanmak artık eski dönemden kalma bir düşünce biçimi
SPA’nın vaadi ile gerçeklik arasındaki fark
- SPA’lar bir zamanlar en doğal sayfa geçişlerini oluşturmanın tek yoluydu, ancak artık durum böyle değil
- Birçok SPA’da şu sorunlar görülüyor:
- Sadece yükleme durumuna uygulanan fade efektleri var; gerçek içerik geçişlerinde akıcılık eksik
- Kaydırma konumunun geri yüklenmesi sorunları ve tutarsız odak yönetimi
- Render/hydration gecikmeleri nedeniyle gezinme gecikmesi
- Layout shift ve içerik sıçramaları, skeleton loading gibi problemler
- Sağladığı faydaya göre gereksiz karmaşıklık ve aşırı JavaScript kullanımı
- Önde gelen SPA framework’leri (Next.js, Gatsby, Nuxt vb.), temel yerel tarayıcı davranışlarını taklit etmek için büyük miktarda JS kodu ekliyor
- Sonuç olarak yerel doğallık feda ediliyor, hız düşüyor ve SEO da zarar görüyor
Web platformunun gelişimi ve CSS’in değişen rolü
- Modern Chromium tabanlı tarayıcılar (Chrome, Edge vb.) artık yerel ve deklaratif sayfa geçişlerini destekliyor
- View Transitions API sayesinde, JavaScript olmadan da belgeler arasında ya da tam sayfa düzeyinde akıcı animasyonlar oluşturulabiliyor
- Temel yetenekler şunlar:
- Sayfalar arasında fade efekti (yalnızca 3-4 satır CSS ile uygulanabilir)
- Küçük görselden detay görseline doğal geçiş gibi paylaşılan öğe animasyonları
- Header, navbar gibi kalıcı öğelerin korunması
- Gerçek URL ve gerçek sayfa geçişi kullanıldığı için SEO, bağlantı paylaşımı, back/forward cache gibi konularda azami uyumluluk
CSS ve JS sinerjisinden tam yararlanmanın yolu
- Gerekirse, sayfa içi geçişlerde View Transition JavaScript ile elle de tetiklenebilir
- Örneğin tema geçişi, sekme değiştirme, dark mode geçişi gibi durumlarda yalnızca çok az miktarda JavaScript yeterli olur
Speculation Rules ve anında gezinme
- Speculation Rules, tarayıcının sayfaları önceden preload/prerender etmesini ve kullanıcı davranışlarını (ör. fareyle üzerine gelme) tahmin ederek anında gezinme sunmasını sağlar
- Deklaratif olarak
<script type="speculationrules"> ile ayarlanabilir
- Ön koşul: Sayfa hafif ve optimize edilmiş olduğunda performansı en üst düzeye çıkarır; ağır sayfalarda ise kaynak israfına yol açabilir
Tarayıcının yerel özelliklerine saygı ve bfcache
- bfcache (Back/Forward Cache), kullanıcı geri/ileri gittiğinde tüm sayfayı anında bir anlık görüntü olarak geri yükler
- Bunun için saf HTML ve CSS tabanlı, temiz bir mimari gerekir; SPA’larda olduğu gibi yönlendirmeyi ele geçiren yapılarda bu avantaj kullanılamaz
- Sonuç olarak, modern tarayıcılar basit ve sağlam web sitelerini ödüllendiren bir yöne evriliyor
SPA ve MPA performans karşılaştırması
- Ortalama bir SPA’da (Next.js baz alınarak):
- JS bundle boyutu: 1-3MB
- TTI (etkileşime hazır olma süresi): 3.5-5 saniye
- Route geçişi: sahte/simüle edilmiş
- SEO: karmaşık, sürdürmesi zor
- Kaydırma/anchor davranışı: kararsız
- Modern bir MPA’da (CSS geçişleri ve Speculation Rules ile):
- JS bundle: 0KB (yalnızca isteğe bağlı geliştirmeler)
- TTI: yaklaşık 1 saniye
- Route geçişi: gerçek yerel davranış
- SEO: çok kolay
- Akıllı kaydırma, odak, geçmiş: tarayıcının varsayılan davranışı ve tam destek
Web sitesi ile uygulama arasındaki fark: uygunluğu yeniden düşünmek gerekiyor
- Web sitelerinin büyük çoğunluğu gerçekte bir “uygulama” değildir; paylaşılan durum, istemci tarafı yönlendirme ve karmaşık etkileşimler gerektirmez
- Pazarlama sayfaları, dokümantasyon portalları, e-ticaret, bloglar gibi alanlar için HTML merkezli, hızlı yüklenen ve basit yapılar daha uygundur
- Her projede SPA yığınına yönelmek, aşırı karmaşıklık ve performans kaybı doğurabilir
- “Uygulama gibi görünsün” talebi
- Framework’ün projeye eklenmesi
- İstemci tarafı yönlendirme ve artan karmaşıklık
- Düşen performans ve ek optimizasyon ihtiyacı
- Buna rağmen yerel bağlantı geçişi + CSS animasyonu yapısından daha yavaş bir sonuç
Sonuç ve öneriler
- SPA’lar geçmişte platform sınırlamalarına karşı geçici bir çözüm gibiydi; ancak bugün bu sınırlamaların çoğu artık yok
- Artık şu yerel özellikleri aktif biçimde kullanmak mümkün:
- Gerçek sayfalar arası geçişler
- Speculation Rules ile anlık önceden render etme
- Progressive degradation’a dayanıklı yapılar
- Temiz markup, hızlı yükleme ve gerçek URL kullanımı
- Platformun sunduğu avantajlardan en yüksek düzeyde yararlanabilen mimariler
- Sırf “akıcılık” uğruna SPA’da ısrar etmek, karmaşıklık, performans ve bakım kolaylığı açısından bedel ödetir
- Sunucu tarafı render, gerçek sayfalar, CSS tabanlı animasyonlar, bilinçli ön yükleme ve minimum JS ile bugünün ihtiyaçlarına uygun, hızlı ve keyifli web siteleri üretmek mümkün
- 2025’in mevcut teknolojilerinden yararlanarak daha hızlı, daha basit ve herkes için daha davetkâr web deneyimleri hedeflenmeli
10 yorum
Başta sadece "akıcılık" nedeniyle SPA düşünülmesi gereken bir durumda, ben zaten akıcılıktan vazgeçip MPA olarak yazardım; o yüzden pek katılamıyorum...
Yazının zayıf kalan noktaları
SPA'nin asıl amacını daraltarak yorumluyor
View Transitions API gerçekten çok etkileyici, ancak bu tek başına SPA'ye artık ihtiyaç olmadığı anlamına gelmez.
Tüm web sitelerine aynı ölçütle bakıyor
Pazarlama sitesi ≠ dashboard ≠ e-ticaret uygulaması ≠ gerçek zamanlı iş birliği aracı
Her birinin farklı yapısal gereksinimleri vardır.
Pratikte SPA + SSR + MPA birlikte var olmaya devam ediyor
Next.js gibi hibrit framework'ler bunu iyi gösteriyor.
Statik varlıklar için SSG, giriş sonrası dashboard için CSR/SPA, arama motoru uyumluluğu için SSR gibi esnek kombinasyonlara ihtiyaç var.
Bence SPA, sadece kullanıcı deneyiminin değil, aynı zamanda yapısal iyileştirmenin de bir ürününe daha yakın.
SPA'nin gereksiz olduğu sayfalarda MPA + modern CSS iyi bir seçim olabilir, ancak SPA; yapı, durum, ölçeklenebilirlik ve bakım açısından hâlâ gereklidir. Modern CSS, SPA'yi "tamamlayabilir" ama "yerine geçemez" diye düşünüyorum.
SPA'yı view transition gibi şeylerle ikame edemeyeceğiniz örnekler arasında, sizin sunduğunuz vakalarda gerçek zamanlı iş birliği araçları dışında bir şey yok; ancak web sitelerinin büyük çoğunluğu gerçek zamanlı iş birliği aracı değildir. Pazarlama siteleri, dashboard'lar ve e-ticaret uygulamalarının tamamını da SPA framework'lerini dışarıda bırakarak; server-side rendering, gerçek sayfalar, CSS tabanlı animasyonlar, bilinçli önceden yükleme ve asgari düzeyde JS kullanımı şartlarına sadık kalarak inşa etmek mümkündür. Bunu hedefleyen Rails ekosistemindeki Hotwire da var ve bunun Basecamp ile HEY gibi production örnekleri de mevcut. State management mı? Gerçek zamanlı iş birliği araçları gibi bir şey olmadığı sürece URL parametreleri, server session gibi sunucu tarafı yöntemler ya da local storage fazlasıyla yeterlidir. Sayfa geçişlerini görüp SPA benimseyen örnekler de elbette var (AGF resmi sitesinde olduğu gibi, Astro bile yeterliyken React'i benimseyen örnekler kesinlikle var) ve SPA'nın en temsilî avantajlarından biri olarak sıkça anılan şeyin sayfa geçişleri olduğunu da inkâr edemeyiz.
Mevcut SPA framework'lerinin ve bunlara dayalı frontend trendinin standart dışılaşmaya karşı sürekli tetikte olmayı gerektirdiği, ayrıca aşırı mühendisliğe ve gereksiz kaynak tüketimine yol açmaya elverişli olduğu doğru ama…
SPA kavramına da fazla dar bakılıyor ama bundan da öte, SPA framework'lerinin genel olarak geliştirme sürecinin tamamı üzerinde nasıl bir etki yarattığının anlaşılıp anlaşılmadığından şüphe duyuyorum.
Sadece View Transition API ile, CSS varsa her şeyin çözüldüğünü söylemek, başka bir ifadeyle bununla ilgisiz tüm işlevlerin ve bunu başarmaya yönelik tüm paradigma anlayışının bütünüyle anlamsız olduğunu söylemek demek; bu bana biraz fazla kibirli bir bakış açısı gibi geliyor.
Broşür sitesi yerine geçen düzeyde bir siteyi React ile yaptığınızda ortaya çıkan aşırı mühendislik ise bambaşka bir mesele.
Çoğu küçük ölçekli projede illa bir SPA framework'üne ihtiyaç olmadığına katılıyorum; ancak karmaşık etkileşimler, süreklilik taşıyan bir kullanıcı deneyimi ve buna bağlı bakım ile sürekli iyileştirmeyi gereksinim olarak taşıyan servislerde, CSS gelişmiş olsa da durumun böyle olmadığını düşünüyorum.
Açıkçası, daha elini bile sürmediğin Rust ya da Haskell için “ona gerek yok, artık modern C++ ile hepsi yapılıyor” demek gibi görünüyor.
Hmm, emin değilim. SPA framework'lerini kullanmanın amacı, akıcı geçişlerden ziyade kullanıcıyla karmaşık etkileşimler kurmak değil mi?
Sırf akıcı bir etkileşim için SPA framework’ü benimseyen örnekler elbette var. SPA uygulanan sitelerin önemli bir kısmıysa karmaşık etkileşimlere ihtiyaç duymuyor.
Büyük ölçüde katılıyorum
Çarpıcı bir örnek olarak React’in kendisi bile front-end’in Spring’i gibi.
Ağır ve karmaşık; işleri kolaylaştırıyormuş gibi görünse de aslında hafif işleri yapmak için daha karmaşık süreçler kurup sonra da o gereksiz yere karmaşıklaşmış süreci kullanışlı hale getiren tuhaf bir kolaylık sağlıyor.
Katılıyorum. Google Docs gibi karmaşık bir web uygulaması değilse Rails ekosisteminin geliştirdiği Howired da fazlasıyla yeterli olur; statik sayfalar içinse Astro’nun da yeterli olduğunu düşünüyorum.
Hacker News görüşü
SPA’ler, kullanıcının tek bir uygulamada uzun süre geçirdiği durumlarda anlamlıdır; yani başta büyük bir bundle yüklenir ve sonrasında uygulama yalnızca küçük ağ istekleriyle kullanılabilir. Akıcı geçiş efektleri sadece ekstra bir faydadır; bence SPA’lerin çözdüğü asıl problem bu değildir. İstemci tarafı yönlendirmesinin sayfa geçişleri için olduğu iddiası, SPA’lerin amacını yanlış anlamaktır. Eğer bu yanlış varsayımla SPA kullandıysanız bu yazı haklıdır, ama SPA’ler jQuery döneminde karmaşık uygulamalar için ortaya çıktı. Her
div’in mini uygulama gibi davrandığı, birçok küçük ağ isteğiyle senkronize edilen dev jQuery kod yığınları vardı. Eski tarayıcılarda ve yavaş internet ortamlarında tüm kodu her seferinde yeniden yüklemeden verimli çalışabiliyordu. Sonra React gibi framework’ler daha yapısal uygulama geliştirmeyi kolaylaştırarak bunu ileri taşıdı ve SPA’nin temel avantajı, uzun oturumlu kullanıcılar için büyük bundle’ı bir kez indirip önbelleğe alarak sonrasında ağ trafiğini en aza indirmesidir.(Yukarıdaki görüşten alıntı: "...if you shared that misunderstanding of SPAs and used them to solve the wrong problem, this article is 100% correct.") Buna tamamen katılıyorum. Yazar bir SEO danışmanı ve sanki sadece pazarlama sitelerine odaklanıyor. Gerçek uygulamalar (pazarlama sitesi olmayanlar) SPA’den büyük fayda sağlayabilir. Örneğin Google Maps’i SPA olmadan yaptığınızı düşünün; sadece sayfa geçiş animasyonları eklemek bile UX’i ciddi biçimde kötüleştirirdi.
“Sadece jQuery spagettisi yığıldı” deniyor ama ben gerçekten IIFE gibi erken dönem JS tasarım kalıplarını kullanarak kodu yapılandırıyor, modülleri gecikmeli yüklüyor ve kodu obfuscate ediyordum. Benim deneyimimde frontend’i yapılandırma girişimleri arasında en büyüğü AngularJS idi; Java geliştiricilerine çekici gelmesinin nedeni de modülerlik, DI ve test kolaylığıydı. İlk başta Backbone ile uygulama geliştirirken işlevlerin çoğunun backend’de olacağını varsayıp testleri pek önemsememiştim; sonra AngularJS ile yeniden yazınca frontend testleri çok daha arttı. Tabii bugünlerde Angular kodunun ya da Java kodunun ayrıntıcılığına, karmaşıklığına ve dolaylılığına karşı bir iticilik hissediyorum.
Yavaş ağ bağlantıları ve agresif önbellekleme ortamları, bence SPA ihtiyacı için güçlü nedenlerden biri (özellikle website’den çok uygulamalar için). İyi bir bağlantı varken tüm frontend’i bir kez indirip önbelleğe alırsanız, sonraki kullanım çok az bant genişliğiyle mümkün olur.
Modern CI/CD pipeline kullanan bir yerde çalışıyorsanız, günde birçok kez yapılan deploy ile o büyük JS bundle’ının tekrar build edilip önbelleğin geçersiz kılınması çok olasıdır. HTTP2 zaten 10 yıldır tarayıcılarda varsayılan ve multiplexing sayesinde JS bundle’larını büyük paketler halinde toplamanın gerekçesi kalmadı. Büyük bundle üreten SPA yaklaşımı, tarayıcı ve sunucunun modern özelliklerinden yararlanmıyor.
Yüklendikten sonra ağ isteklerinin gerçekten çok küçüldüğü örneklerin pratikte ne kadar yaygın olduğunu merak ediyorum. Benim gördüğüm çoğu SPA, yüklendikten sonra da büyük çağrılar yapıyordu ve HTML’i doğrudan göndermekten çok daha yavaştı. JSON’ın sihirli biçimde HTML’den daha iyi sıkıştığı iddiası da doğru değil. HTML de gayet iyi sıkışır. Pratikte ağ nedeniyle SPA daha iyi olur argümanı, neredeyse propaganda ya da batıl inanç gibi geliyor.
SPA’nin değeri sadece akıcı geçişlerde değil, kullanıcı yolculuğunun büyük kısmını istemci tarafında işleyip sunucuyu neredeyse düşünmemekte yatıyor. Örneğin 2025 yılında bile çoğu online mağazada filtre değiştirince ya da kategoriye girince tüm sayfanın yeniden yüklenip verinin baştan alınması sinir bozucu. Kullanıcı kategoriler arasında gidip gelirken birden fazla istek yapıyorsa, tüm kataloğu bir kez istemciye indirip sonrasında sunucuya danışmadan filtreleyebilmek UX’i çok iyileştirir. Elbette veri çok olur denebilir ama çoğu e-ticaret kategorisi birkaç KB yeterlidir ve tek bir ürün fotoğrafından bile küçüktür. 2005’ten beri böyle uygulamalar yapıyorum ve bunun neden daha yaygınlaşmadığını hâlâ anlayamıyorum.
Bence tam sayfa yeniden yüklemenin en can sıkıcı tarafı veri boyutu değil, sitenin verimsizliği. Gerçek veri birkaç KB ama sayfanın kendisi 100MB indiriyor ve tarayıcı 1GB RAM tüketiyor. Mesela Hacker News çoğunlukla yeniden yüklenen gezinme kullanmasına rağmen eski dizüstülerde iyi çalışıyor. Buna karşılık DoorDash gibi bir SPA aynı cihazda 30 saniye sürüyordu ve gerçekten yemek sipariş etmek 3 dakikadan fazla aldı. Arayüzün görünmesi için 2,5 dakika beklemek gerekti ve bunun neredeyse tamamı tam yeniden yükleme değildi.
HTMX gibi araçlar bu sorunun büyük kısmını çözüyor. SPA yaklaşımı sonuçta frontend ve backend diye iki ayrı uygulama yapmak anlamına geliyor. Ben, çoğu şeyi server-side yapıp istemci tarafına sadece basit etkileşimler (göster/gizle, aç/kapat, efektler vb.) eklemenin daha iyi olduğunu düşünüyorum. Elbette SPA’nin faydalı olduğu yerler var.
Benzer bir deneyim olarak, bazı kişisel projelerimi statik web sunucusunda barındırıyorum. On binlerce ayrı sayfa render etmek yerine, tek bir JSON dosyasıyla SPA içinde istemci tarafında render ediyorum. Github Pages da kullandım. Son dönemde ise sqlite veritabanının wasm build’ini kullanıp HTTP Range Requests ile sadece gereken sayfaları alan bir yapı da deniyorum. sqlite’ın Full Text Search özelliği çalışıyor ama kısa aramalarda tüm tabloyu almak gerekmesi can sıkıcı. Belki tüm DB’yi indirip FTS tablosunu yerelde oluşturmak daha iyi olabilir.
Karşı argüman örneği de var: örneğin “sci-fi” kategorisini Shift-click ile yeni sekmede açmak istediğinizde, MPA’de bunu neredeyse bedavaya alırsınız ama SPA’de ayrıca yönetmeniz gerekir, bu da uğraştırıcıdır. Eğer kategori linki yoksa ve sadece Select Box ile erişiliyorsa UX pek iyi değildir.
Genel olarak şirketler kullanıcının tüm kataloğu indirmesini istemez; çünkü rakiplerin bunu kolayca analiz etmesini istemezler. Ayrıca kitap satışı gibi durumlarda yüz binlerce ürün olabilir; hepsini tek seferde taşımak hem kullanıcı deneyimi açısından hem de bant genişliği/bellek açısından verimsizdir.
SPA’nin amacı kesinlikle sayfa geçişi değildir. Sayfa geçişlerini gerçekten iyi yapan SPA neredeyse yok. Örneğin Next.js’te route loading yapısı nedeniyle sayfa geçişi uygulamak neredeyse imkânsıza yakındır. Ben gerçekten Next.js’e düzgün sayfa geçişleri eklemeyi denedim ve tam bir kâbustu. SPA’nin belirgin avantajı bana göre iki tane: birincisi, çoğu uygulama bir miktar etkileşim ister (HTML/CSS tek başına yeterli değildir) ve React ile saf HTML’i karıştırmak büyük bir acıdır, özellikle global state gerektiğinde. İkincisi, sayfa yapısının tamamını önceden yüklemek sonraki veri yüklemelerini hızlandırır; tıklamadan hemen sonra tepki verip loading göstermek, 500ms sonra tepki vermekten daha iyi bir UX sunar (tabii 100ms altındaysa başka). Tüm sayfayı yeniden çizmek gerekmediği için frontend performansı, sadece HTML ile yakalanamaz. Basecamp gibi SPA olmadan iyi yapılmış karmaşık web uygulamaları var ama 30 saniye gezinince bile SPA performansını yakalayamıyorlar. Web’in doğasına uygun şekilde çalışmasını isterim ama Next.js ve SPA’nin kattığı karmaşıklık, uygulamaları daha hızlı ve daha tepkisel hâle getirirken geliştirmeyi de zorlaştırdı ve büyük bundle’lar üretme gibi zararlar doğurdu. Yine de sadece HTML’in bugün hâlâ SPA performansını yakalayabildiğini düşünmüyorum.
Bu SEO danışmanının hangi evrende yaşadığını bilmiyorum. Next ve Nuxt’ı SPA’ye karşıt örnek framework’ler gibi vermek tamamen yanlış. 1. Next ABD/Batı dünyasında neredeyse tamamen hâkim ve insanlar yeni bir React uygulamasından söz ederken çoğu zaman Next’i kastediyor. Vue tarafında da Nuxt neredeyse standart; Nuxt = Vue ekosisteminin Next’i. Yani insanlar farkında olmadan Next ve MPA stratejisini seçiyor. Sarkaç MPA yönüne fazla kaydı; bu yüzden insanlara tam tersine SPA denemelerini önermek gerekir. Son 8 yıl MPA’ye dönüş furyasıydı ve artık Facebook bile belgelerinde Create React App yerine Next’i öneriyor. 2. Next’in karmaşıklığına dair şikâyetler, modern MPA stratejisinin zorluğuna dair; SPA tarafında anlatılan hikâye ise neredeyse 10 yıldır değişmedi. 3. MPA geliştirmek SPA’den çok daha zor; çünkü server ve client ayrımını çok daha sıkı korumanız gerekiyor. 4. SPA içinde MPA tarzı veri yüklemek istiyorsanız bu geliştiricinin tercihidir; artılarını eksilerini de kendisi taşır. Veriyi önceden yükleyip SPA navigasyonunu anlık hâle de getirebilir. 5. Gerçekten SEO’nun önemli olduğu ana frontend dışında çok daha fazla iç dashboard ve uygulama var. React geliştiricileri genelde buralarda çalışıyor; bu yüzden ilk frame’i kusursuz verme baskısı yüzünden gereksiz yük almamak önemli.
SPA’yi küçümseyen tonun adil olmadığını düşünüyorum. SPA kesinlikle daha fazla emek ister ama kesinlikle daha çok avantaj da sunar. Uygulama gibi hissettiren bir UX üretmenin uzun süre tek yolu SPA idi. Yazar uygulama yorgunluğundan söz ediyor ama gerçekten bir “uygulama” deneyimi vermek istiyorsanız SPA neredeyse tek yoldur. Ağır bir SPA ile hafif bir website’yi (statik siteyi) karşılaştırmak uygun değil. Birisi hafif bir website yapabiliyorsa aynı şekilde hafif bir SPA de yapabilir. SPA de website de verimsiz yapılırsa yavaş ve ağır olur. SPA’ye çok yatırım yapmış biri olarak, daha az çabayla aynı deneyimi verecek yöntemlerle çok ilgilendim ama bu yazı biraz görsel süsleme düzeyinde kalıyor. Görsel stil değerli olabilir ama SPA olup olmamaya karar verecek kadar etkili değil.
“SPA framework’ü olmadan linear.app yapmayı deneyin” demek mantıklı değil; “Native CSS transitions, SPA’nin en büyük avantajını (client routing) öldürdü” önermesi de anlamsız.
Linear bence SPA’ler içinde çok özel bir vaka. Buradaki öneri SPA’yi yasaklamak ya da JS’i tarayıcıdan tamamen çıkarmak değil. Linear’ın hızlı olmasının nedeni “offline-first” tasarımı ama bunu yapan hizmet sayısı çok az. Biletleme, forum, haber, blog ve bilgi odaklı sitelerde SSR tabanlı geliştirme çok daha iyi bence. SPA’yi sadece gerçekten gerektiği yerde kullanıp geri kalanını SSR ile hızlı geliştirmek ve CSS ile SPA gibi göstermek çok daha verimli.
SPA’nin hiç yeri yok değil ama kalan %99 sitenin SPA olmasına gerek yok.
SPA, view transitions’ın amacı değildir. Asıl yazı (TFA), sayfalar arası gösterişli geçişlerin önemli olduğunu ima ediyor gibi görünüyor ki bu yanlış. “CMO” ya da “brand manager”ı suçlamak yerine SPA’nin öz değerine odaklanılmalı. SPA, client-side logic için harika bir framework’tür; separation of concerns (frontend mantığını backend’den ayırma), daha iyi geliştirici deneyimi ve dolayısıyla daha hızlı geliştirme gibi pek çok avantaj sunar. Bu tür yazıların çok görünmesinin nedeni, benim bu yorumum gibi tartışma çekmeye uygun olmaları; aslında bence bu kadar ilgi hak eden yazılar değiller.
Benim açımdan SPA’nin esas vaadi akıcı geçişler değil, backend’den tamamen ayrılmış bir veri API’si ile frontend kurabilmek. Bu yüzden SSR ile client rendering’i karıştırmayı sevmiyorum. Ya düpedüz bir website olmalı ya da bir uygulama.
“SPA ile MPA arasındaki ölçüt ne?” diye merak ediyorum. Next.js tabanlı kişisel sitemde neredeyse her şey server-side render ediliyor. Teknik olarak SPA ama JS açıksa RSC ve client-side navigation çalışıyor; JS kapalıysa da client-only component’ler (ör. QR code generator) yedek içerikle gösteriliyor ve geri kalan her şey tamamen SSR render ediliyor, biraz daha yavaş olsa da gayet iyi çalışıyor. Bileşenleri server’da render etmemek daha fazla uğraştırıyor. Progressive enhancement en iyisi.
Window loadevent’inin kaç kez tetiklendiğine bakarak anlayabilirsiniz.Bir de SEO dünyasından ya da pandemi sonrası işe giren yeni web geliştiricilerinden SPA’nin sürekli yanlış anlaşılması ve küçümsenmesi gerçekten bunaltıcı. 2000’lerden beri geliştiren biri olarak söyleyebilirim ki SPA’nin gerçek kökeni, asıl yazıda anlatılan “sahte vaatler” değil; 2000’lerin sonu ile 2010’ların başında mobile-first stratejinin yayılmasıyla frontend ve backend’in tamamen ayrılması ihtiyacıydı. Ondan önce frontend dediğiniz şey genelde server’da template ile HTML üretip üzerine biraz jQuery serpmekten ibaretti. Ama artık hem mobil hem masaüstü uygulamalar aynı iş mantığını ve aynı DB’yi kullanmak zorundaydı; bu yüzden REST yapısı, Roy Fielding’in tezine yeniden dönülmesi, service-oriented architecture ve API’leri dışa açma akımı öne çıktı. Maliyet optimizasyonu da önemli bir etkendi. Bu dönemde Ruby on Rails ya da Django gibi full-stack web framework’leri kısa süreli bir duraklama yaşadı. Node.js yükselirken tarayıcılar ve mobil cihazlar da giderek güçlendi; böylece birçok iş mantığını “edge device” tarafına, yani istemciye taşımak mümkün oldu. SPA’nin özü tam olarak budur. CSS’in bunu ikame edebileceğini düşünmüyorum.