Htmx’e Yönelik Ölçülü Bir Eleştiri

• Htmx’in temel ve basit fikrini gerçekten seviyorum, ancak tüm ekip olarak kullandıktan sonra pratikte basit olmadığını ve epey karmaşık olduğunu gördük

Htmx özellik kalıtımı kesinlikle bir hata

• Kod parçalarında özellik kalıtımı örtük ve şaşırtıcı
• CSS’te olduğu gibi kalıtım ucuz bir hile ama bir bedeli var
• Yazarın davranışın yerelliği iddiasıyla çelişiyor
• Birden çok özellikte varsayılan kalıtım farklı (ör. hx-delete kalıtılmıyor ama hx-confirm ve hx-ext kalıtılıyor)
• İstisnaları ezberlemek gerekiyor ve her şeyi açıkça ifade etmeye itiyor; bu da kalıtımı anlamsızlaştırıyor

Çoğu ilginç web uygulaması DOM öğelerini bütünüyle değiştiremez

• DOM öğeleri neredeyse her zaman tarayıcıya yerel durum taşır (ör. <details> öğesinin açık/kapalı durumu, <input> öğesinin giriş değeri, açılır menü öğesinin açık/kapalı durumu)
• Htmx’in outerHTML’i doğrudan değiştiren basit yaklaşımı kullanıldığında bu durumların hepsi kaybolur
• Morphdom eklentisi de beklendiği gibi davranmayıp bazı öğelerin üzerine yazar

Durumu doğrudan DOM öğesinin kendisinde saklamak kötü bir fikir

• Morphdom, önceki başlıktaki sıkıntıyı çözmek için var, ancak Htmx’in çalışma biçiminin öğeleri bütünüyle değiştirmeye dayandığını görüyoruz
• İstek kuyruğunu doğrudan DOM öğesinin kendisinde saklıyor
• Bir isteği başlattığınızda ilgili öğe veya ona işaret eden başka bir öğe istek kuyruğunu taşıyor
• DOM öğesi bütünüyle değiştirildiğinde kuyruk sıfırlanıyor; bu da bazı kötü hata modlarından kaçınmayı sağlıyor
• Ancak Morphdom’da öğe korunduğu için kuyruk da korunuyor
• Böylece Htmx tasarımının ihlal edildiği, bir tür tanımsız davranış alanına giriliyor

Varsayılan kuyruklama modu berbat

• Varsayılan olarak Htmx, aynı kuyrukta (öğede) başka bir istek tetiklenirse sürmekte olan isteği iptal ediyor
• Varsayılan strateji bu
• Bunu sonradan fark ettim
• Oldukça sezgi dışı ve yapılan işin kaybolması anlamına geliyor

Olay tetikleyicileri yerel değil

• Olay tetikleyicileri çoğu zaman bir şeylerin olmasını sağlamaya yardımcı oluyor, ancak yerel etkiler değiller ve özellik kalıtımına benzer sorunlar taşıyorlar
• Sunucu tarafı dillerde DSL çalışmaları bunu bir yere kadar hafifletebilir, ama yine de eski usul JavaScript callback tabanlı programlamaya benziyor
• Bir olay meydana geliyor, siz de ona "abone" olup bir şey yapıyorsunuz

Bileşen durumunu iyi koruyamıyor

• DOM öğesi durumu sorununa benzeyen daha geniş bir sorun, kendi bileşenlerinizin de kendi durumuna sahip olması
  • Örneğin sunucunun ihtiyaç duyduğu kendi durumu olan (ör. sonuç kümesinin sayfası) ve React ya da WebComponents’in ihtiyaç duyduğu durumu olan üç bölümden oluşan bir sayfa istiyorsanız, ebeveyn ve çocuk bileşenler arasında durumu eşitleme problemi ortaya çıkıyor
• Htmx bunun için iyi bir yol sunmuyor
  • Sorgu parametreleri, gizli form girdileri, olay tetikleyicileri vb. kullanma fikirleri var ama hepsinin ciddi çekinceleri bulunuyor
• React ve Halogen’in buna bir cevabı var
  • Her iki durumda da çocuk bileşenler kendi durumuna sahip; ebeveyn ise "öneri" gibi "props" sağlayabiliyor
  • Ayrıca kendi iç durumlarına da sahipler ve bunu props’u görmezden gelmek ya da ona öncelik vermek için kullanabiliyorlar
  • Props genellikle sunucudan geliyor ya da sunucudan türetiliyor; durum ise genellikle istemci tarafı durumu oluyor
• React ile sunulan veya kullanmak zorunda olduğunuz hazır bileşenler çoğu zaman React gerektiriyor
  • React ile Htmx iyi etkileşmiyor
  • WebComponents ile tatmin edici olmayan çalışmalar yaptım ama onların da şaşırtıcı derecede tuhaf kısıtları var
  • Hatta sunucu tarafı dilde kullandığımız React bileşenlerine doğrudan köprüler de kurduk, fakat genel olarak Htmx ve React durum akışı ve DOM öğesi yönetimi konusunda çatışıyor
  • Alpine’ı denedim; güzel ama bu da başka bir istemci tarafı programlama kütüphanesi, dolayısıyla kod tabanında zaten React varsa tekrar yaratıyor

Buna rağmen artıları var

• Sunucu tarafı dillerin kullanılabilmesi son derece açık ve tartışmasız büyük bir avantaj
• Ekipte hiç kimse tüm bu iş mantığını tekrar TypeScript ile yazmak istemez
• Veritabanı türlerinden frontend türlerine serileştirme gerekmiyor
  • Veri sızıntısı yok ve GraphQL de gerekmiyor
• Sunucu tarafı dillerin daha güçlü soyutlama yeteneklerinden yararlanılabiliyor
• Aynı doğrulama için frontend ve backend’de ayrı ayrı uygulama yazmak yerine sunucu tarafı dilin form oluşturucusu kullanılabiliyor
• Ama yukarıdaki eksiler de gerçek

React içinde Htmx?

• Cazip bir gelecek yönü, Htmx’i React içinde yeniden uygulamak olabilir
  • Sunucu bir JSON blob gönderir ve React bunu sanal DOM bileşenlerine dönüştürür
  • Böylece bileşen durumu sorunu çözülmüş olur
  • React bileşenlerini kullanmak için özel köprüler gerekmez
  • React ile entegre web veri çekme kütüphaneleri kullanılabilir ve Htmx’te özellikle kaçınılması gereken bir kuyruklama tercihinden sakınılabilir
  • Morphdom sorunları ve tarayıcı DOM input öğeleriyle ilgili sorunlar da çözülmüş olur; bunlar React’te neredeyse çözülmüş problemler
• Böylece Htmx bağımlılığı kaldırılırken fikrin avantajları korunabilir. Tabii böyle büyük bir işe girişecek bütçe verilirse

GN⁺ görüşü

• Htmx’in temel fikri çekici, ancak gerçek kullanımda çeşitli karmaşık sorunlarla karşılaşılabiliyor
• Özellik kalıtımı, DOM öğesi değiştirme, kuyruklama modu gibi Htmx’in bazı tasarımları sezgisel değil ve beklenmedik davranışlara yol açabiliyor
• React veya WebComponents ile entegrasyonun da kolay olmadığı görülüyor
• Buna rağmen sunucu tarafı dillerin kullanılabilmesi büyük bir avantaj
• Gelecekte React tabanlı bir Htmx yeniden uygulaması da ilginç bir yön olabilir

[felizgeek]

İlgi, ilgisizlikten iyidir~ Ben HTMX'i seviyorum. Felsefesiyle birlikte.
Ayrıca SQLite ile de havası gerçekten çok benziyor haha

[savvykang]

SQLite ve HTMX hangi açılardan benzer?

[aer0700]

Sqlite'a benziyor mu?

[halfenif]

Yorum gerçekten derin. Felsefe yani..

[savvykang]

SPA ortaya çıkmadan önce server-side rendering ve jQuery ile web geliştirme deneyiminiz varsa, bunun o taraftaki bir teknoloji olduğunu hemen anlarsınız. Sanırım web geliştirmeye SPA ile başlayanlar, yeni bir şey ararken yanılgıya düşüyor.

[heycalmdown]

Bu yazı sanki Kore'de yazılmış bir yazı değil gibi.

[ndrgrd]

Aynen öyle. Sanki basit sayfalar için yapılmış bir araç gibi; ama tuhaf örnekler ya da kullanım senaryoları getirip ona uygun olmadığını söyleyerek neden tartışma çıkarıldığını anlamıyorum.

[roxie]

htmx’in ana sayfasından da anlaşılacağı gibi, htmx, (yalnızca kendileri olsa) React’i de kapsayan modern frontend teknolojilerine gerek olmadığı görüşüne yakın duruyor

[rlrsbtm80879]

Bu, htmx'in neden ilgi gördüğüyle ilgili. Bu yazı da yabancı bir katkı yazısından çevrilmiş; yurt dışında insanlar React'in her türlü state yönetiminden yorulmuş durumda. Bu yüzden, React'e benzer işlevler sunarken React'ten farklı olarak state yönetimi gerektirmeyen htmx'i React'e alternatif olarak gördüler. Bu nedenle htmx'i sürekli React ile karşılaştırıyorlar.

[ndrgrd]

Pek sayılmaz. Eğer gerekçe buysa, React'ın yerini alabileceğini iddia eden bir şeyi getirip onunla karşılaştırmak daha doğru olmaz mı?

Bu sayfada listelenen özelliklere bakınca bile, HTMX'in karmaşık sayfalarda kullanılacak bir şey olmadığı ve React'ın yerini alabilecek herhangi bir şey olmadığı açık.

[GN⁺]

Hacker News görüşleri

• Özellik kalıtımı konusunda görüşler bölünmüş durumda. htmx.config.disableInheritance seçeneğiyle devre dışı bırakılabiliyor

  • İstemci tarafı durumu ile htmx değiştirmeleri her zaman iyi örtüşmüyor. Özellikle basit durumlarda böyle
  • Event’ler güçlü ama karmaşık ve debug etmesi zor. Bu, event tabanlı programlamanın bir özelliği
  • Varsayılan kuyruk moduna katılmıyor. Mevcut isteği iptal edip değiştirmek yerine, mevcut isteği koruyup yalnızca ek bir isteği bekletiyor
  • htmx’ten hoşlanmayanlar için kupa tanıtımı

• Frontend’e girmemesinin nedeni seçeneklerin çok olması, eleştirinin fazla olması ve teknoloji trendlerinin sık değişmesi

  • Backend ve sistem programlamada da görüş ayrılıkları var ama frontend’e göre daha az kaotik

• HTMX kullanarak yüksek performanslı bir storefront inşa ediyor ve sonuçtan memnun

  • Brezilya’daki büyük bir giyim perakendecisinde HTMX ve kısmi render stratejisi kullanılıyor

• "HTMX in React" fikri, React Server Components’i yeniden icat etmek gibi

  • Sunucu JSON gönderiyor ve React bunu virtual DOM component’lerine dönüştürüyor
  • Component state sorununu çözüyor ve özel bir bridge olmadan React component’lerini kullanmayı sağlıyor
  • React ile bağlantılı web fetching kütüphaneleri kullanılabiliyor ve HTMX’in kuyruk seçimi sorunundan kaçınılabiliyor
  • morphdom sorunları ve tarayıcı DOM input elemanı sorunları çözülebiliyor
  • RSC hâlâ deneysel ve varsayılan uygulama sunucuda JS çalıştığını varsayıyor

• Varsayılan kuyruk modunun mantıksız olduğu görüşüne katılmıyor

  • Kullanıcı bir girdiyi submit edip arada değişiklik yaptıktan sonra tekrar submit ederse isteğin iptal edilmesi gerekir
  • Yanıt içeriği farklı bir ID ile değiştiriyorsa ikinci yanıt aynı şekilde değiştirilemez

• HTMX’i ilk kez denemiş; basit işlerde kolay uygulanabildiğini ve eğlenceli olduğunu düşünmüş

  • Karmaşık projelerde kullanıp kullanmayacağından henüz emin değil

• State hakkındaki şikâyetleri okuyunca, yazarın React öncesinde hiç web sitesi yapmadığını düşündüğünü söylüyor

  • Verilen örnek anlaşılır gelmiyor ve sanki htmx’i React gibi kullanmaya çalışıp beklentisi karşılanmayınca hayal kırıklığı yaşamış gibi duruyor

• HTMX’te Turbo Mount benzeri bir özellik olup olmadığını merak ediyor

  • Bunun Hotwire/Turbo kullanmanın en iyi yollarından biri olduğunu düşünüyor

• morphdom’un beklenmedik şekilde bazı öğelerin üzerine yazması sorununu daha fazla öğrenmek istiyor

  • Input elemanlarının ve detail elemanlarının durumunu korumak, morphdom gibi kütüphanelerin temel işlevlerinden biri