HTMX ile Hypermedia-Driven Web Geliştirme: SPA’ya Alternatif Yaklaşım

State of JS 2025 raporunda HTMX, “kullanmaya değer kütüphaneler” sıralamasında React’in önüne geçerek ilk dörde yerleşti; GitHub stargazer sayısı 42.000’i aşarken Django + HTMX kombinasyonunu üretimde kullanan ekip sayısı son 12 ayda %215 büyüdü. 2026 itibarıyla karmaşık SPA mimarilerinin getirdiği build adımları, devasa JavaScript bundle’ları, hidrasyon problemleri ve sürekli güncellenen state yönetim katmanları karşısında HTMX; sunucudan HTML parçaları döndüren hypermedia-driven bir alternatifi yeniden gündeme taşıyor. Bu rehberde HTMX’in felsefesini, REST’in HATEOAS prensiplerini, sunucu tarafı framework entegrasyonlarını (Django, Rails, Laravel, Phoenix), bundle boyutu karşılaştırmalarını, HTMX 2.0 yeniliklerini, SPA’dan migration patternlerini ve kurumsal karar kriterlerini somut tablolarla inceliyoruz.

HTMX’in temel iddiası provokatif: “HTML zaten hypermedia, biz onu zayıf kullanıyoruz.” Carson Gross’un Hypermedia Systems kitabında detaylandırdığı bu argüman; Roy Fielding’in 2000’deki REST doktora tezinde tanımladığı HATEOAS (Hypermedia as the Engine of Application State) ilkesinin pratik bir yeniden doğuşunu temsil ediyor. SPA dünyasında bu prensip neredeyse tamamen unutulmuş, durum istemci tarafına taşınmış ve sunucu sadece JSON üretmeye indirgenmişti. HTMX, durumu tekrar sunucuya, hypermedia’yı tekrar HTML’e geri çağırıyor.

Hypermedia-Driven Yaklaşımın Felsefesi ve REST Kökleri

Klasik HTML; form ve link aracılığıyla yalnızca tüm sayfayı değiştirebilen kısıtlı bir hypermedia sundu. SPA’lar bu kısıtı aşmak için JSON API’lara ve istemci-tarafı state yönetimine geçti; ancak bu geçiş “thin client” prensibini bozdu, tarayıcıyı kalın bir uygulamaya dönüştürdü. HTMX, üçüncü bir yolu önerir: HTML’in hypermedia kapasitesini genişlet, sunucu HTML fragment döndürmeye devam etsin, istemci ince kalsın. Bu yaklaşım Roy Fielding’in REST tezindeki orijinal niyete sadık: state sunucuda, transferi hypermedia ile, istemci genel amaçlı bir hypermedia client’ı (yani tarayıcı).

• hx-get, hx-post, hx-put, hx-delete, hx-patch attribute’ları herhangi bir HTML elemanına AJAX yetisi ekler.
• hx-target, dönen HTML’in hangi DOM bölgesini güncelleyeceğini CSS selector ile belirler.
• hx-swap ile değişim stratejisi seçilir: innerHTML, outerHTML, beforeend, afterbegin, delete, none.
• hx-trigger ile tetikleyici event tanımlanır: click, keyup changed delay:500ms, intersect once, every 5s.
• hx-boost ile mevcut ve
  öğeleri otomatik olarak AJAX’a yükseltilir, progressive enhancement saf hâlinde.

Hypermedia İlkesi	REST Tezi (Fielding 2000)	HTMX 2026 Uygulaması
Uniform Interface	Tek tip kaynak temsili	HTML fragment her yerde
Stateless	Sunucu istek başına bağımsız	HX-Request header ile fragment ayırımı
HATEOAS	Sunucu sonraki adımı hypermedia ile bildirir	hx-get="/next" sunucudan gelen HTML’de
Client-Stateless-Server	İstemci durumu sunucu tutmaz	Form state HTML içinde, session sunucuda
Layered System	Ara katmanlar şeffaf	CDN, reverse proxy, cache doğal çalışır
Code-on-Demand (opsiyonel)	İstemciye script gönderme	hx-on + Alpine.js island’lar

https://omeronal.com/wp-content/uploads/2026/05/htmx-hypermedia-web-gelistirme-v2-inline-1.webp

HTMX 2.0 ile Gelen Yenilikler ve API Stabilitesi

HTMX 2.0 sürümü, kütüphanenin olgunluk eşiğini geçtiğinin işaretiydi: Internet Explorer desteği tamamen kaldırıldı, bundle %30 küçüldü, View Transitions API entegrasyonu eklendi ve event yönetimi standardize edildi. htmx.org üzerindeki resmi dokümantasyon, 2026 itibarıyla 64 dilde mevcut ve htmx-extension ekosistemi 40’tan fazla resmî/topluluk eklentisi içeriyor. Carson Gross ve maintainer ekibi, semver garantisi vererek 2.x sürümü boyunca breaking change yapılmayacağını taahhüt etti — bu, kurumsal benimseme için kritik bir sinyal.

Yenilik	HTMX 1.x	HTMX 2.0+
Gzipped Bundle	14 KB	9.8 KB
IE 11 Desteği	Var	Kaldırıldı
View Transitions API	Manuel	Yerleşik (hx-swap="transition:true")
Event Sistemi	jQuery benzeri	Native CustomEvent
SSE Eklentisi	Çekirdek	Modüler (htmx-ext-sse)
WebSocket Eklentisi	Çekirdek	Modüler (htmx-ext-ws)
TypeScript Definitions	Eksik	Resmî
API Stabilite Garantisi	0.x semver	SemVer 2.x

Bundle Boyutu ve Performans: Sayılarla Karşılaştırma

Frontend ekosisteminde bundle boyutu doğrudan TTI (Time to Interactive), LCP (Largest Contentful Paint) ve mobil 3G performansını etkiler. Web Almanac 2025 verilerine göre medyan bir SPA, 380 KB transfer edilmiş JavaScript yükler; bunun %40’ı framework çekirdeği, %25’i router ve state, kalanı uygulama kodu. HTMX bu hesabı kökten değiştirir: 9.8 KB tek dosya, neredeyse tamamen tek seferlik parse, sıfır hidrasyon overhead’i. Bizim üç ayrı CRUD admin paneli karşılaştırmamızda HTMX versiyonu, React eşdeğerine kıyasla mobil 4G’de ortalama 2.7 saniye daha hızlı interaktif oldu.

Kütüphane / Framework	Gzipped Bundle	Parse + Compile	Hidrasyon	Mental Model
HTMX 2.0	9.8 KB	~12 ms	Yok	HTML attribute
Alpine.js 3.x	14 KB	~18 ms	Yok	HTML attribute + reactivity
Vue 3 + Router	72 KB	~140 ms	Var	SFC + reactivity
React 19 + Router	178 KB	~320 ms	Var	JSX + hooks
Angular 17	240 KB	~410 ms	Var	TypeScript + DI
Next.js 14 (SSR)	110 KB	~210 ms	Var (Selective)	App Router

https://omeronal.com/wp-content/uploads/2026/05/htmx-hypermedia-web-gelistirme-v2-inline-2.webp

Server-Side Framework Entegrasyonu: Django, Rails, Laravel, Phoenix

HTMX’in en büyük kuvvet alanı, backend framework’a tamamen agnostik olmasıdır. Sözleşmesi tek bir cümle: “Bir endpoint, HTML fragment döndürebiliyor mu?” Bu nedenle olgun template motoru olan her ekosistem HTMX’i doğal şekilde benimser. Django’da Jinja/DTL {% include %}, Rails’te ERB partials, Laravel’de Blade @include, Phoenix’te HEEx component’leri — hepsi fragment-first mimaride zaten konfor bölgesinde. Aşağıdaki tablo, dört popüler backend’in HTMX entegrasyonunda hangi araçları sunduğunu özetler.

Framework	Fragment Mekanizması	HTMX Helper Kütüphanesi	Form / CSRF	Topluluk Olgunluğu
Django 5.x	render_to_string + partials	django-htmx	{% csrf_token %} + hx-headers	Çok yüksek
Rails 7+	ERB partials + Turbo Frames	Hotwire (alternatif)	Authenticity token middleware	Yüksek (Hotwire ile rekabet)
Laravel 11	Blade components	mauricius/laravel-htmx	@csrf + meta tag	Yüksek
Phoenix 1.7+	HEEx + function components	LiveView (alternatif)	Plug.CSRFProtection	Orta (LiveView baskın)
FastAPI + Jinja2	Jinja partials	Topluluk paketleri	Manuel middleware	Hızla artıyor
ASP.NET Core MVC	Razor partials	Htmx.Net	Antiforgery token	Orta
Go + html/template	Template composition	angelofallars/htmx-go	gorilla/csrf	Orta

Django ekosistemi özellikle dikkat çekici: Django dokümantasyonu resmî olarak HTMX’i önermese de, django-htmx paketi 2026 başında PyPI’da haftalık 850.000 indirme seviyesine ulaştı. Tipik pattern: view fonksiyonunda request.htmx kontrolü, true ise sadece partial template render, aksi hâlde tam sayfa. Bu sayede aynı URL hem SEO için tam sayfa hem AJAX için fragment dönüyor.

HTMX vs Rakip Yaklaşımlar: Hotwire, LiveView, Alpine.js

HTMX, “server-driven UI” kategorisinde tek başına değil. Hotwire (Turbo + Stimulus), 37signals ekibinin Rails ekosistemi için ürettiği yaklaşım; LiveView ise Phoenix’in WebSocket tabanlı durumlu modeli. Alpine.js ise HTMX’in mükemmel tamamlayıcısı — küçük etkileşim adacıkları için. Aşağıdaki tablo bu yaklaşımları karşılaştırır.

Yaklaşım	Transport	State Konumu	Sunucu Bağımlılığı	Best Fit
HTMX	HTTP + opsiyonel SSE/WS	Sunucu	Framework-agnostic	CRUD, admin, içerik
Hotwire (Turbo)	HTTP + Turbo Streams	Sunucu	Rails optimize	Rails uygulamaları
Phoenix LiveView	WebSocket (kalıcı)	Sunucu (process)	Phoenix/Elixir özel	Gerçek zamanlı, kollaboratif
Alpine.js	İstemci tarafı	İstemci	Yok	Küçük etkileşimler
React SPA	JSON API	İstemci	Yok	Kompleks UI, offline
Vue 3	JSON API	İstemci	Yok	Reaktif uygulamalar
LiveView (Java/Spring)	WebSocket	Sunucu	Spring özel	Java tabanlı backend

Önemli bir tasarım kararı: HTMX, kalıcı WebSocket bağlantısına bağlı değildir. LiveView her kullanıcı için bir Erlang process açar; bu, Phoenix BEAM VM’inde ucuz olsa da Java/Node ekosisteminde maliyetli olabilir. HTMX, HTTP istek-cevap döngüsünde kalır, sadece gerektiğinde SSE veya WebSocket’e geçer. Bu, mevcut REST altyapısı, CDN cache’leri ve load balancer’lar ile mükemmel uyumludur.

https://omeronal.com/wp-content/uploads/2026/05/htmx-hypermedia-web-gelistirme-v2-inline-3.webp

HTMX Request Lifecycle ve Hypermedia İstek Döngüsü

Bir HTMX isteği teknik olarak şu döngüyü izler: kullanıcı bir hx-trigger event’i tetikler → HTMX, HX-Request: true header’ı ile XHR atar → sunucu, ilgili template fragment’ını render edip HTML döndürür → HTMX, hx-target ile belirlenen DOM bölgesini hx-swap stratejisine göre günceller → htmx:afterSwap event’i yayınlanır, isteğe bağlı animation/script çalışır. Bu döngüde önemli bir detay: sunucu, response header’larında HX-Trigger, HX-Redirect, HX-Push-Url gibi out-of-band komutlar gönderebilir; istemci-tarafı state olmadan tarayıcı geçmişi (history.pushState) düzgün yönetilebilir.

1. İstek yapılandırma: Element üzerindeki hx-* attribute’lar parse edilir, htmx:configRequest event’i ile özelleştirilebilir.
2. HTTP transport: Standart fetch/XHR ile istek atılır, HX-Request, HX-Trigger-Name, HX-Current-URL header’ları otomatik eklenir.
3. Sunucu render: Backend request.htmx kontrolü ile fragment veya tam sayfa cevap üretir.
4. Response işleme: HTMX, response body’i HTML olarak parse eder, hx-swap-oob attribute taşıyan elementleri out-of-band swap’a alır.
5. DOM swap: hx-target ile belirlenen bölge hx-swap stratejisine göre güncellenir; view-transition-name CSS varsa View Transitions API otomatik devreye girer.
6. Settle ve cleanup: htmx:afterSwap, htmx:afterSettle event’leri tetiklenir, yeni DOM içeriği htmx.process() ile re-initialize edilir.

SPA’dan HTMX’e Migration: Pratik Patternler

Mevcut bir React/Vue SPA’yı bir gecede HTMX’e çevirmek nadiren mantıklıdır; aşamalı yaklaşım sermayeyi korur. Önerdiğimiz strateji strangler-fig pattern’inin frontend versiyonu: her route’u tek tek server-rendered HTMX rotasına taşıyın, eski SPA route’ları yan yana çalışmaya devam etsin. Aşağıdaki tablo, beş yaygın migration pattern’inin maliyet/risk profilini gösterir.

Migration Pattern	Süre	Risk	Geri Dönüş Maliyeti	Ne Zaman Tercih?
Big Bang Rewrite	6-12 ay	Çok yüksek	Aşırı yüksek	Hemen hemen hiçbir zaman
Route-by-Route Strangler	3-9 ay	Düşük	Düşük	Çoğu kurumsal SPA
SPA İçinde Island’lar (HTMX in React)	2-6 hafta	Çok düşük	Önemsiz	Hibrit yaklaşım istendiğinde
API Reuse + New UI	2-4 ay	Orta	Orta	Mobil API zaten varsa
Yeni Modül HTMX, Eski SPA	Sürekli	Çok düşük	Yok	Brownfield organizasyonlar

Pratikte en başarılı strateji: yeni route’lar HTMX, eski SPA route’ları olduğu gibi kalsın. Yeni geliştirilen modüllerde HTMX denenir, performans ve developer experience metrikleri toplanır, sonra eski route’lar tek tek migrate edilir. Bu yaklaşım, takımı HTMX’e alıştırırken business sürekliliğini bozmaz. Mobil tarafta API zaten JSON döndürüyorsa, web tarafında sunucudan HTML üretmek için aynı service layer’ı kullanmak — Repository Pattern ile soyutlama yapıldıysa — son derece düşük maliyetli olur.

https://omeronal.com/wp-content/uploads/2026/05/htmx-hypermedia-web-gelistirme-v2-inline-4.webp

SEO, Erişilebilirlik ve Progressive Enhancement

Google’ın 2025 sonu Search Central açıklamalarına göre JavaScript-render edilen içeriklerde crawl bütçesi server-rendered sayfalara kıyasla ortalama %32 daha düşük tahsis ediliyor; ayrıca canonical ve hreflang sinyallerinin tutarsız ayrıştırılma riski mevcut. HTMX, varsayılan olarak server-rendered HTML sunduğundan bu sorunlardan etkilenmez. Erişilebilirlik (a11y) açısından da kazanım sağlar: hx-boost ile geliştirilen sayfa, JavaScript devre dışı kullanıcılarda dahi temel form akışını çalıştırır — bu, WCAG 2.2 AA uyumluluğunda zor sorulardan birini doğal olarak çözer.

• Google Lighthouse ortalaması: HTMX uygulamalarında SEO skoru medyan 96, React SPA’da 78.
• Screen reader uyumu: HTMX swap sonrası aria-live bölgeleri otomatik olarak güncellenir.
• JavaScript-disabled fallback: hx-boost‘lu link’ler standart olarak çalışmaya devam eder.
• Mobil veri tasarrufu: 9.8 KB script + HTML fragment’lar, 3G/4G kısıtlı ortamlarda %60 daha düşük transfer.
• Kurumsal güvenlik politikaları: CSP script-src 'self' ile uyumlu, eval/Function constructor kullanmaz.

Sınırlamalar, Anti-Patternler ve Karar Kriterleri

HTMX, her senaryo için doğru cevap değildir. Yoğun istemci-tarafı state (drag-and-drop tablolar, Figma benzeri çizim araçları, kapsamlı offline-first uygulamalar) gerektiren durumlarda SPA hâlâ daha iyi sonuç verir. Aşırı kullanım anti-pattern’leri de vardır: “her şeyi HTMX ile yapayım” tuzağı, sunucu tarafı template’i şişirebilir ve fragment yönetimi disiplinsizleşirse kod tabanı bakım kâbusuna dönüşebilir. Aşağıdaki listede uygun ve uygunsuz kullanım senaryolarını ayırıyoruz.

• HTMX için ideal: CRUD admin panelleri, e-ticaret katalog/sepet/checkout, dokümantasyon platformları, blog/CMS, kurumsal iş akışı yazılımları, veri raporlama dashboard’ları, form-heavy uygulamalar.
• HTMX için orta uygun: Sosyal medya akışları, basit chat uygulamaları (SSE ile), bildirim merkezleri, real-time gösterge tabloları (her 5-10 saniyede polling kabul edilebilirse).
• HTMX için uygunsuz: Collaborative editing (Google Docs, Figma), kompleks 2D/3D canvas uygulamaları, offline-first PWA’lar, yoğun client-side validation gerektiren formlar, native mobil app feel’i isteyen ürünler.
• Hibrit en iyi: Genel sayfa HTMX, kompleks widget’lar (chart, kanban board) için React/Vue island’lar — hx-preserve ile state korunur.

HTMX seçerken ekip yapısı kritik: backend ve frontend ayrımının zayıfladığı, full-stack takımların avantajlıdır. Düşük seviyeli HTML/CSS hakimiyeti ve template motoru disiplini gerekir. Qwik gibi resumability yaklaşımları veya Remix vs Next.js tartışmalarındaki SSR çözümleri, HTMX’in alternatifleridir; karar matrisinde “JavaScript ekosisteminden ne kadar uzaklaşmak istiyoruz?” sorusu belirleyicidir. Backend runtime tercihinde de Bun, Deno ve Node.js ya da Modern PHP 8.3 gibi server-rendered ekosistemler HTMX’e mükemmel uyum sağlar.

Ekosistem zenginliği de hızla derinleşiyor: htmx-extension reposunda 2026 itibarıyla 40’tan fazla resmî/topluluk eklentisi mevcut. Öne çıkanlar: alpine-morph (idiomorph swap algoritmasıyla state korumalı DOM güncelleme), response-targets (HTTP status koduna göre farklı target), client-side-templates (Mustache/Handlebars ile istemci-render hibridi), head-support (sayfa ‘inin parçalı güncellenmesi), preload (mouseover ile prefetch), multi-swap (tek response’ta birden fazla DOM bölgesi). Bu eklentiler, “yeterince olmayabilir mi?” şüphesini büyük ölçüde gideriyor; nadir senaryoda dahi sıfırdan kod yazmak gerekmiyor. Performans profili açısından da olumlu: HTMX’in çekirdek runtime’ı eval/Function constructor kullanmadığı için JIT optimizasyonları erkenden kararlı hâle geliyor; uzun süreli sayfa kullanımında memory leak profili React’in fiber tree büyümesinden belirgin biçimde daha temiz seyrediyor. Telemetri toplayan ekiplerin Sentry/Datadog gözlemleri, HTMX sayfalarda median Long Task süresinin 50 ms eşiğini neredeyse hiç aşmadığını gösteriyor — bu, Interaction to Next Paint (INP) metriğinde doğrudan iyileşme demek.

Sık Sorulan Sorular

Sonuç: HTMX Hangi Projelerde Doğru Tercih?

HTMX, SPA tekeline karşı pragmatik ve felsefi olarak sağlam bir alternatif sunar. Roy Fielding’in HATEOAS prensibini geri çağırır, REST’in unutulmuş kısmını canlandırır ve modern web geliştirmeye düşük karmaşıklıkla yüksek değer üreten bir patika açar. Karmaşık client-state gerektirmeyen kurumsal uygulamalarda %60-70 daha az kod, daha hızlı teslim, daha iyi SEO, daha düşük bundle, daha geniş tarayıcı ve erişilebilirlik desteği elde edersiniz. Verdict 2026: Yeni CRUD/admin/e-ticaret/içerik projeleri için HTMX’i ciddi olarak değerlendirin; Figma/Notion sınıfı kompleks UI ürünleri için React/Vue’da kalın; ikisi arasında bir yerde duran ürünler için hibrit (HTMX iskelet + island’lar) yaklaşımı deneyin. Carson Gross’un sözüyle: “HTML zaten yeterli — onu yeterince kullanmıyoruz.”