HTMX, lütfen en az bir kez deneyin

 (pleasejusttryhtmx.com)
21 puan yazan GN⁺ 2025-12-19 | 8 yorum | WhatsApp'ta paylaş
  • Modern web geliştirmede HTML ile büyük JavaScript framework'leri arasında kurulan sahte ikilem, geliştiricileri gereksiz karmaşıklığa sürüklüyor
  • HTMX, yalnızca HTML öznitelikleriyle AJAX istekleri, kısmi güncellemeler ve animasyonlu geçişleri yöneterek, sunucunun döndürdüğü HTML'i doğrudan ekrana yansıtan bir yaklaşım sunuyor
  • Mevcut kod tabanını büyük ölçüde değiştirmeden kademeli olarak benimsenebilen yapısıyla frontend karmaşıklığını azaltıp üretkenliği ve bakım kolaylığını artırabiliyor
  • React tabanlı SPA'lara kıyasla kod miktarı, bağımlılık, build süresi ve yükleme hızı açısından büyük iyileşmelerin gerçek üretim ortamlarında görüldüğü aktarılıyor
  • Aşırı framework tercihleri yerine basit hipermedya tabanlı yaklaşımın uzun vadede üretkenlik ve bakım açısından daha avantajlı olduğu savunuluyor

Sorunun ortaya konması: web geliştirmedeki sahte seçenek

  • Web geliştirme tartışmalarında ya yalnızca HTML kullanmak ya da React gibi büyük framework'lere yönelmek şeklinde uç seçenekler tekrar tekrar karşımıza çıkıyor
  • Saf HTML; link, form, dialog gibi temel işlevlerde güçlü olsa da kısmi güncelleme veya anında tepki verme konusunda sınırları var
  • React·Vue·Angular seçildiğinde yüzlerce bağımlılık, yavaş build'ler ve karmaşık durum yönetimi tartışmaları da beraberinde geliyor
  • Basit CRUD, dashboard ve form ağırlıklı uygulamalarda bile gereğinden ağır araç zincirlerinin kullanılması yaygın hale gelmiş durumda

HTMX'in temel kavramı

  • HTMX, HTML öğelerine özel öznitelikler ekleyerek sunucuyla asenkron iletişim kurmayı sağlayan bir araç
    • Örneğin hx-get, hx-post öznitelikleriyle istek gönderip yanıtı belirli bir DOM alanına yerleştirebiliyor
  • Her HTML öğesinin bir HTTP isteği başlatıcısı olabilmesini sağlayacak şekilde genişletiliyor
  • Sunucu JSON yerine HTML parçalarını doğrudan döndürüyor ve dönen HTML belirtilen konumda otomatik olarak değiştiriliyor veya ekleniyor
  • Doğrudan JavaScript yazmadan, yalnızca HTML öznitelik bildirimleriyle davranış tanımlanabiliyor
  • Yaklaşık 14kb(gzip) boyutundaki kütüphane oldukça hafif
  • Ayrı bir build aracı ya da framework ayarı olmadan mevcut HTML belgelerine doğrudan uygulanabiliyor
  • Sunucu tarafı render odaklı geleneksel web geliştirme yaklaşımıyla iyi uyum sağlıyor

Başlıca özellikler

  • AJAX istek işleme: HTML öznitelikleriyle GET ve POST istekleri yapılabiliyor
  • DOM güncelleme: Sunucudan dönen HTML belirlenen öğeye otomatik olarak yansıtılıyor
  • Olay işleme: Tıklama, giriş gibi kullanıcı olaylarına göre sunucu çağrıları bağlanabiliyor
  • Geçmiş yönetimi: Tarayıcının geri ve ileri hareketleriyle entegre çalışabiliyor

Gerçek kullanım örnekleri ve sayılar

  • Contexte, React tabanlı SaaS ürününü Django + HTMX'e taşıdı
    • Toplam kod satırı sayısında %67 azalma (21,500 → 7,200)
    • JavaScript bağımlılıklarında %96 azalma (255 → 9)
    • Build süresinde %88 kısalma (40 saniye → 5 saniye)
    • Sayfa yükleme hızında %50~60 iyileşme
  • Kod tabanının üçte ikisi silinmiş ve uygulama daha iyi hale gelmiş
  • Frontend ve backend ayrımı olmadan tüm geliştiriciler full-stack çalışabilir hale gelmiş

Sık görülen itirazlara yanıtlar

  • "Karmaşık istemci durum yönetimi gerekmiyor mu?"
    • Gerçekte çoğu ihtiyaç formlar, listeler ve tıklamayla görünen öğeler düzeyinde; bunlar HTMX ile rahatça karşılanabiliyor
    • Google Docs gibi gerçek zamanlı işbirliği araçları istisna olabilir ama çoğu durumda CRUD uygulamaları gereğinden fazla büyütülüyor
  • "React ekosisteminin sağladığı avantajlar ne olacak?"
    • Geniş ekosistem çoğu zaman GB'larca node_modules, bitmeyen seçenekler ve durum yönetimi tartışmaları anlamına geliyor
    • HTMX ekosistemi ise çoğu zaman seçtiğiniz tek bir sunucu tarafı dille sınırlı kalıyor
  • "SPA'lar hissedilen hız açısından daha hızlı değil mi?"
    • Başlangıçta büyük JavaScript paketlerinin indirilmesi, parse edilmesi, çalıştırılması ve hydration süreçlerinin tamamı gerekiyor
    • HTMX ise ilk yüklemeden itibaren hızlı ve sonrasında da yalnızca değişen kısımları değiştirerek bu hızı koruyabiliyor
  • "Peki belirli React özellikleri gerçekten gerekliyse?"
    • Bazı durumlarda React uygun olabilir
    • Ancak pratikte çoğu zaman toplam problemin yalnızca küçük bir bölümü için gerekli olan araç alışkanlıkla tüm projeye seçiliyor
  • Neden HTMX seçilmeli?
    • Ekiplerin başarısız olmasının nedeni yanlış framework değil, aşırı framework seçimi
    • HTMX, sadeliğe yatırım yapıyor ve uzun vadede sadelik bakım kolaylığı ile üretkenlik açısından avantaj sağlıyor

HTMX'in uygun olmadığı durumlar

  • Gerçek zamanlı işbirlikçi düzenleme araçları (Google Docs, Figma)
  • Büyük ölçekli istemci tarafı hesaplama gerektiren uygulamalar (video editörleri, CAD araçları)
  • Offline-first yapılar (elbette farklı yaklaşımlar birleştirilebilir)
  • Gerçekten karmaşık UI durumu gerektiren senaryolar
  • Ama gerçekten böyle bir şey mi geliştiriyorsunuz?
    • Yoksa sadece formlar, tablolar ve listelerden oluşan bir başka dashboard, yönetim paneli, e-ticaret sitesi, blog ya da SaaS uygulaması mı yapıyorsunuz?
    • Bu tür işler için HTMX gerçekten şaşırtıcı derecede iyi; insana adeta "Bunu neden bu kadar karmaşık yaptık?" ve "Vay canına, bugüne kadar ne kadar çok zaman harcamışız" dedirtiyor

O halde bir kez deneyin

  • React de kullandınız, Vue da kullandınız; belki Angular'ı da deneyip pişman oldunuz, değil mi?
    • Bu hafta Hacker News'te popüler olan meta-framework'e de muhtemelen bir noktada göz atmışsınızdır
  • HTMX'i sadece bir kez deneyin
    • Bir hafta sonundan bir gün ayırın
    • Bir yan proje seçin ya da
    • Kimsenin çok da önemsemediği bir iç aracı ele alın ya da
    • Bir gün yeniden yapmak üzere ertelediğiniz bir şeyi tekrar ortaya çıkarın
  • <script> etiketi ekleyip bir hx-get özniteliği yazın ve nasıl çalıştığını bizzat görün
  • En kötü ihtimalle bir hafta sonunun bir gününü kaybedersiniz; zarar büyük değil
    • Ama muhtemelen hoşunuza gidecek
    • Hatta gerçekte, web geliştirmenin neden bu kadar karmaşık hale geldiğini sorgulamaya başlayacaksınız

İlgili okumalar

8 yorum

 
iolothebard 2025-12-20

Geçen yıl böyle bir sunum yapmışım. Dinleyen pek olmamıştı ama^^
https://www.slideshare.net/slideshow/htmx-2024/274315966

PoC düzeyinde şöyle bir şey de yapmıştım
https://github.com/iolo/hx

Ama yine de kimse htmx kullanmıyor haha
 
shakespeares 2025-12-21

Zaten alışılmış duruma ve buna paralel olarak oluşmuş büyük ölçekli ekosistem yapısına yerleştikten sonra, sanki artık yeniliğe yönelik bir hareket kalmamış gibi görünmesi üzücü.
 
roxie 2025-12-20

Slaytlar eğlenceliymiş, sunumu izleyemediğim için üzüldüm hahaha
 
ryj0902 2025-12-22

PyCon'da bununla ilgili bir konuşma dinlemiştim; konuşmacının da bunu henüz gerçek bir projede kullanma fırsatı bulamadığını söylemesi aklımda kalmış.
 
aer0700 2025-12-21

Rust, lütfen bir kez deneyin?
 
bbulbum 2025-12-20

Alpine.js'i denemiştim ama çoğu durumda state yönetimine ihtiyaç duyuluyordu...
En baştan backend'de state yönetilecek şekilde tasarlamadıkça, adım adım state, koşullu state gibi durumları çözmenin epey can sıkıcı olduğunu hatırlıyorum.
 
roxie 2025-12-20

Söylenenlerin hepsine katılıyorum ama nedense htmx'e elim gitmiyor :(
 
GN⁺ 2025-12-19
Hacker News görüşleri

  • Ben htmx'in yaratıcısıyım. Abartılı yazılar sayesinde dikkat çekmesi güzel ama bu tarz hype'tan pek hoşlanmıyorum
    Web uygulaması geliştirmenin birçok yolu var ve her birinin artıları ile eksileri bulunuyor. htmx'in güçlü ve zayıf yönlerini bu yazıda özetledim
    Bir diğer harika hypermedia odaklı kütüphane olan Unpoly'yi de mutlaka denemenizi öneririm
    (ek) Yazıya tekrar bakınca düşündüğümden daha iyi buldum. Yine de htmx'in biraz daha sakin bir üslupla ele alınmasını isterim

    • 1990'ların sonu, 2000'lerin başındaki web uygulaması geliştirme tarzına alışkınsanız, HTMX ile az çabayla etkileşimli özellikler eklemek çok kolay
      Açılır menüyle alan güncelleme, modal oluşturma, otomatik tamamlama arama kutusu gibi şeylerin hepsi basit
      Ancak RIA frontend'lerinin karmaşıklığı, veri değiştiğinde frontend'in nasıl güncelleneceğinde yatıyor.
      Backend tarafında biraz düzenleme gerekiyor ve birden fazla partial güncellemeyi birlikte işleyebilen bir yapı varsa daha da iyi oluyor
    • HTMX Sucks diye bir yazı da var. İlginç bir bakış açısı
    • Unpoly gerçekten çok iyi görünüyor. HTMX'i henüz kullanmadım ama Django ya da Rails gibi framework'lerin UX sorunlarını hafifçe çözmesi hoşuma gidiyor
      Şu anda Rails + Stimulus ile bir yan proje yapıyorum ama Stimulus biraz fazla geliyor. Inertia veya Stimulus'u ne zaman seçmek gerektiğini merak ediyorum
    • Bu arada ben htmx'in CEO'suyum ve böyle abartılı yazılara bayılıyorum
    • Unpoly'nin dokümantasyonu da harika ama biraz karmaşık geliyor. Daha basit durumlarda Alpine AJAX kullanıyorum.
      Bir Alpine.js eklentisi olarak linklere ve formlara temel AJAX özellikleri ekliyor

  • React'ten daha iyi olduğunu “Hello World” örneğiyle savunan yazılardan bıktım
    Basit örneklerde her şey iyi çalışır. Ama gerçekte çoğu zaman bağımlılığı çok olan bir backend ve karmaşık bir UI vardır

    • Geliştiricilerin aşırı basit framework'lerden korkmasının nedeni, eninde sonunda ölçeklenebilirlik sınırına çarpma ihtimalidir
      Temel demolar güzel ama daha karmaşık özellikler eklendiğinde bunun nasıl genişletilebildiğini de göstermek gerekir
      JS'nin nereye ekleneceğini, build step gerekip gerekmediğini, htmx paradigmasına ne kadar bağlı kalındığını merak ediyorum
    • Fizzy gibi 37signals'ın Hotwire ile yaptığı uygulamalar da var.
      React'ten daha iyi olmaktan ziyade başka bir yaklaşım sadece
    • Bizim intranet Python + HTMX kombinasyonuyla çalışıyor. Şimdiye kadar yapamadığımız hiçbir şey olmadı
      DOM'un bir kısmını değiştirme paradigması çok basit ve sezgisel
    • Tersine, bazı aşırı karmaşık teknolojiler “Hello World” aşamasından itibaren zor oluyor
      Örneğin effect-ts güçlü ama en basit çıktıyı bile vermek karmaşık
    • Go + Htmx ile yapılmış bir gerçek zamanlı planning poker uygulaması var. Yaklaşık 500 satır kodla yazılmış

  • Startup'ımız HTMX'i benimsedi ama sonunda React'e geçiyoruz
    HTMX'te yanıt işleme karmaşıklığı yüksek ve her endpoint'in birden fazla HTML parçası döndürmesi gerekiyor
    Dokümantasyon ve örnekler yetersiz, büyük ölçekli best practice'ler de yok.
    React olgun bir ekosistem ve yapay zeka destekli kodlama ile de iyi anlaşıyor. HTMX basit projeler için uygun ama ötesi zor

    • Ben HTMX ile akıcı mimari kalıplar buldum
      Her endpoint tek bir sorumluluk üstleniyor ve Optimistic UI sayesinde anında tepki veriyor
      Hata işleme basit tutuluyor, hx-swap-oob ise minimum düzeyde kullanılıyor
      Teknoloji seçiminde asıl mesele trade-off'ları en aza indirmek
    • Frontend ve backend'in tüm senaryolarda uzlaşması gerektiği zaten açık.
      Bu yüzden ben backend doğrulamasını merkezde tutup frontend'in sadece gösterim yapmasını tercih ediyorum
    • Hypermedia Systems kitabı bunu daha bütünlüklü şekilde anlatıyor
    • Anlamadığın niş bir çözümü seçip sonra başka bir karmaşık çözüme geçmek, sadece trade-off'ları tekrar etmek demek
    • Teknolojiyi “yapay zeka destekli kodlamaya iyi geliyor” diye seçmek biraz üzücü

  • Ben SSR istemiyorum. Backend sadece JSON API sağlasın, frontend de onu tüketsin istiyorum
    SSR'nin gereğinden fazla övüldüğünü düşünüyorum. Sanki cloud servisleri satmak için kullanılan bir yönlendirme gibi

  • Demo 3 Live Search örneğinde ciddi bir scroll jank sorunu var.
    Sonuçlar doğrudan belge içine eklendiği için yerleşim sürekli yeniden hesaplanıyor gibi görünüyor

  • React gayet yeterli. Basit projelerde bile sırf farklı bir paradigma olsun diye başka bir şey öğrenmeye gerek yok

    • React de sonuçta HTML'e render ediyor, yani HTML/CSS öğrenmek gerekiyor. Sadece üstünde bir soyutlama var
    • React ekosistemi o kadar geniş ki sürekli öğrenip unutma yorgunluğu yaratıyor
      HTMX'te ise kavramları 15 dakikada öğrenip 10 yıl kullanabilirsiniz
    • React ya da Angular, MVC üstüne bir MVC daha koyan yapılara benziyor. Gereksiz derecede karmaşıklar
    • Ağır çözümleri her yerde kullanmak verimsiz.
      Tarihsel olarak hafif paradigmalar pazarda kazanmıştır. React de bir zamanlar böyleydi
    • Sebep basit — performans

  • Ben HTMX'e değil, Alpine.js'e tamamen vuruldum
    Sunucuda render edilmiş HTML'i güçlendirme (enhance) fikri kafama çok yattı
    Açılır menüler, show/hide gibi şeylerin hepsi sezgisel ve build step gerektirmiyor

    • Alpine'da da Alpine AJAX eklentisi var; HTMX'e benzer işlevler sunuyor
    • Ben de Alpine.js kullanıyorum ve frontend yeniden keyifli hale geldi
      Sezgisel ve büyük projelerde de yönetmesi kolay
    • Ama ticari projelerde Alpine bir kâbus olabilir
      JS'yi HTML içine inline koydukça bakım zorlaşıyor ve durum yönetimi de örtük hale geliyor
      Hotwire ya da Stimulus organizasyon ölçeğinde çok daha iyi hissettiriyor
    • Deklaratif yaklaşım doğru yol

  • Büyük uygulamalarda HTMX kullanıldığında sunucu yükü ve maliyeti nasıl oluyor, merak ediyorum
    HTML sunucuda render edildiği için JSON'a göre daha fazla işlem gerektiriyor gibi geliyor

    • Ama durum mutlaka öyle değil. Template render etme çok hızlıdır
      Bazen JSON serileştirmeden bile verimli olabilir, ayrıca istemci tarafında da deserialize maliyeti vardır
      HTMX, Alpine.js gibi araçlarla birlikte kullanıldığında karmaşık durumları da rahatça yönetebilir
      Her senaryoya uymaz ama birçok durumda çok iyi çalışır

  • Framework misyonerliği web ekosistemindeki en kötü kültür
    İyi bir çözümse zaten benimsenir. İnsanların vaiz gibi davranmasına gerek yok
    npm saldırıları da abartılıyor. htmx de sonuçta npm kullanabiliyor

    • htmx, bağımlılığı olmayan tek bir dosya olduğu için npm zorunlu değil
    • “İyi çözümler doğal olarak benimsenir” sözü doğru değil.
      Dünyada pazarlama ve bilinirlik sayesinde benimsenmiş pek çok kötü çözüm var
    • Popülerlik, bütçe ve atalet teknoloji benimsemeyi belirliyor.
      Gerçek zanaatkârlığı korumak istiyorsak bu tür önyargılara karşı durmak gerekir

  • HTMX, iki dünyanın da sadece kötü yanlarını birleştirmiş gibi görünüyor
    SSR tutarlı bir yapı sunar, CSR ise ayrışmış bir yapı sunar; HTMX ise ikisini karıştırıp örtük bir bağlanma yaratıyor
    Aynı veriyi farklı biçimlerde göstermek için backend'de iki endpoint mi oluşturmak gerekiyor diye merak ediyorum

    • Frontend durumunun mutlaka gerekli olduğu düşüncesinden çıkmak lazım
      Uygulamaların çoğunda backend durumu tek başına yeterlidir; UX iyileştirmesi dışında büyük bir kazanç sağlamaz
    • Splitting Your APIs yazısına bakılırsa bu aslında iyi bir şey
    • Jinja gibi sunucu şablonları kullanırsanız tek bir render ile birden fazla sunum biçimini işleyebilirsiniz
      Tüm sayfa sunucuda oluşturuluyorsa veri zaten onun içindedir