Gumroad neden htmx'i seçmedi

 (htmx.org)
6 puan yazan GN⁺ 2024-10-04 | 1 yorum | WhatsApp'ta paylaş
  • Gumroad, yeni projesi Helper için hafif bir frontend beklentisiyle htmx'i değerlendirdi, ancak karmaşık UX gereksinimleri büyüdükçe React/Next.js'e geçti
  • Basit etkileşimlerde htmx umut vericiydi, ancak dinamik doğrulama ve koşullu alanlar içeren formlarda sunucu tarafı mantığı uzayıp geliştirme akışı doğallığını kaybetti
  • İş akışı oluşturucudaki sürükle-bırak, gerçek zamanlı iş birliği, karmaşık durum yönetimi ve dinamik form üretimi React ekosistemi ve bileşen modeliyle daha doğrudan hayata geçirildi
  • Sorun çözme kaynakları ve yapay zeka araç desteği Next.js ve React tarafında daha zengindi; htmx ise açık kaynak eğitim verisi eksikliği nedeniyle geliştirme hızında dezavantajlı kaldı
  • htmx, mevcut sunucu tarafında render edilen uygulamalar veya basit etkileşim modelleri için uygun olabilir, ancak Helper gibi durum yoğun arayüzlerde React ve Next.js daha iyi uydu

Helper'da htmx'i değerlendirme arka planı

  • Gumroad, yeni proje Helper'ı başlatırken htmx adlı frontend adayını değerlendirdi
  • İlk beklenti, React'in gereğinden fazla ağır olduğu yönündeki önceki deneyimlerden doğdu ve htmx'in basit etkileşimleri hafif biçimde eklemenin bir yolu olabileceği düşünüldü
  • Ekip içinde htmx'in, giderek karmaşıklaşan JavaScript ekosistemini hicveden bir meme'e benzediği yönünde değerlendirmeler de vardı
    • Tailwind nasıl satır içi CSS'in farklı bir sözdizimi gibi görünüyorsa, htmx de satır içi JavaScript'in farklı bir sözdizimine daha yakın görülüyordu
  • Tailwind, Gumroad'un araç setine yerleşti, ancak htmx Helper'ın amacına uygun şekilde ölçeklenmedi ve müşteriler için en iyi kullanıcı deneyimine dönüşmedi

React/Next.js'in daha doğal geldiği noktalar

  • Geliştirici deneyimi ve form işleme

    • htmx ile de doğru bir uygulama mümkündü, ancak Gumroad, Next.js'te özellikleri çalışır hale getirme sürecini daha sezgisel buldu
    • Dinamik doğrulama ve koşullu alanlar içeren karmaşık formlarda React'in istemci tarafı yaklaşımı daha basitti; htmx'te ise sunucu tarafı mantığı uzuyordu

  • UX ve etkileşim kısıtları

    • htmx, uygulamayı Rails/CRUD tarzına doğru itme eğiliminde olduğundan, varsayılan deneyim kolayca sıradan veya genel bir yapıya dönüşebiliyordu
    • İş akışı oluşturucunun sürükle-bırak arayüzü, htmx'te dolaylı çözümler gerektiriyordu ve React kütüphaneleriyle elde edilen akıcı deneyime kıyasla daha kaba hissettiriyordu

  • Yapay zeka araçları ve sorun çözme hızı

    • Yapay zeka araçları Next.js'e daha aşinaydı, htmx'e ise daha az; bunun nedeni olarak açık kaynak eğitim verisinin azlığı gösterildi
    • React/Next.js tarafındaki kaynak bolluğu sayesinde bir sorun çıktığında çözüm bulma hızı daha yüksekti

  • Karmaşıklık ve ölçeklenebilirlik

    • Proje karmaşıklaştıkça htmx'in sadeliği, avantajdan çok kısıta dönüşmeye başladı
    • Gerçek zamanlı iş birliği ve karmaşık veri görselleştirme eklendikçe, htmx'in sunucu merkezli yaklaşımında birden fazla bileşen arasındaki durumu yönetmek giderek zorlaştı

Helper özelliklerinde ortaya çıkan farklar

  • Sürükle-bırak: React ekosistemindeki react-beautiful-dnd, az ayarla akıcı ve erişilebilir sürükle-bırak deneyimi sunuyor
  • Karmaşık durum yönetimi: Her iş akışı adımının ayarlarını ve koşul mantığını gerçek zamanlı olarak UI'a yansıtmak için useState veya Redux gibi React durum yönetimi yaklaşımları daha doğrudandı
  • Dinamik form üretimi: Adım türüne göre farklı ayar formları oluşturmak ve bunları kullanıcı girdisine göre değiştirmek, React bileşen modelinde daha sezgisel biçimde ele alındı
  • Gerçek zamanlı iş birliği: Birden fazla kullanıcının aynı anda iş akışını düzenlemesi özelliği, WebSockets ve React ile görece doğrudan uygulandı; htmx'te ise daha karmaşık sunucu tarafı mantığı ve özel JavaScript gerekti
  • Performans optimizasyonu: İş akışı büyüyüp karmaşıklaştıkça, React'in virtual DOM'u ve useMemo, useCallback gibi hook'larla render süreci ince ayarlı biçimde optimize edilebildi

Ekosistem ve nihai değerlendirme

  • React/Next.js ekosistemi büyük ve olgun olduğu için Gumroad'un karşılaştığı neredeyse her soruna bir çözüm sundu
  • htmx'te ise çoğu zaman özelliklerden ödün vermek veya bunları baştan kendileri yapmak gerekti; üçüncü taraf hizmet ve kütüphane entegrasyonlarında da React binding'leri varken htmx karşılıkları olmayan durumlar vardı
  • React/Next.js'e geçtikten sonra Gumroad, bunun karmaşık UX inşa etmek için daha uygun bir tercih olduğunu değerlendirdi
    • Daha hızlı hareket edebildiler, daha sürükleyici bir kullanıcı deneyimi oluşturabildiler ve mevcut araçlar ile kütüphanelerden yararlanabildiler
    • Ayrıca Helper'ın temel müşterileri için uygulama kullanıcı deneyimini önemli ölçüde iyileştirebildiler
  • htmx'in sınırları aşılamaz değildi, ancak çözüm süreci htmx'in güçlü yanlarından uzaklaşıp JavaScript merkezli ortamda daha doğal çözümlere yöneltti
  • htmx, basit etkileşim modelleri veya mevcut sunucu tarafında render edilen uygulamalar üzerine kurulu projeler için iyi bir tercih olabilir
  • Helper gibi karmaşık ve durum yoğun arayüzlerde React ve Next.js daha uygundu; Gumroad da ihtiyaçlar değiştikçe ve yeni teknolojiler geldikçe teknoloji yığınını yeniden değerlendirmeye devam edebileceğini düşünüyor

İlgili okumalar

1 yorum

 
GN⁺ 2024-10-04
Hacker News yorumları

  • Başka bir başlıkta yazdığım bir şeydi; Gumroad CEO'su Twitter'da bir projede htmx'i denediğini ama sonunda NextJS'i seçtiğini söylemişti.
    htmx web sitesine koymaya değer, düşünülmüş olumsuz deneyim yazıları arıyordum; deneyimini yazıya dökebilir mi diye sordum, seve seve kabul ettiği için de minnettar oldum.

    • htmx'in her zaman en iyi seçenek olmayabileceği noktaları doğrudan göstermesi, projeye olan saygımı artırıyor.
      Her şey için en iyi çözüm olduğunu iddia eden diğer projelerle karşılaştırınca ferahlatıcı.
      Özellikle sürükle-bırak konusundaki eleştiriyi merak ediyorum; htmx'te gerçekten zor mu görüyorlar, öyleyse bunu çözme planları var mı?
    • Gumroad CEO'su Rails'in kendisinin de teknik borç olduğunu söyledi; nedenini sorunca da sadece React'in çok daha iyi olduğunu yanıtladı.
      Rails ile React birlikte kullanılamazmış gibi söylemiş oldu.
      Yazının kendisi htmx'e dair olumsuz bir deneyimden ziyade, sürükle-bırak ve gerçek zamanlı iş birliği devreye girdiği anda en başta htmx'i deneme tercihinin yanlış olabileceğini düşündürüyor.
      Ekran görüntüsünün neyi göstermeye çalıştığını da pek anlamıyorum ama yine de htmx web sitesine koymak için iyi bir yazı olduğunu düşünüyorum.
    • htmx'in başka araçlara göre daha az uygun olabileceği noktaları göstermek saygı duyulası.
      Benim için htmx, React'in yerine geçecek bir şey olmaktan çok jQuery'nin yerine geçecek bir şeye daha yakın.
      htmx ve jQuery belgeye etkileşim ekler; React ise belgenin tamamı olmaya çalışır.
      Araç işe göre değişmeli.
    • Bağlantısı verilen yazıyı ve https://htmx.org/essays/htmx-sucks/ yazısını gördükten sonra htmx kullanmamaya veya başkalarına önermemeye karar verdim.
    • Diğer başlık https://news.ycombinator.com/item?id=41727315.

  • “Yapay zeka ve araç desteği: Yapay zeka araçlarının Next.js'e çok aşina olduğu, ama htmx'e o kadar aşina olmadığı da worth noting” kısmı sakin bir şekilde dezavantaj gibi yazılmış ama geliştirme araçları, kütüphaneler, framework'ler ve dillerin geleceği açısından oldukça ürpertici bir işaret.
    Tahminimce büyük dil modelleri, mevcut kazanan-hepsini-alır ve ilk giren avantajı etkilerini daha da büyütecek; daha fazla ve daha iyi eğitim verisi sayesinde açık kaynak araçların kullanımını da daha fazla teşvik edecek.

    • Yapay zeka ve araç desteği meselesi aslında topluluk ve ekosistem meselesinin bir uzantısı.
      Büyük dil modellerinden önce de React'in, soruların çoğunun StackOverflow'da zaten yanıtlanmış olması ve neredeyse her kullanım için olgun bir kütüphanenin bulunması gibi avantajları vardı.
      Şimdi sadece eskiden StackOverflow'a sorulacak soruları büyük dil modellerine soran insanlar ortaya çıktı; sonuç aynı.
      Başkalarının çok kullandığı şeyi kullanırsanız avantaj elde edersiniz.
    • Büyük dil modellerinin geliştirme araçlarında kazanan-hepsini-alır ve ilk giren avantajı etkilerini büyütmesi, kod yazmayı büyük dil modellerine emanet eden kişiler için doğru olacaktır.
      Ancak yazılım mühendisi kariyerinin uzun vadeli stratejisi olarak bunun pek iyi bir bahis olmadığını güçlü biçimde düşünüyorum.
    • Yapay zeka araçları belirli bir zamana hapsolmuş durumda; yeni materyalle eğitseniz bile öğrenebilecekleri bilgi miktarının bir sınırı var.
      Hatta bunun iyi bir şey olabileceğini bile düşündüm.
      Yazılım sektörü en yeni araçların, dil özelliklerinin ve framework'lerin peşinden koşmaya çok fazla zaman harcıyor.
      Biraz durgunlaşıp her 6 ayda bir yeni bir çekiç yapmak yerine elimizdeki araçlarla işi bitirmeye yönelmek olumlu olabilir.
    • Bir geliştirici, kendi kodunu onun yerine yazacak bir şey olmadan çalışamıyorsa, en başta neden işe alındığını bilmiyorum.
    • Bu konuda fazla endişelenmiyorum; Gumroad'un kaygısı da abartılmış olabilir.
      Gerçekten yapay zekanın HTMX'i iyi kullanamadığı bir deneyim mi yaşadılar, yoksa yorumda başka kaynak eksikliği konusuna mı geçildi, buradan anlamak mümkün değil.
      Büyük dil modelleri çoğu zaman genel amaçlı çevirmenler gibi çok iyi çalışır.
      Popüler framework'lerdeki genel kalıpları ve kavramları öğrenip daha küçük bir framework'ün söz dizimini bir ölçüde bildiklerinde, deneyimime göre oldukça iyi niş framework kodu da üretebiliyorlar.
      Bu, korsanların eğitim verisinde hiç konuşmadığı konuları bile korsan ağzıyla anlatabilmesine benziyor.

  • “Dinamik doğrulama ve koşullu alanlar içeren karmaşık formlar oluştururken, React'te basit bir istemci tarafı işi olacak şeyi yapmak için karmaşık sunucu tarafı mantık yazmak zorunda kaldık” kısmını görünce aklıma Anakin Padme mimi geliyor.
    “Yine de sunucu tarafı doğrulamayı da uyguluyorsunuz, değil mi… değil mi?”

    • Bir web formu kâğıt formdan daha karmaşıksa, bence o web formunun kendisini yeniden düşünmek gerekmez mi?
      React'te kolay ama htmx'te zor olan formlar, React tarzı global uygulama durumunu araya sokup işi bir kütüphaneyle %90 bitirmek istenen durumlar dışında pek aklıma gelmiyor.
    • Sunucuda da doğrulama yapılıyor.
      Sadece her sayfada değil, gönderim sırasında bir kez yapılıyor.

  • “Frontend'i çok hafif tutmak için htmx'in iyi bir çözüm olabileceğini düşündük” sözünün aksine, hafif frontend'den vazgeçtikleri anda htmx uygun olmaktan çıkmış gibi görünüyor.
    Karmaşık UI/UX ve durum yönetimini render etmek için üçüncü taraf kütüphaneler kullanmaya başlamışlar.
    Ayrıca “React'te X'i yapmak daha kolaydı” demek, bunu üçüncü taraf bir kütüphaneyle yaptılarsa adil bir karşılaştırma değil.
    Biri sizin yerinize yaptığı için sizin doğrudan yapmanız gerekmemiş sadece.
    Yazıya büyük ölçüde katılıyorum ama karmaşık durum ve render ihtiyacı olduğunu biliyorlarsa htmx'in baştan iyi bir çözüm olmadığını düşünüyorum.

    • Bence tam olarak böyle.
      htmx'i seviyorum ama bu yazı, yazarın teknik anlayışının epey eksik olduğunu gösteriyor.
      Web platformunu ve htmx.org belgelerini biraz bilince ortaya çıkacak artılar-eksilerden ziyade, havayı görüp HTMX'i denemek istemiş gibi duruyor.
    • En başta React kullanmaması gereken insanların “React uygulamasını htmx'e çevirince her şey çok daha iyi oldu” diye yazılar yazmasıyla güzel bir simetri oluşturuyor.
    • htmx ile JavaScript karşıtlığı bana behave'in davranış odaklı geliştirme testleriyle pytest testlerini hatırlatıyor.
      Gherkin dili basit durumlarda iyi görünür ve ilke olarak karmaşık durumlara da genişletilebilir; ama ne kadar çok soyutlama katmanını yönetmeniz gerekirse, saf Python olan pytest o kadar daha rahat hale gelir.
    • Ben de aynısını düşündüm.
      Projenin kapsamı hiç de “basit” değildi; benim durumumda doğrudan React'e giderdim.
    • İstenen özellik açıklamasına bakınca bile ağır JavaScript gerekeceği kaçınılmaz görünüyordu.

  • “İş akışı oluşturucu için sürükle-bırak arayüzünü uygulamak htmx’te büyük bir zorluktu; React kütüphaneleriyle elde edilebilen akıcı deneyime kıyasla hantal geçici çözümler gerekiyordu” kısmına gelince, HTMX, ön uç bundle’ı yalnızca gerektiği kadar yaptığınızda ve daha fazlasını yapmadığınızda daha iyi çalışır.
    htmx.onLoad olayına bağlanıp, yüklenen içeriğin içinde özellik eklenmiş markup’ı — örneğin columns, cards, tasks vb. — bulup iliştirmek yeterli.
    Örneğin, render edilmiş markup’a sortable.js bağlayabilir ve sortable olaylarını HTMX üzerinden durum güncellemelerine bağlayabilirsiniz.
    Oldukça basit ve dokümantasyonda tam olarak buna dair bir örnek var: https://htmx.org/docs/#3rd-party

    • HTMX’i UIKit bileşenleriyle birlikte kullanıyorum.
      Modern, durum tutan ve dinamik web siteleri HTMX ile hiç de uyumsuz değil.

  • Yazıyı okuyunca ekip, arka uç geliştirmeden çok ön uç geliştirmeye daha alışkın görünüyor.
    Eski usul bir geliştiricinin bakış açısından, ön uç geliştiricilerin düşünme biçiminde bazen küçük bir korku ve yanlış anlama görülebiliyor.
    Açıkçası bu yaklaşımın nasıl çalıştığını anlamak için düşünme biçimini biraz ayarlamanın yeterli olduğunu düşünüyorum; ama birçok kişinin kariyeri boyunca genel istemci/sunucu yaklaşımını hiç görmemiş olmasını da anlıyorum.
    Yine de hazır React bileşenlerinin değerini ve dokümantasyon ile yardım bulmanın kolay olmasını göz ardı edemeyiz.

    • Yalnızca geliştiricilerin değil, UX tasarımcılarının da React gibi düşünmesinin htmx’i benimsemenin önündeki en büyük engel olduğunu düşünüyorum.
      Bir nesil tasarımcı, mobil ile web’i birbirine çok benzer tasarladı ve uygulama karmaşıklığını geliştiricilerin üzerine attı.
      Oysa web, mümkün olduğunca mobilden farklı olmalı ve farklı olabilir.
      Yazıda, bir CRUD uygulaması gibi tasarımın fazla “generic” olduğu söyleniyor; ama bu gerçekten kötü mü?
      Her sitede öngörülebilir bir kullanıcı deneyimi yaratmayı mümkün kılan, yaygın olarak benimsenmiş bir belge modeli gibi büyük bir başarı var; biz ise bunu yalnızca “sıkıcı” olarak görüyoruz.
      Sıkıcılığın kendi başına özünde sorunlu olduğunu varsayıyoruz.
      Mobil uygulama gibi hissettiren, benzersiz ve markalaştırılmış deneyimler talep eden piyasa baskısını anlıyorum; ama tasarımcılar React tarzı düşünce kadar WWW tarzı düşünceye de sahip olabilseydi nasıl olurdu diye düşünmeden edemiyorum.

  • HTMX’in bu yazıyı ve benzerlerini kendi sitesinde yayımlaması hoşuma gidiyor.
    Yalnızca HTMX’in iyi uymadığına dair epey makul neden var gibi görünüyor.
    Ön uç uzmanı değilim ama birkaç düşüncem var.
    Birincisi, zaten arka uçta da form doğrulaması yapmak gerekmiyor mu?
    Arka uç sisteminin sonucu ön uca iletmesinin neden bu kadar zor olduğunu merak ediyorum.
    Çoğu durumda form doğrulamasını hem ön uçta hem arka uçta yapmak için iyi nedenler vardır; böyle durumlarda yalnızca HTMX yetersiz kalır, ama bu sorunun ifade edilişi biraz kafa karıştırıcı.
    İkincisi, yalnızca HTMX kullanınca uygulama bir ölçüde bu yöne itilebilir ve bazı durumlarda bu iyi bir şeydir; fakat onlar müşterileri için farklı bir yaklaşım gerektiğine karar vermiş gibi görünüyor.
    Üçüncüsü, yapay zeka araçlarına bağımlılığın ana sorun olacak kadar bu ekibin yapay zeka araçlarını nasıl kullandığını daha çok öğrenmek isterdim.
    Gelecekte yapay zeka geliştirme araçları önem kazanırsa, yeni bir framework’ün ya da programlama dilinin benimsenebilmesi için yeterli araç ve entegrasyona sahip olma çıtasının çok yükselip yükselmeyeceği de ilginç bir soru.
    Dördüncüsü, HTMX’e yönelik yaygın bir şikâyet gibi, bazı projeler HTMX’in sunduğundan fazlasını ister.
    Beşincisi, Django ve Python’ı sevmemin nedenlerinden biri de derin topluluk, entegrasyon ve eklenti ekosistemidir.
    Kavram olarak benzer ama HTMX’ten daha fazla özellik sunan https://unpoly.com/ gibi bir şey onlar için daha uygun olabilirdi.

  • “Next.js’in geliştirme süreci doğal hissettirdi” sözüne gelince, bu ReactJS sözdiziminin hangi kısmı doğal, bilmiyorum.
    Alışıldık olabilir ama doğal değil.
    useEffect(() => { const timer = setInterval(() => { setCount((prevCount) => prevCount + 1); }, 1000); return () => clearInterval(timer); }, []);

    • Bildiğim kadarıyla HTMX’te zamanlayıcılar ve interval’lar için zarif bir çözüm yok.
      Sonunda bunu JavaScript ile beceriksizce bağlamak gerekecektir.
    • Bu kod örneği oldukça cömert sayılır.
      Değişken timeout’a sahip özel bir hook istiyorsanız çok daha karmaşık hale gelebilir.
      Dan de bu konuda uzun bir yazı yazmak zorunda kalmıştı: https://overreacted.io/making-setinterval-declarative-with-r...
    • Bu kullanım senaryosunda doğal görünen kodun ne olduğunu merak ediyorum.
      Kodu yazabilir misiniz?

  • htmx.org’un bu yazıyı barındırması takdire değer.

    • Bir hizmet ya da aracın yalnızca neden kullanılması gerektiğini değil, neden kullanılmaması gerektiğini de açıklaması bence gerçekten değerli.
    • Böyle bir yazıyı yayımlamak gerçekten alçakgönüllü ve dürüst bir tutum.
      Sonuçta biri htmx’i alıp kendi ihtiyaçlarını karşılamadığını düşünerek sinirlenirse artık işaret edilebilecek bir kaynak da var.
    • https://htmx.org/essays/ sayfasında “On The Other Hand…” altında bağlantılanmış.
    • Başta biraz rant ya da iğneleyici bir yazı bekliyordum; ama gerçekte iyi noktalara sahip iyi bir yazı olduğu için sevindim.
      Kendi projelerimden birkaçında htmx kullanıyorum ve oldukça iyi oldu.
      Böyle yazılar, htmx’in nerede iyi olduğunu ve nerede eksik kaldığını nadiren gösterdiği için, aslında htmx kullanma konusunda bana daha çok güven veriyor.

  • Üçüncü nokta ürkütücü geliyor.
    Şirketlerin kendi framework’lerinin model eğitim setlerinde aşırı temsil edilmesi için para ödediği ve bunun üzerinden sözleşme sattığı bir dünya hayal ettiriyor.
    Arama motoru optimizasyonunun geliştirme araçlarının içine baked in edilmiş hâli gibi.