Aşırı JavaScript odaklı geliştirme, web’i bozuyor

 (jonoalderson.com)
19 puan yazan baeba 2025-07-11 | 23 yorum | WhatsApp'ta paylaş

Özet Genel Bakış

Aşırı JavaScript odaklı geliştirme, web’i bozuyor

  • JS framework’lerinin aşırı kullanımı web sitesi karmaşıklığını artırıyor
  • Geliştirici deneyimi (DX), kullanıcı deneyimine (UX) baskın çıkıyor
  • Basit işler bile aşırı yapı gerektiriyor
  • Performans, erişilebilirlik ve bakım yapılabilirlik birlikte geriliyor
  • Çözüm, web’in asıl işlevlerini geri kazanmakta

Giriş

Geliştirici merkezli webin hastalıkları

  • Web sitelerinin çoğu gereğinden fazla karmaşık ve yavaş
  • JS merkezli tasarım, yapıyı kullanıcıdan çok geliştirici odaklı hale dönüştürdü
  • Basit bir değişiklik bile karmaşık bir dağıtım süreci gerektirir hale geldi

Ana Bölüm

Uygulama gibi görünme arzusu asıl neden

  • 2010’lardan sonra mobil uygulama trendiyle birlikte “uygulama gibi web” talebi arttı
  • Angular gibi JS framework’lerinin benimsenmesiyle karmaşıklık hızla yükseldi
  • Basit içerikler bile bir sistem gibi geliştirilmeye başlandı

Geliştirici deneyimi (DX) öncelikli kültür

  • En yeni framework’ler geliştirici kolaylığına odaklanıyor
  • Bileşen soyutlamaları, UX ile kopukluk yaratıyor
  • “Neden bir blogda React kullanılıyor?” sorusundan önce SSR uyumluluğu tartışılıyor

Karmaşıklığın standart haline geldiği gerçeklik

  • Basit işler için bile build, routing, API ve cache gibi çok katmanlı yapılar gerekiyor
  • Karmaşık stack yüzünden geliştirici olmayanlar içerik düzenleyemiyor
  • Teknolojik değişim çok hızlı olduğu için bakım zorlaşıyor

Framework aşırı kullanımının zararları

  • SSR, cache ve metadata gibi mevcut web işlevleri yeniden uygulanıyor
  • Performans düşüyor, bağımlılıklar artıyor
  • Sonuçta JS framework’leriyle CMS’i yeniden üretme gibi bir çelişki ortaya çıkıyor

Anlamsız tekrar ve maliyet

  • Framework benimseme ve terk etme döngüsü tekrarlandığı için kalıcı bir yapı oluşmuyor
  • Gerçek kullanıcı sorunlarını çözmekten çok iç karmaşıklığı çözmeye odaklanılıyor
  • İçerik pazarlaması, SEO ve deneyler yavaşlıyor; kullanıcı deneyimi kötüleşiyor

JS’nin aşırı kullanımından doğan kullanıcı ve pazarlamacı zararları

  • İçerik güncellemeleri için geliştirici müdahalesi gerekiyor
  • SEO ve sayfa kalitesi geriliyor
  • Kullanıcılar daha uzun yükleme süreleri ve etkileşim hatalarıyla karşılaşıyor

JS sadece bir araçtır, amaç değil

  • JS güçlü bir araç olsa da çoğu web sitesi için fazlasıyla ağır kalıyor
  • Statik içerik için HTML, CSS ve az miktarda JS çoğu zaman yeterli
  • Vanilla JS, sunucu tarafı render ve minimum script daha verimli olabilir

Yetkinin merkezileşmesi ve yapısal sorunlar

  • Karmaşık stack nedeniyle tüm işler geliştiricilere bağımlı hale geliyor
  • Organizasyon yapısında güç geliştirici merkezli olarak toplanıyor
  • Teknoloji kararları kullanıcıdan çok geliştirici kolaylığına göre alınıyor

Sonuç

Çözüm, webin özünü yeniden kazanmakta

  • Hızlı yüklenen, bulunabilen ve bakımı kolay web sitelerine ihtiyaç var
  • Sunucu tarafında render edilen HTML, semantik işaretleme ve minimum JS gibi temellere dönüş doğru yaklaşım
  • Teknolojiden çok sonuç odaklı bir yaklaşım gerekli
  • “Bu teknolojiyi neden kullanıyoruz?” sorusunu sormak gerekiyor
  • Basit ve kullanıcı odaklı web; performans, maliyet tasarrufu ve esneklik sağlar

İlgili okumalar

23 yorum

 
ws0051 2025-07-23

Sadece WordPress'e bakmak bile... sanırım yukarıdaki sorunun cevabı olur. Pazar payı da WordPress'te çok daha yüksek. Yavaş olmasına rağmen...
 
test831767639 2025-07-17

Dayanak olarak benchmark sonuçları olursa geliştiriciler buna daha çok katılabilir diye düşünüyorum. Aşırı framework odaklı kodlama varsa sitenin kesinlikle yavaşlayacağı doğru, ancak kişisel olarak site içi sayfa geçişleri açısından vanilla kodla yapılmış sitelerin, iyi optimize edilmiş framework kullanan sitelerden daha yavaş olduğuna daha sık rastladım. Elbette sadece statik veriden oluşan bir siteyse yalnızca HTML + CSS içeren bir yapının daha hızlı olması mümkün, ama günümüzde yalnızca statik veriden oluşan sitelerin ne kadar yaygın olduğundan pek emin değilim.
 
dnflajt3 2025-07-16

React ya da Vue gibi şeyler olmadan
aynı işlevi uygulasanız bile kodu daha karmaşık yazmak gerekiyor, değil mi?
Özellikle popup yönetirken tek bir props bile saf JavaScript ile geçirilecekse kod çok daha karmaşık hale geliyor.
Böyle basit bir şeyi yaparken bile kod karmaşıklaşıyorsa gerçekten
karmaşık özellikleri uygulamak zorlaşıyor.
 
slowandsnow 2025-07-15

Kaçınılmaz bir karmaşıklık. Eskisi gibi basit şablon HTML değil çünkü.
 
ahwjdekf 2025-07-12

İnsanların kullandığı tarayıcıların sayısı zaten çok fazla değilken framework neden bu kadar çok? Tarayıcıları yöneten şirketlerin en iyi framework’ü yapıp onu da birlikte yönetmesi en iyi çözüm olmaz mı? Bu kısır döngüyü daha ne kadar sürdüreceğiz.
 
spp00 2025-07-12

Benimsedikleri geliştirme felsefeleri birbirinden çok farklı, o yüzden.........
 
lastiverse 2025-07-12

Ortaya konan tespitlere katılıyorum ama sonuca katılmıyorum.

Bu durumun yüzeydeki nedeni, yazıda da belirtildiği gibi, "uygulama gibi web"e olan talebin artmış olması.
Hem şimdi hem de o zaman web, "uygulama gibi bir şey" yapmak için çok uygun değildi; ama epey zorlayınca "benzerini yapmak mümkün" olan bir yapıdaydı diye düşünüyorum.

Aslında web’in doğuş amacı, tezler gibi bir tür "belge"yi paylaşmak için oluşturulmuş bir platform olmasıdır.
Bunu HTML’in temel bileşenlerine bakınca da anlayabilirsiniz.

Sonra CGI gibi dinamik içerik üretebilen teknolojiler ortaya çıktı, tarayıcı tarafına da script dilleri gömülünce ortaya çıkan sonuca dinamizm katmak mümkün oldu ve "belge olarak web" anlayışından uzaklaşma başladı.

Sorun şu ki, bu ilk kopuş anından bugüne kadar web’in temeli hâlâ "belge" tabanlı bir sistem.
Elbette WebSocket, WebRTC, WASM gibi "belge" yöneliminden uzak yeni teknolojiler çokça çıktı; ama bugün hâlâ web sitelerinin büyük çoğunluğu mevcut "belge" tabanlı platforma dayanarak geliştiriliyor.
Hâlâ ekran çizmek için div etiketlerini üst üste koymak zorundayız.

Buraya kadar durum tespiti; peki çözüm ne diye düşününce,
gerçekçilik gibi şeyleri hiç hesaba katmadan ideal bir sonraki platformun işlevlerini hayal edersem şöyle olurdu.

(Bunun tüm siteler için geçerli olması gerektiğini söylemiyorum; yalnızca uygulama niteliği taşıyan siteler için.)
Öncelikle tarayıcı bir tür uygulama başlatıcısı olurdu.
Bir kez indirildikten sonra çevrimdışı da çalışabilmesi gerekirdi.
Ve uygulama, mevcut html/css/js üçlüsünden çıkarak başka dillerle geliştirilirdi.
Bu süreçte Android’de olduğu gibi tarayıcı da bir tür framework sağlayabilirdi.
Sunucuyla iletişim biçimi de mevcut web isteklerinin dışına çıkıp başka bir paradigma kullanabilirdi.
Gerçek zamanlılık gerektiren iletişimde mevcut TCP iletişimi olduğu gibi kullanılabilir,
HTTP protokolünü kullanmayan daha basit bir RPC iletişimi de yeni baştan tasarlanıp kullanılabilirdi.
 
techiemann 2025-07-13

"İdealleştirilmiş bir platform" diyerek bahsettiğiniz son kısmın ne demek olduğunu pek anlayamadım.

Sonuçta bu, yerel bir program indirip onun içinde ActiveX kullandığımız dönemden bahsetmek oluyor.
 
lastiverse 2025-07-13

Meselenin özü, web "belge" temeline dayanan HTTP protokolü içinde uygulama benzeri bir web oluşturmak için verilen zorlu çaba gibi görünüyor,
ve bunu çözmek için uygulama seviyesinde işlevler gerekiyorsa, uygulamalar için yeni bir protokol ve framework oluşturmak nasıl olurdu görüşüydü.
Akıllı telefonda saf native programlar değil, bir tür sandbox içine alınmış uygulamalar çalıştığı gibi, bunun da tarayıcı seviyesinde çalışan bir yapı olmasıdır.
Elbette bunun ActiveX benzeri bir hale gelmemesi için açıklık ve standardizasyonun önce gelmesi gerekir.
 
spp00 2025-07-12

Web uygulama gibi olsa bile, bence sonuç kısmında varılan noktaya yakın bir yönelim izlenmeli. JavaScript çok kullanılırsa istemci tarafında ağırlaşıyor.

Aslında bunu bu şekilde uygulayabilecek framework’ler de var. Hatta Next.js’te bile client component kullanımını yalnızca gerektiğinde olacak şekilde en aza indirirseniz kabaca mümkün; bir başkasının bahsettiği Rails ekosisteminde de, yazarın vardığı sonuca neredeyse yaklaşabilen uygulama benzeri web’i destekleyen bir framework araç takımı olan Hotwire(https://hotwired.dev/) (Turbo, Stimulus vb.) mevcut.
 
kunggom 2025-07-12

Bu yazının temel meselesine katılıyorum, ancak bazı kısımlarda insanın biraz durup düşündüğü noktalar da var.

Örneğin, şirketimiz tarafından işletilen belirli bir hizmeti tanıtan web sitesi, tam da bu yazıda övülen türden bir sadeliği koruyor. Neyse ki bu web sitesinin unsurlarının çoğu yeterince statik. Frontend tarafındaki HTML ve CSS gibi kodlar herhangi bir framework olmadan doğrudan insanlar tarafından elle yazılmış, JS olarak da yalnızca jQuery ve Google Analytics bulunuyor. Duyurular veya ilan panosu gibi bölümler jQuery kullanan AJAX ile gerçekleştirilmiş olsa da, bunun mantıksız ya da aşırı karmaşık bir düzeyde olduğunu düşünmüyorum. Ben web geliştirmeye uzun zaman önce giriş yaptığımda bunun jQuery tabanlı olarak gerçekleştirilebilecek bir seviyede olduğunu düşünürdüm. Bildiğim kadarıyla bu site Internet Explorer döneminden beri işletiliyordu, yani ben doğrudan yapmadım, ama bence hiç de fena değil.

Ama burada Git sürüm yönetimi ve CI/CD pipeline'ı da var; staging sunucusu ile gerçek production sunucusu birbirinden ayrılmış durumda. main branch'ine bir Pull Request merge edildiğinde pipeline, bundler'ın ürettiği çıktıları staging sunucusuna otomatik olarak deploy ediyor; sorumlu kişi staging sunucusunu kontrol edip dağıtımı nihai olarak onayladıktan sonra bu kez production sunucusuna deploy ediliyor. Geçmişte ise sadece FTP üzerinden kaynak dosyaları doğrudan production sunucusunda ezerek güncelleme yapılıyordu; ilgili iş bizim ekibe geçtikten sonra bunu bu şekilde değiştirdik.

Bu gerçekten mantıksız bir karmaşıklık mı? Geçmişte bu web sitesinin başlık etiketini düzeltmek, FTP bağlantısını destekleyen AcroEdit (evet, o sitenin HTML'ini doğrudan yazan kişiler hâlâ bunu kullanıyordu) ile production sunucusundaki HTML dosyasına girip tek satır değiştirerek kaydetmekle biten bir işti; o kişiler muhtemelen bunu böyle hissedebilir.

Ama bana göre bu düzeyde bir karmaşıklık eklemesi gayet katlanılabilir bir şeydi. Sonuçta yapılan her iş yalnızca bir başlık etiketini düzenlemek kadar basit değil. Ayrıca eski kodların yorum satırına alınarak üst üste birikmesi yerine, istendiğinde geri döndürülebileceği için hiç çekinmeden tamamen silinebilmesi; değişikliklerin şeffaf şekilde izlenebilmesi ve rollback yapılabilmesi; bundler sayesinde gerekirse biraz daha temel optimizasyonların eklenebilmesi bence yeterince büyük avantajlar. Gerçek ortama deploy edilmeden önce önizleme yapılabilen bir staging sunucusu eklemek de bir bakıma karmaşıklık sayılabilir, ama ben bunun gerekli olduğunu düşünüyorum.

Ben de çeşitli web sitelerinin iç kod yapısının aşırı karmaşık ve ağır hâle gelmesinden epey rahatsızım. Bugünlerde Windows'taki Outlook uygulaması web app tabanlı, ama son zamanlarda özellikle daha da ağırlaştı. Ekranda sadece e-posta gövdesi yazmak ya da gövdenin tamamını seçmek bile takılmaya neden oluyor, hatta bazen "sayfa yanıt vermiyor" noktasına geliyor. Neden böyle diye merak edip web Outlook'ta geliştirici araçlarını açtığımda gerçekten şaşırdım. Bir kez cache'i temizleyip sayfayı yeniledim, 1 dakika sonra bile hâlâ bir sürü istek akmaya devam ediyordu. Tarayıcıdan baktığımda yalnızca MS Office sitesiyle ilgili birkaç gigabayt veri depolanmış olduğunu gördüm.

Ama bu yazı birçok şeyi birbirine karıştırıyor; bazı kısımlarına katılıyorum ama bazı kısımlarına pek katılamıyorum. Semantik HTML ya da erişilebilirlik konusunda geçmişin aslında daha da korkunç olduğunu biliyorum. Üstelik geliştirici deneyiminin iyileşmesinin kullanıcı deneyimini kötüleştirdiği iddiasına, web frontend geliştiricisi olmadığım için mi bilmiyorum ama hiç katılamıyorum. Hatta bütün güç ve kontrolün geliştiricilerde toplandığını söylemek bana saçma geliyor. Şirketlerde güç yönetimde değil mi? Yoksa Batı'da şirket yapısı Kore'dekinden biraz farklı mı?

Her zaman olduğu gibi denge ve itidal, sadelik ve pratiklik önemli değerlerdir ve karar verirken bunlara öncelik verilmesi gerektiğine tamamen katılıyorum. Ama bu yazı, "tüm web sitelerine birer yazılım ürünü gibi davranılması"nı sanki bütünüyle geliştiricilerin sorumluluğuymuş gibi öne sürüyor; bence bu da asıl meseleye dair farkındalığı bulanıklaştırıyor. Ayrıca sistemli olmayan o 'eski güzel günler'i yüceltiyor gibi görünen kısımlar da bence eleştirilmeli.
 
techiemann 2025-07-13

Bahsettiğiniz konu, anlatılan şeyden tamamen farklı değil mi?
 
kunggom 2025-07-14

Hangi açıdan bunun tamamen farklı bir konu olduğunu düşünüyorsunuz?
Sonuçta bu yazının eleştirdiği şeyin aşırı karmaşıklık ve bunun yol açtığı şişkinlik olduğunu düşünüyorum. Yorumumda JavaScript konusunu açmamış olmamın, bunun tamamen ilgisiz bir yorum olduğu anlamına geldiğini düşünmüyorum. Bir bakıma bu, tali bir noktaya yönelik bir eleştiri sonuçta. Ayrıca yorumumda en başta da belirttiğim gibi, ben de asıl yazının temel mesele bilinciyle hemfikirim.
 
techiemann 2025-07-14

Sanırım asıl yazının niyetini yanlış anlamışsınız.

"...Burada Git sürüm yönetimi ve CI/CD pipeline'ı var; staging sunucusu ile gerçek prod sunucusu birbirinden ayrılmış durumda. main branch'ine bir Pull Request merge edildiğinde, pipeline bundler çıktısını otomatik olarak staging sunucusuna deploy ediyor; sorumlu kişi staging sunucusunu kontrol edip deploy'u nihai olarak onayladığında ise bu kez prod sunucusuna deploy ediliyor. Eskiden dosyaları FTP ile doğrudan prod sunucusundaki asıllarının üzerine yazıyorduk, ancak ilgili iş ekibimize geçtikten sonra bunu bu şekilde değiştirdik.

Bu gerçekten irrasyonel bir karmaşıklık mı?"

demişsiniz ama bence bu yazıyla pek ilgili değil. Deploy ve yönetimi bu şekilde yapmakla, bu yazının savunduğu şey oldukça farklı görünüyor.
 
kunggom 2025-07-14

Asıl yazının amacı yalnızca karmaşıklaşan JS framework’lerini eleştirmek değil.
Kolaylık olması açısından yukarıdaki Korece çeviri bağlantısından alıntı yapacağım.

Artık yalnızca bir başlığı değiştirmek için bile 4 mühendis, 3 framework ve bir CI/CD pipeline’ı gerekiyor. Bir web sayfası yayımlamak tuhaf derecede karmaşık hale geldi.

Böylece web, yavaş yavaş, kullanıcılar ihtiyaç duyduğu için değil, geliştiriciler kendilerini modern hissetmek istediği için yayımlanmadan önce derlenmesi gereken bir şeye dönüştü.

Her şey geliştiriciler için optimize edildi ve diğer herkes için düşmanca hale geldi.

Artık karmaşıklığa yalnızca katlanmıyoruz; onu doğal kabul ediyoruz. Her sitenin bir build aşamasına, bundler’a, hydration stratejisine, routing katmanına, API katmanına, tasarım sistemine ve akıllı cache invalidation mantığına ihtiyaç duyduğunu varsayıyoruz. Mikroservislerle inşa ediyor, edge ağlarında barındırıyor ve basit içerik sunmak için pipeline’lar devreye alıyoruz.

WordPress gibi platformların işlevlerini yeniden yaratıyoruz, ama ortaya 10 kat daha ağır ve kullanılabilirliği çok daha kötü sonuçlar çıkıyor. Daha kötüsü, her yeni katman yeni bug’lar, yeni uyumluluk sorunları ve yeni bilişsel yük getiriyor. Artık yalnızca bir ana sayfayı yayına almak için hydration mantığını, cache stratejilerini ve build pipeline’ını bakımda tutuyoruz.

Bileşen kütüphanesi yeterince esnek olmadığı için pazarlama kampanyaları gecikiyor. Analitik katmanı hydration stratejisiyle uyumlu olmadığı için A/B testleri iptal ediliyor. İçerik güncellemeleri için günlerce build bekleniyor. Temel SEO düzenlemeleri backlog’da kaybolup gidiyor.

Pazarlamacılar ticket açmadan metni güncelleyemiyor ya da deney yürütemiyor. İçeriği önizleyemiyor, yerleşimi test edemiyor veya sayfa dışa aktaramıyorlar. Her değişiklik geliştiricilerden, pipeline’lardan, onaylardan ve yeniden build sürecinden geçmek zorunda.

Pazarlamacılar, içerik editörleri, SEO uzmanları ve tasarımcılar; hepsi süreçten dışlanıyor. Çünkü artık basit işler bile teknik akıcılık gerektiriyor. Başlık etiketini değiştirmek istiyorsanız size bir mühendisle görüşmeniz söyleniyor; bir kampanyayı yayına almak istiyorsanız ticket açıp iki sprint beklemeniz isteniyor.

Her şey geliştirme ekibinin içinden geçiyor. Bu da neyin önemli olduğuna, neyin yayımlandığına ve neyin süresiz olarak geri plana itildiğine geliştirme ekibinin karar verdiği anlamına geliyor. Ve onlar ne kadar fazla karmaşıklık eklerse, o kadar vazgeçilmez hale geliyorlar.
 
spp00 2025-07-12

Kore'nin yönetimden -> planlamacıya -> geliştiriciye doğru inen geliştirme kültürünün aksine, Batı'da Kore'deki anlamıyla bir planlamacı kavramı yoktur ve geliştiricilerin ürün planlaması gibi alanlara aktif olarak katıldığı durumlar vardır. Batı'daki PM gibi roller de, cover letter ile özgeçmişin tamamen aynı kavramlar olmaması gibi, Kore'deki planlamacıyla birebir örtüşmez. Elbette yaratıcı proje niteliğinin güçlü olduğu, eğlence ve oynanışın önemli olduğu oyunlarda Batı da Asya'ya kıyasla daha yatay olsa da, yine de direktörden geliştiriciye doğru inen bir yapı vardır.
 
kunggom 2025-07-14

Demek böyle bir fark varmış.
Ancak bunun yukarıdaki içerikle çok ilgili bir nokta olduğunu sanmıyorum.
 
eajrezz 2025-07-11

Rails kullanın, mutlu olun
 
spp00 2025-07-11

Bu yazının ana fikrine katılıyorum. Son zamanlarda JS o kadar fazla ve ölçüsüz kullanılıyor ki i9-9900k kullansanız bile sitenin takıldığı durumlar çok oluyor. Oyun ya da iş üretimi için biraz arada kalan bir donanım olsa da, gerçekte bundan daha düşük özellikli ofis bilgisayarları fazlasıyla yaygın.

Bu yüzden ben, yalnızca etkileşimli kısımlarda ya da etkileşimli sayfa gezinimi gibi JS’nin gerçekten gerekli olduğu durumlarda kullanılmasını savunan bir felsefeye sahip framework’ler olan Astro ve hotwired’ı seviyorum. Sunucu tarafında render etmeyi savunan server-side rendering yaklaşımını da seviyorum. Buna karşılık CSR’den (yalnızca meta etiketlerini sunucu tarafında render edip geri kalan kısmı CSR ile işleyen yaklaşımlar dahil) ciddi anlamda nefret ediyorum. Çünkü bunu, sunucunun yapması gereken işi istemciye yıkmak olarak görüyorum. Bana göre CSR kullanan geleneksel SPA yaklaşımı, Electron benzeri uygulamalarda frontend yerel olarak çalıştırıldığında kullanılmalı. Elbette frontend sunucudan yüklenecekse SSR kullanılmalı.
 
baeba 2025-07-11

Aşağıda, gönderiye verilen yorum tepkilerinin 5 türde sınıflandırılmış özeti yer alıyor:

1. Tam katılım ve destek

  • Başlıca özellikler: Yazının savlarına güçlü biçimde katılıyor ve karmaşık JS yığınının sorunlarını kabul ediyor.

  • Görüş örnekleri:

    • “Sonunda biri söylenmesi gerekeni söyledi.”
    • “Gerçeklerle yüzleşen harika bir yazı.”
    • “Web performansı ve erişilebilirlik vazgeçilmezdir.”

2. Framework aşırı kullanımına yönelik kaygı

  • Başlıca özellikler: React, Angular gibi framework’lerin aşırı kullanımını eleştiriyor, daha basit teknolojilerin yeterli olduğunu savunuyor.

  • Görüş örnekleri:

    • “Bir blog için React gerekli değil.”
    • “Vanilla JS çoğu şeyi çözer.”
    • “Svelte, Eleventy gibi hafif alternatifler daha iyi.”

3. Kısmi katılım + gerçekleri gözetme

  • Başlıca özellikler: Savlara empati duyuyor, ancak karmaşıklığın kaçınılmaz ya da gerekli olabileceğini düşünen daha gerçekçi bir bakış da var.

  • Görüş örnekleri:

    • “Karmaşıklık sorun ama bazı durumlarda kaçınılmaz.”
    • “İş birliği ve bakım için framework’ler de gerekli olabilir.”
    • “HTML/CSS de kusursuz değil, bu yüzden JS kullanmak zorunda kalıyoruz.”

4. Geliştirme kültürü ve sektör yapısına eleştiri

  • Başlıca özellikler: Framework fazlalığının yalnızca teknik bir sorun olmadığını; işe alım, kültür ve pazarlama yapısının bir ürünü olduğunu belirtiyor.

  • Görüş örnekleri:

    • “Framework’ler özgeçmişe yazılan teknolojilere dönüştü.”
    • “Geliştiriciler sadece şirketin taleplerine uyuyor.”
    • “Bu, organizasyon kültürü ve iş gücü piyasasının sorunu.”

5. Eleştiri veya karşı çıkış

  • Başlıca özellikler: Yazının öncüllerine katılmıyor ya da bunu tek taraflı bir iddia olarak eleştiriyor.

  • Görüş örnekleri:

    • “Web’in yavaşladığına dair bir kanıt yok.”
    • “Yazı aşırı derecede taraflı.”
    • “JS sorununu WordPress ile çözmek aslında bir geri adım.”
 
dlehals2 2025-07-11

Vay, türlere göre ayırınca bakması daha kolay ve güzel olmuş.
 
slidingv 2025-07-14

Yazının işaret ettiği "webin aşırı karmaşıklığı" sorununa katılıyorum. Ancak bunun nedenini yalnızca geliştirici kültürüne ya da framework’lerin kötüye kullanımına bağlayan teşhise katılmak zor. Günümüz webinin karmaşıklığı, büyük ölçüde "iş modelinin" zorunlu kıldığı işlevlerin ve güvenliğin gölgesinden kaynaklanıyor. Bu noktayı dışarıda bırakırsak, değerlendirme kaçınılmaz olarak eksik kalır.

Web artık bir "ücretsiz sergi salonu" değil. Bugün kamu siteleri dışındaki çoğu web hizmetinin amacı gelir elde etmektir. Bu yüzden teknoloji seçimindeki temel soru "Bu kod ne kadar saf?" değil, "Bu teknoloji işimizi başarıya ulaştırıyor mu?" olmalıdır.

Bu açıdan bakıldığında, yazının idealize ettiği "hafif içerik webi" gerçek dünyanın iş gereksinimleri duvarına çarpar. Örneğin içerik satan bir iş modeli, yalnızca basit statik sayfalarla yürütülemez. Ücretli abonelik ve ödemeleri işlemek için kullanıcı kimlik doğrulaması, abonelik durumunun kontrolü ve yetki yönetimi gibi durum tabanlı mantık gerekir; içeriği korumak için de korsan kopyalama veya yetkisiz erişimi engelleyen gerçek zamanlı token doğrulaması gibi güvenlik katmanları zorunludur. Dahası, kişiselleştirme ve A/B testleriyle kullanıcı deneyimini ve dönüşüm oranını artırmak istiyorsanız dinamik veri işleme de gerekir.

Bunların tamamı "gelişmiş uygulama" alanına girer ve framework’ler bunu hayata geçirmek için kullanılan gerçekçi araçlardır.

Elbette her karmaşıklık meşrulaştırılamaz. Karmaşıklığı ikiye ayırmalıyız.

  • Kaçınılmaz karmaşıklık: İşlevsel gereksinimleri (kimlik doğrulama, ödeme, kişiselleştirme vb.) yerine getirmek için ortaya çıkan, ROI’si net olan karmaşıklıktır. Katlanılması gereken bir maliyettir.

  • Tesadüfi karmaşıklık: Geliştirme kolaylığı ya da aşırı teknik soyutlama nedeniyle ortaya çıkan gereksiz karmaşıklıktır. Sürekli ölçülmesi ve ortadan kaldırılması gereken teknik borç ve israftır.

Başarılı hizmetler, bu ikisini ayırt ederek gerçekçi bir mimari kurar. Yani pazarlama ve SEO’nun kritik olduğu ön yüzü mümkün olduğunca hafif tutarken, temel işlem veya kişiselleştirme işlevlerinin gerekli olduğu iç alanlarda framework tabanlı yapılarla istikrar sağlar; böylece hız ve işlevselliği birlikte yakalayan hibrit bir strateji izler.

Yazı, kullanıcı deneyiminin kötüleşme nedenini yalnızca framework kültürüne odaklayıp "gelir modelinin doğurduğu kaçınılmaz gereksinimleri" dışarıda bırakmış. Bu noktayı hariç tutarak web geliştirmeyi tartışmak, müşterinin masasına "hızlı ve lezzetli yemek" koymaktan söz ederken o yemeğin hazırlandığı karmaşık mutfağı ve paranın tahsil edildiği kasayı yok saymaktan farksızdır.

Web ağırlaştı diye framework’leri düşünmeden bir kenara atamayız. Asıl tartışılması gereken, işletmenin ihtiyaç duyduğu işlevleri ne kadar verimli ve en düşük maliyetle hayata geçirip kullanıcıya değer sunduğumuz olmalıdır diye düşünüyorum.