Web geliştirme dünyası, on yılın büyük bir kısmını tarayıcının ağır iş yükünü üstlenmesi gerektiğine kendini ikna ederek geçirdi

Web geliştirme dünyası, on yılın büyük bir kısmını tarayıcının ağır işleri yapması gerektiğine kendini ikna ederek geçirdi. Belge ve formlarla başladık, ardından akla gelebilecek her türlü işlemi kademeli olarak istemciye (client) taşıdık. Yönlendirme (routing), durum yönetimi (state management), veri çekme (data fetching), işleme mantığı (rendering logic), hatta GraphQL aracılığıyla veritabanı sorgu orkestrasyonu — bunların hepsi, her sürümle birlikte daha da ağırlaşan JavaScript paketlerine (bundles) taşındı. Framework'ler çoğaldı, derleme süreçleri (build pipelines) derinleşti ve uygulamaların hızlı hissettirmesini sağlayan bir yöntem olarak başlayan süreç, megabaytlarca kod indirilip ayrıştırılana ve yürütülene kadar bir sayfanın tek bir anlamlı piksel bile işleyemediği bir mimariye dönüştü.

Bu değişim gerçek sorunları çözdü. Biraz jQuery içeren sunucu taraflı işlenen (server-rendered) sayfalar, kullanıcıların beklediği o pürüzsüz, uygulama benzeri geçişleri sağlamakta zorlanıyordu. Tek Sayfalı Uygulamalar (Single Page Applications) bize anlık navigasyon, kalıcı durum ve zengin etkileşimler sundu. Ancak maliyet birikti. Ekipler artık karmaşık istemci tarafı durum depolarını (state stores) yönetiyor, devasa JavaScript paketleriyle boğuşuyor, hassas veri senkronizasyon katmanlarını sürdürüyor ve bazen kendi başlarına tam zamanlı bir işmiş gibi hissettiren derleme süreçlerini hata ayıklıyor. Bir sorun kümesini diğeriyle takas ettik ve birçok geliştirici artık her uygulamanın bu vergiyi ödemesi gerekip gerekmediğini sorguluyor.

İki gelişme, bu soruyu yanıtlamayı kolaylaştırıyor.

HTMX ve Hypermedia'nın Dönüşü

Birincisi HTMX. Görünüşte küçük bir kütüphane gibi duruyor ancak mimari etkisi oldukça büyük. HTMX, HTML'i JavaScript tarafından şişirilmesi gereken statik bir kabuk olarak görmek yerine, uygulama mantığı için yerel format olarak ele alıyor.

Uygulamada neler değiştiğine bakalım. Geleneksel olarak, bir kullanıcı daha fazla yorum yüklemek için bir düğmeye tıkladığında, frontend bir fetch isteği gönderir, bir JSON yükü (payload) alır, bunu istemci tarafı bir depoya normalize eder, bir bileşen şablonundan geçirir, sanal DOM'u (virtual DOM) karşılaştırır (diff) ve sonunda sayfayı yamalar (patch). HTMX bu zinciri kısaltıyor. Düğmenin kendisi, tarayıcıya isteği nereye göndereceğini ve hangi sayfa öğesini değiştireceğini söyleyen öznitelikler (attributes) içerir. Sunucu bir HTML parçacığı (fragment) döndürür — sadece bir div içine alınmış yeni yorumlar. Tarayıcı bunu sayfaya yerleştirir. JSON yok, frontend durum ağacı yok, uzlaştırma (reconciliation) algoritması yok ve kullanıcı arayüzünü (UI) sunucuyla senkronize tutmak için emirsel (imperative) JavaScript yok.

Bu, modern geliştirmeyi reddetmek değil; gereksiz soyutlamayı reddetmektir. HTMX, erken web dönemine güç veren mimari stil olan hypermedia'nın, modern ergonomi ile birleştirildiğinde hala gelişmiş arayüzleri destekleyebileceğini kanıtlıyor. Sadece formlar ve bağlantılar değil, herhangi bir öğe istek gönderebilir. Herhangi bir olay bir güncellemeyi tetikleyebilir. Sunucu, hem veri hem de sunum için tek gerçeklik kaynağı (source of truth) olmaya devam eder.

Chrome'un Deklaratif Kısmi Güncellemeleri

İkinci değişim daha yeni ve doğrudan tarayıcının içinde gerçekleşiyor. Chrome, Declarative Partial Updates (DPU) özelliğini tanıtıyor. Bu özellik, tarayıcının HTML'i akış (stream) halinde almasına ve baytlar geldikçe doğrudan sayfanın hedeflenen kısımlarına yerleştirmesine olanak tanıyor.

DPU'dan önce, bir web sayfasına canlı veri akışı sağlamak istiyorsanız, genellikle WebSockets, Server-Sent Events veya manuel DOM manipülasyonu ile eşleştirilmiş long-polling yöntemlerine başvururdunuz. Frontend bağlantıyı yönetmek, yükü ayrıştırmak ve işaretlemeyi (markup) tam olarak nasıl ve nereye enjekte edeceğine karar vermek zorundaydı. DPU, süreci deklaratif hale getirerek denklemi değiştiriyor. Geliştirici bir hedef kapsayıcı (container) belirtir ve tarayıcı geri kalanını halleder: akışı almak, parçacığı ayrıştırmak ve tam yanıt kapanmadan bile onu tam olarak olması gereken yere yerleştirmek.

Sunucu günlüklerini gösteren bir izleme paneli veya gerçek zamanlı güncellenen bir destek kuyruğunu düşünün. DPU ile backend, HTML parçalarını oluşturuldukları anda gönderir. Tarayıcı, tek bir satır istemci tarafı akış mantığına ihtiyaç duymadan bunları bir tablo gövdesine (table body) veya bir akış kapsayıcısına (feed container) aktarır. Birleştirme işlemi yerel (native) olarak gerçekleşir.

Sunucu Öncelikli Model (Server-First Model)

HTMX ve DPU'yu bir araya getirdiğinizde; sunucunun durumu (state) yönettiği ve kullanıcı arayüzünü (UI) oluşturduğu, tarayıcının ise görüntülemeyi ve kullanıcı girişini yönettiği tutarlı bir mimari elde edersiniz. Rails, Laravel, Django, Go templates veya ASP.NET gibi backend framework'leri yeniden birincil arayüz katmanı haline gelir. Frontend, bir API tüketen ayrı bir uygulama değildir; sunucunun ürettiği hypermedia arayüzüdür.

This model fits a surprisingly wide slice of software. Consider the typical SaaS application. It is dashboards with sortable tables. It is admin panels with forms and filters. It is internal tools that move records from one state to another. It is CRUD workflows that show a list, expose a detail view, and let the user edit fields. It is even AI interfaces where a language model streams tokens back to the user, and each token or paragraph can be wrapped in HTML and appended to the conversation thread. For all of these, a thick JavaScript client is often overkill.

The benefits are immediate and practical. Initial page loads are faster because the first meaningful paint arrives as HTML, not after a hydration cycle completes. JavaScript payloads shrink because there is no virtual DOM, no client-side router, and no state management library to ship. Search engines see complete content without executing bundles, so SEO works by default. Complexity drops because one codebase handles routing, business logic, and rendering. Debugging gets easier. When something looks wrong, you inspect the Network tab and see exactly what HTML the server sent. There is no opaque client-side state object to reverse-engineer.

What About React and Heavy Clients?

None of this means React is dead, or that SPAs are a mistake. Complex, editor-grade applications still need a thick client. Figma runs a C++ engine compiled to WebAssembly inside the browser because server round-trips would make drawing impossible. Canva manipulates the canvas at sixty frames per second with client-side geometry. Google Docs uses operational transforms to resolve editing conflicts in milliseconds. These tools are essentially desktop applications delivered through a browser tab. They are not going back to server-rendered forms.

But most software is not Figma. Most software is not a real-time graphics editor. Most software is a reporting screen, a configuration panel, a booking flow, or a content management form. For that long tail of applications, shipping hundreds of kilobytes of JavaScript framework just to toggle a modal or fetch a list of records never made much sense. The economics of the stack are shifting. We are rediscovering that the server can be close to the user thanks to the edge, and that the browser itself has grown capable enough to update fragments without a framework intermediating every byte.

The Pendulum Finds a Balance

The arc of web architecture is swinging back toward simplicity, but it is not a naive return to the nineties. The browser is becoming smarter. Features like DPU do not replace developer ingenuity; they absorb the patterns we used to implement by hand — streaming, partial updates, targeted DOM insertion — into the platform itself. HTMX gives us the vocabulary to express those behaviors without reconstructing a miniature operating system in the frontend.

You no longer have to choose between a simple architecture and a responsive user experience. You can have both. The server can drive the interface, the browser can assemble it, and the JavaScript you write can focus on genuine interactivity rather than plumbing.

For the next generation of dashboards, admin tools, and AI-powered interfaces, the smartest client might be the one that does less.