</> Htmx – The Fetch()ening

• htmx 4.0, mevcut XMLHttpRequest tabanlı yapıyı tamamen fetch() merkezli asenkron bir mimariyle değiştiren büyük ölçekli bir yeniden inşa sürümü
• Öznitelik kalıtım yöntemi, örtük yapıdan açık :inherited bildirimi modeline geçerek kodun netliğini ve bakım kolaylığını artırıyor
• Geçmiş önbelleği, yerel anlık görüntü saklama yerine ağ isteği tabanlı geri yükleme yöntemiyle sadeleştirilerek güvenilirliği artırıyor
• Akış yanıtları, SSE, DOM morphing, <partial> etiketi, View Transition kuyruğu gibi çeşitli yeni özellikler çekirdeğe entegre edildi
• Uzun vadede kod tabanının sadeleşmesi ve genişletilebilirliğin iyileştirilmesi hedefleniyor; mevcut 2.0 kullanıcıları da desteklenmeye devam edecek

---

htmx 4.0 genel bakış

• htmx 4.0, mevcut yapıyı baştan aşağı yeniden yazarak fixi.js geliştirme deneyimini ve 5 yıllık bakım derslerini yansıtıyor
• Başlıca değişiklikler, fetch() geçişi, öznitelik kalıtımının açık hale getirilmesi ve geçmiş önbelleğinin sadeleştirilmesi olmak üzere 3 temel değişiklikte özetleniyor

The fetch()ening

• Ajax altyapısını modernleştirmek için XMLHttpRequest, fetch() ile değiştiriliyor
  • Çoğu kullanım senaryosunda büyük bir etki olmayacak olsa da, olay modeli fetch()in asenkron yapısına göre değişiyor
• Bu geçiş, kodun sadeleşmesi ve gelecekteki özellik genişlemeleri için bir temel sağlıyor

Açık öznitelik kalıtımı

• Önceki örtük kalıtım yerine, açık bildirim için :inherited değiştiricisi kullanılıyor
  • Örnek:

    <div hx-target:inherited="#output">
        <button hx-post="/up">Like</button>
        <button hx-post="/down">Dislike</button>
    </div>
    

  • hx-target açıkça belirtilmemişse, alt öğeler bunu devralmıyor
• Çoğu kullanıcı için bu, yükseltmedeki en büyük kırıcı değişiklik olacak

Geçmiş önbelleğinin sadeleştirilmesi

• htmx 2.0’daki yerel DOM anlık görüntü önbelleği, üçüncü taraf değişiklikleri ve gizli durumlar gibi nedenlerle kararsızdı
• 4.0’da bu yapı, ağ isteği üzerinden geri yükleme yöntemine dönüştürülüyor
  • Önbellek genişletme, isteğe bağlı (opt-in) olarak sunulacak
• Bu sayede kod tabanı sadeleşiyor ve varsayılan davranışın güvenilirliği artıyor

Korunan unsurlar

• hx-get, hx-post, hx-target, hx-boost, hx-swap, hx-trigger gibi çekirdek API’ler aynı kalıyor
• :inherited eklemesi dışında, projelerin büyük kısmı mevcut kodla çalışmaya devam edebilecek
• Uzun vadeli bakım yapılabilirlik ve kararlılık güçlendiriliyor

Yükseltme politikası

• 2.0 kullanıcıları için bir yükseltme projesi gerekecek, ancak 2.0 kalıcı olarak desteklenecek
• 4.0, 2.x ile paralel dağıtılacak; lateste geçişin 2027 başında olması bekleniyor
• 2.0 davranışını geri getiren bir extension da sunulacak

Yeni özellik özeti

Akış yanıtları ve SSE entegrasyonu

• fetch()in Readable Streams desteği kullanılarak kısmi DOM değiştirme mümkün hale geliyor
• SSE(Server Sent Events), çekirdek özelliğe yeniden entegre edilerek içeriklerin kademeli güncellenmesini destekliyor

Morphing Swap

• Idiomorph algoritması temel alınarak DOM birleştirme sırasında düğüm koruma ve silme kararları iyileştiriliyor
• morphInner, morphOuter swap’leri çekirdeğe dahil ediliyor

<partial> etiketi desteği

• Mevcut Out-of-band swap sözdiziminin karmaşıklığı sadeleştiriliyor
• <partial>, hx-target, hx-swap gibi standart öznitelikleri kullanabilen bir şablon öğesi olacak
• Out-of-band swap ise yeniden id tabanlı basit değiştirme modeline dönüyor

View Transition iyileştirmeleri

• Görsel çakışmaları önlemek için bir geçiş kuyruğu (queue) ekleniyor
• CSS geçişleri mevcut yaklaşımı korurken, asenkron çalışma zamanı sayesinde sadeleşiyor
• Varsayılan olarak etkin olup olmayacağı henüz net değil

Olay sırasının istikrara kavuşması

• fetch() tabanlı asenkron yapı sayesinde olay sırasını garanti etmek daha kolay hale geliyor
• Yeni olay adlandırma kuralı getiriliyor:
  htmx:<phase>:<system>[:<optional-sub-action>]
  • Örnek: htmx:before:request

Genişletilebilirliğin artırılması

• async tabanlı olarak ön istek (preload) ve iyimser güncelleme (optimistic update) extension’ları sunulacak
• İstek/yanıt/swap döngüsü extension geliştiricilerine açılıyor ve fetch() implementasyonu değiştirilebiliyor
• Böylece hack kullanmadan istenen davranış gerçekleştirilebiliyor

hx-on iyileştirmeleri

• Standartlaştırılmış hx-on:<event name> sözdizimi benimseniyor
• Asenkron API desteğiyle basit DOM scripting mümkün hale geliyor

  <button hx-post="/like"
          hx-on:htmx:after:swap="await timeout('3s'); ctx.newContent[0].remove()">
      Get A Response Then Remove It 3 Seconds Later
  </button>
  

• eval() devre dışı ortamlarda da çalışıyor, ancak bazı özellikler sınırlı kalıyor

Genel yönelim

• htmx 4.0, 2.0’a benzer kullanım hissini korurken hataları azaltmayı ve yetenekleri geliştirmeyi hedefliyor
• Kod sadeleştirmesi, açık yapı ve asenkron tabanlı genişletilebilirlikle daha kararlı ve daha modern bir htmx sunuyor

Geliştirme takvimi

• Alfa sürümü (htmx@4.0.0-alpha1) şu anda yayımlandı
• Resmî 4.0.0 sürümünün 2026’nın başı ile ortası arasında çıkması planlanıyor
• 2027 başında latest sürümüne geçirilmesi bekleniyor
• Geliştirme durumu GitHub four dalı ve four.htmx.org üzerinden takip edilebilir

---

[GN⁺]

Hacker News görüşleri

• Sonunda fikrini değiştirip htmx'in yeni bir majör sürümünü çıkarmaya karar vermiş
  Ancak “3.0 olmayacak” sözünü tutmak için bir sonraki sürümü htmx 4.0 olarak adlandırmış
  Bunun teknik olarak doğru bir ifade olduğunu söyleyerek esprili bir tavır sergiliyor

  • Eğlenceli bir çözüm, ama geçmişte ortadan kaybolan PHP 6 gibi kullanıcıları da şaşırtabilir
    Belki de dürüstçe 3.0 olarak çıkarmak daha iyi olurdu
  • Doğrudan htmx 4.1'e geçip “xhtmx 1.0” yapalım diye şaka yapılıyor
  • Bunun Leisure Suit Larry 4: The Missing Floppies havası verdiği söyleniyor
  • En azından “3. sürüm olmayacak” dememesi sayesinde ifade payı bıraktığından bahsediliyor

• htmx 2.0'ın kalıcı olarak destekleneceği söyleniyor, yani yükseltme baskısı hiç yok
  API değişikliklerinin sık yaşandığı bu dönemde bu yaklaşım övgüyü hak ediyor

• İstikrar arayanların bazen buradan yanlış dersler çıkardığı düşünülüyor
  Python 3.0'da olduğu gibi büyük değişiklikleri tek seferde toplamak yerine, kademeli sürüm stratejisinin daha iyi olduğu savunuluyor
  Örneğin değişiklikleri 2.1, 4.0, 5.0 gibi sürümlere bölerek getirmek yönetimi çok daha kolaylaştırır
  Django'da olduğu gibi birden fazla sürüm boyunca uyumluluk aşamalarını koruyan bir yöntem öneriliyor

• hx-target niteliğine dair açıklama kafa karıştırıcı bulunuyor
  “inherited” yerine “inheritable” ya da “inherit” daha doğal görünüyor

  • Kendi okumasında bunun “çocuk öğe miras alıyor” anlamına geldiğini, bu yüzden “pass-down” gibi bir ifadenin daha açık olabileceğini söylüyor
  • “inherited”in yanlış kelime olduğunu, “inherit”in kısa ve iyi olduğunu belirtiyor
    Şaka yollu olarak “bequeath” de olabilir diye ekliyor
  • Farklı ifadeleri değerlendirdiğini ve geri bildirime açık olduğunu söylüyor
  • “heritable” veya “cascade” gibi alternatifler de öneriliyor

• HTMX'in fikrini ve Hypermedia felsefesini etkileyici buluyor
  SPA ortamından çıkıp Datastar'ı seçmiş, çünkü öğrenme yatırımına kıyasla ölçeklenebilirliğinin daha yüksek olduğunu düşünüyor
  Sunucudan tarayıcıya sinyalleri doğrudan push ederek polling kodunu kaldırmış ve karmaşıklığı ciddi biçimde azaltmış
  Alpine.js bağımlılığını da kaldırdığı için kod sadeleşmiş; streaming tabanlı tam görünüm güncellemeleri de sıkıştırma sayesinde verimli çalışmış
  SPA tarafından geliyorsanız hem Datastar'ı hem HTMX'i denemenizi öneriyor

• fetch()e geçip Readable Stream kullanmaları ilgi çekici bulunuyor
  HTMX'i epey kullanmış olsa da, Datastar'ın SSE tabanlı streaming yaklaşımını daha cazip bulduğu için son dönemde onu tercih ettiğini söylüyor

• HTMX'in gelişmesi memnuniyet verici olsa da, Datastar'ın daha standart dostu ve esnek bir API sunduğu düşünülüyor
  Küçük bir pakette Fetch, SSE, declarative signals, DOM morphing gibi pek çok özellik bulunduğu söyleniyor
  Bu yüzden “neden HTMX kullanayım ki?” sorusu soruluyor

  • Datastar Pro açık kaynak olmadığı için güven riski taşıdığına dikkat çekiliyor
  • Datastar'ın yaratıcısının zamanında bu özellikleri HTMX'e eklemeye çalışmış olmasının ironik olduğu belirtiliyor
  • HTMX'in gücünün, request/response paradigmasına optimize edilmiş basit arayüzünde yattığı açıklanıyor
    Datastar event stream merkezli olduğu için gerçek zamanlı panolar veya oyunlar için uygun olabilir, ama çoğu web uygulamasında HTMX'in sadeliği daha avantajlıdır
    İlgili okumalar: Datastar essay, Less HTMX is More
  • HTMX, tarayıcının URL history yönetimini kolayca desteklerken, Datastar'ın bu özelliği ücretli (Pro) sürüme koyduğu söyleniyor

• “O kadar mükemmel ki artık yeni majör sürüm yok” sözünden sonra sonunda evrim ihtiyacını kabul etmiş olmasına takılıyor
  “Şimdi event naming standardını değiştiriyoruz” kısmını alıntılayarak, JavaScript'ten kaçma çabasını hicvediyor

  • “Sonunda JavaScript yazmamak için özel bir sözdizimini JS ile yorumlar hale geldiler” diye iğneliyor
    Yine de niyetin HTML içinde ifade edilebilmesini olumlu buluyor
  • “Bu sefer gerçekten son sürüm olur” diye şaka yapılıyor
  • “Yine de JavaScript'i doğrudan yazmaktan iyidir” diyerek olumlu yaklaşılıyor
  • “Yazarın fikrini değiştirmesinde ne sorun var?” denilerek eleştirel tona itiraz ediliyor

• Yazının çok açık olduğu ve buradan API tasarım felsefesi hakkında çok şey öğrenilebildiği söyleniyor

• fetch ile HTMX'i birlikte kullanmak için xhr-fetch-proxy oluşturduğunu,
  bu değişiklikle birlikte daha fazla olasılığın açılacağını düşündüğünü söylüyor
  Proje bağlantısı

  • 4.0'da request cycle tamamen açıldığı için her istekte fetch implementasyonunu değiştirebilmenin mümkün olduğu belirtiliyor
    Bu fikri fixi.js'ten öğrendiğini de ekliyor