- htmx, ilk GitHub Open Source Accelerator programına seçildi ve olgun açık kaynak projeleriyle iş birliği yapıp onlardan öğrenme fırsatı elde etti
- Bu katılım, hypermedia ve htmx yaklaşımını daha geniş geliştirici topluluğuna tanıtmak için bir fırsat sunuyor
- htmx, Accelerator süresini htmx 2.0 çalışmalarına başlamak için kullanmayı planlıyor
- Projeyi sürdürmek ve geliştirmeye devam edebilmek için htmx üzerindeki çalışmayı tam zamanlı bir işe dönüştürmenin yollarını öğrenmek de önemli bir görev olmaya devam ediyor
- Birlikte seçilen projeler; güvenlik, dokümantasyon, kimlik doğrulama, bildirimler, CMS ve daha birçok farklı açık kaynak alanını kapsayarak GitHub Accelerator'ın kapsamını gösteriyor
htmx'in elde ettiği fırsat
- htmx, ilk GitHub Open Source Accelerator dönemine seçildi
- Bu seçim sayesinde başarılı açık kaynak geliştiricileri ve projeleriyle öğrenme ve iş birliği yapma imkanı buldu
- htmx, bu süreç aracılığıyla hypermedia ve htmx'i daha geniş kitlelere tanıtabileceğine inanıyor
- Accelerator'a katılım süresindeki başlıca iki hedef şunlar
- htmx 2.0 çalışmalarına başlamak
- htmx üzerindeki çalışmayı tam zamanlı bir işe dönüştürmenin yollarını öğrenmek
Birlikte seçilen açık kaynak projeleri
- BoxyHQ: Güvenlik ve gizlilik için API ürünleri sunan bir paket; mühendislik ekiplerinin mevzuata uyumlu bulut uygulamalarını daha hızlı geliştirmesine ve dağıtmasına yardımcı oluyor
- Cal.com: E-postayla tekrar tekrar yazışmadan toplantı planlamaya yardımcı olan bir takvim aracı
- Crowd.dev: Topluluk, ürün ve müşteri verilerini merkezileştirerek hangi şirketlerin açık kaynak projelere katıldığını anlamaya yardımcı oluyor
- Documenso: Açık kaynaklı bir DocuSign alternatifi; self-hosting ve iç işleyişin incelenebilir olması sayesinde güven kazanmayı hedefliyor
- Erxes: Açık kaynaklı bir HubSpot alternatifi; tek bir XOS üzerinden farklı iş türlerine uygun deneyimler oluşturabiliyor
- Formbricks: Kullanıcı yolculuğunun herhangi bir noktasında ayrıntılı kullanıcı gruplarına anket göndermeyi sağlıyor; hedefli mikro anketlerle 6 kata kadar daha fazla içgörü toplanabiliyor
- Forward Email: Özel alan adları için ücretsiz bir e-posta yönlendirme hizmeti; 6 yılı aşkın süredir içerik üreticileri, geliştiriciler ve şirketler tarafından kullanılıyor
- GitWonk: Geliştirici deneyimine odaklanarak tasarlanmış ve geliştirilmiş açık kaynak teknik dokümantasyon aracı
- Hanko: Passkey çağı için açık kaynak kimlik doğrulama ve kullanıcı yönetimi aracı; web ve mobil uygulamalara dakikalar içinde entegre edilebiliyor
- Infisical: Ekipler, cihazlar ve altyapı genelinde sırları ve yapılandırmaları güvenli şekilde yöneten açık kaynak uçtan uca şifreli platform
- Novu: Geliştiriciler için açık kaynak bildirim altyapısı; tüm iletişim kanallarını tek yerden yönetmeye yönelik bileşenler ve API'ler sunuyor
- OpenBB: Açık kaynak finans ekosistemi aracılığıyla yatırım araştırmasını demokratikleştiriyor; OpenBB Terminal ile her yerden yatırım araştırması yapılabiliyor
- Sniffnet: İnternet trafiğini kolayca izlemeye yardımcı olan bir ağ izleme aracı
- Typebot: Benzersiz sohbet deneyimleri oluşturmak için bloklar sunuyor; uygulamanın herhangi bir yerine gömülerek sonuç toplanabiliyor
- Webiny: Veri sahipliği, genişletilebilirlik ve özelleştirmeyi vurgulayan açık kaynak kurumsal düzeyde sunucusuz CMS
- Webstudio: Webflow'a açık kaynak bir alternatif olarak seçildi
1 yorum
Hacker News yorumları
Merhaba, çoğunuzun bildiği gibi htmx’i yapan kişiyim ve ilgili soruları yanıtlayabilirim
htmx, fireship dev’in videosu (https://www.youtube.com/watch?v=r-GSGH2RxJs) ve popüler Twitch yayıncısı ThePrimeagen’in video serisi sayesinde epey popülerlik kazandı
HN okurları için htmx ve genel olarak hipermedya üzerine yazdığım yazıların derlemesi https://htmx.org/essays ilgi çekici olabilir; ayrıca birkaç yazarla birlikte kısa süre önce yayımladığımız hipermedya, htmx ve mobil hipermedya Hyperview hakkındaki kitap https://hypermedia.systems da göz atmaya değer
Elbette ben bir htmx hayranıyım, ama daha derindeki özün hipermedya olduğunu düşünüyorum. Günlük geliştirme işlerinizde htmx kullanmayı planlamasanız bile keşfetmeye değer bir kavram
37signals’ın Hotwire’ı veya htmx’ten sonra en sevdiğim https://unpoly.com gibi pek çok harika hipermedya odaklı kütüphane de var
Birçok Django geliştiricisi için büyük fayda sağlıyor
Birkaç ay önce makale beğenme özelliği yaparken, htmx’ten önce jQuery ile bir JSON API sunucusunu çağırıp beğeni sayısını güncellemem gerekiyordu; HTMX kullanınca ise Django mantığıyla birlikte düz HTML yazıyormuşum gibi hissettirdi
Şimdiye kadar keşfettiklerimin en iyileri arasında ve form işleme de çok kolay. HTMX hem kullanıcı deneyimini hem geliştirici deneyimini ciddi biçimde iyileştiriyor
Çok popüler projelerde bile genelde kodun büyük kısmını mevcut katkıcıların üstlendiğini düşünürsek bu güçlü bir büyüme sinyali
https://devboard.gitsense.com/bigskysoftware/htmx
Bu arada bu benim yaptığım bir araç
Web sitesine ve örneklere biraz baktığımda, sunucunun HTTP yanıtının tam markup içerdiği ve istemci durumunun buna göre güncellendiği bir yaklaşım, yani DOM’u yeniden yazmaya ağırlık veren bir model gibi görünüyor
htmx’in yalnızca istemci taraflı trigger’lar veya istemci tarafından üretilen içerik için de esneklik sağlayıp sağlamadığını merak ediyorum
Bugünün JavaScript merkezli istemci framework’lerinin avantajı, mümkün olduğunca çok işi tarayıcıya devrederek sunucunun veri ve CPU kullanımını azaltabilmeleri. Web ölçeğindeki uygulamalarda bu büyük fark yaratır
HTMX’in bu tür mühendislik hedeflerini de karşılayıp karşılayamayacağını, yoksa tamamen farklı amaçlara sahip bir proje mi olduğunu merak ediyorum. Facebook gibi istemcilerin hipermedya odaklı olmadığını anlıyorum, ama yine de karşılaştırmadan kaçmak zor olacaktır
Doğal, kendini belgeleyen bir yapıda ve iyi tasarlanmış. Gerçekten HTML’in doğal bir uzantısı gibi hissettiriyor
Bana göre htmx’te eksik olan tek parça bileşen modeli; böyle bir şey arayanlar için Astro[1] ile çok iyi uyum sağlayacak gibi görünüyor. Astro, Vue veya React benzeri çalışma zamanı yükü olmadan HTML bileşenleri tanımlayıp kullanmanızı sağlıyor
[1] http://astro.build
Htmx bana Tailwind’i hatırlatıyor. Çünkü çalışma zamanında tek bir kütüphanenin okuyup yorumladığı özellik adları ve değerleri yaratmış oluyor
Frontend build’e ihtiyaç olmaması, npm ve webpack’e dokunmak istemeyen ve buna ihtiyaç duymayan çoğu geliştirici için çok büyük bir avantaj
Sayfa boyutu açısından sınır, küçük bir tek sayfa uygulaması civarı gibi görünüyor; çok büyürse başka bir tek sayfa uygulamasına bölünebilir gibi
React/Vue geliştiricilerinin özellikle eksikliğini hissedeceği şey, global durumu temsil eden tek bir nesne olması ve bunun bileşen kod tabanında hiyerarşik olarak tanımlanmış tek bir fonksiyon tarafından UI’a render edilmesi bakış açısı olacaktır
Ancak bu bakış açısının kendisi de ağır bir yük getiriyor, çok fazla görüş ayrılığı ve duygusal yıpranma doğuruyor; üstüne frontend build süreci ve onun kafa karıştırıcı varyasyonları da geliyor
Henüz kullanmıyorum ama şimdiden büyük hayranıyım
İyi haber
Son 1 yıldır htmx kullanıyorum; iyi sonuçlar ve tatmin edici deneyimler elde ettim, özellikle Clojure’da hiccup ile sunucu tarafı render ederken harikaydı
htmx bir kez anlaşıldığında ne kadar basit ve esnek olduğu neredeyse şaşırtıyor. HTML’in hipermedya olarak neden bu yönde evrilmediğine inanmak zor
Web geliştirmenin aslında böyle evrilmesi gerektiği çok netleşiyor. Umarım bir gün htmx’in JavaScript ile yaptığı işler doğrudan HTML’e ve tarayıcı istemcisine yerleşir
htmx’i Angular’ın bir türevi gibi yanlış görüyorsanız ya da hipermedya mimarisini geliştirmesinin anlamını kavramıyorsanız, sitedeki harika yazıları mutlaka okumanızı öneririm. O zaman REST’in ne olduğunu ve gerçek HATEOAS’ın neden önemli olduğunu anlarsınız: https://htmx.org/essays/
Ücretsiz bir kitap da var: https://hypermedia.systems/
10-15 yıl önce, erken web’in yeni ve güçlü fikri olan hipermedyayı genişletip zenginleştirmek yerine, JSON API mimarisiyle web’in üzerine kalın istemcileri yeniden inşa etmeye çalışarak maliyetli, yanlış bir yola girdik
htmx’in var olmasına ve birçok kişiye iyi uymasına seviniyorum, ama benim işimde çoğu zaman en iyi seçenek olmadı. Yine de sorun değil
Web’in farklı şekillerde büyüyebilmiş olması harika; web’in mutlaka tek bir yönde evrilmiş olması gerektiğini düşünmemize gerek yok
Son yaklaşık 10 yılda web geliştirmenin en büyük hatası, tek doğru cevabın olması gerektiği düşüncesiydi
İster sıradaki Gmail’i ister statik bir blog yapın, sektörün kargo-kült yaklaşımı her şeyin aynı şekilde yapılması gerektiğini söylüyor; ama sağduyu bunun böyle olmadığını gösteriyor
Web’in %98’inden fazlası için yeterli olacaktır. Kalan %1,9 için küçük bir JavaScript kütüphanesi kullanılabilir
Geriye kalan %0,1 ise saf JavaScript web uygulamalarıdır
HTML’e biraz öznitelik serpiştirerek kolay durumları dinamik hale getirmek gibi aynı fikir gibi görünüyor
Angular 1, Vue vb. birçok framework böyle başladı; belli bir popülerlik kazandıktan sonra da daha zor senaryolara yönelik gerçek talep nedeniyle tam teşekküllü tek sayfa uygulama framework’lerine dönüştüler
“Angular 1 gibi” bir framework seçecek olsam, sınırlarını net biçimde belgelendiren ve o sınırları aşmak gerektiğinde olgun bir tek sayfa uygulama framework’üne geçiş yolunu açıkça sunan birini seçerdim. Böyle bir framework bilen varsa paylaşsın lütfen
Ben HTMX “havalı olmadan önce” hayranıydım.
Son dönemde gördüğü ilgi ve başarı beni çok sevindiriyor; web’in 2013’te icat edildiğine ve o şehri kendilerinin kurduğuna inanan frontend tarafının şakayla karışık alaylarını ve tepkilerini de epey keyifle izliyorum.
Backbone.js döneminden beri bir önyargım vardı; o zaman da acının bir kısmını anlıyordum ama bir ölçüde şüpheciydim.
Sonra React çıktı ve genç, enerjik insanlar 5 sayfalık son derece basit web sitelerini frontend framework’lerinden oluşan Rube Goldberg makinelerine dönüştürmeye başlayınca, ben teknoloji fişlerimi bozdurup bu işlere bulaşmadım.
Uygulama ayrıntıları oldukça farklıydı ama hipermedya tabanlı uygulama fikri yaptığımız her şeyin merkezindeydi.
Ne yazık ki uzun vadede insanların gönlünü kazanamadı; blog güdümlü geliştirme, yani cargo cult, çabalarımızın yerini aldı.
Şimdi HTMX’in popülerliğinin arttığını görmek bir ölçüde telafi edilmiş gibi hissettiriyor. Bu kavramlarla düşünenlerin sadece biz olmadığını görmek güzel.
Elbette kavram güçlü idiyse bu benim uygulamada eksik kaldığım anlamına da gelebilir; o yüzden belki de fazla sevinmemeliyim.
Bir grubun gitarlarını satıp turntable aldığını da duydum.
HTTP endpoint’lerini JSON döndürecek şekilde yeniden yazdıklarını ve bunun REST olduğunu da duydum.
Bir grubun turntable’larını satıp gitar aldığını da duydum.
HTTP endpoint’lerini şablon HTML parçaları döndürecek şekilde yeniden yazdıklarını ve bunun HATEOAS olduğunu da duydum.
Ben de hissimi kaybedip, geri kazanıp, kaybedip, geri kazanıyorum.
Yalnız Backbone biraz gevşekti; Angular çıkana kadar da pek kurumsal görünmüyordu.
Her hâlükârda bu web uygulaması akımının çevremde popülerleşmesinin nedeni, backend ile frontend’i ayırması ve tek bir backend’in, genellikle REST/JSON’un, mobil ve web istemcilerini ayrı ayrı besleyebilmesiydi.
Tek sayfa uygulamalar yapmamızın nedeni buydu, ama şimdi yeniden unutulmuş gibi görünüyor.
Benim dünyamda, giriş ekranının arkasındaki uygulamalar için mantıklıydı. Ama “onlar” web mağazaları gibi internete açık siteleri de tek sayfa uygulama yapmak istiyordu.
Bunu da anlıyorum. Gatsby ile birkaç web sitesi yaptım; gezinme inanılmaz hızlıyken arama motorları tarafından da indeksleniyor.
Ancak bazı durumlarda işler giderek daha karmaşıklaştı ve sunucu tarafı React gibi şeyler bile çıktı. Neyse ki benim ona dokunmam gerekmedi.
Öte yandan htmx’in, daha genel olarak da hipermedyanın bir araç olarak benimsenmesini istiyorum. Faydalı ama sonuçta sadece bir araç.
Bir süredir hipermedyayı derinlemesine düşünmemiş frontend insanları tarafından da böyle kabul edilmesini umarım.
İki yaklaşımı birbirini dışlayan şeyler olarak görmüyorum; Rich Harris’in Transitional web uygulamaları kavramına, yani iki yaklaşımı karıştırma fikrine katılıyorum.
Sadece hipermedyayı bırakıp daha gelişmiş istemci tarafı yaklaşıma geçilecek çizgiyi ben ondan farklı bir yere çekiyorum.
Ben kesinlikle öyle düşünüyorum.
1996'da Perl ile başladım; PHP, jQuery, Drupal, Backbone, Node, Angular, ClojureScript, React, GraphQL ve NextJS'e kadar neredeyse tüm akımlardan geçtim.
Htmx bu akıştan ayrılan bir dal gibi geliyor ve üzerinde düşünmeye değer.
Htmx iyi bir soru soruyor: “İşinizdeki karmaşıklık özünde sunucuda mı, istemcide mi?”
Çoğu web sitesinde karmaşıklık özünde sunucudadır. Çoğumuz Figma ya da Google Sheets yapmıyoruz. Birçok web sitesi, etkileşimi yoğun olsa bile, güzel görünümlü arayüzlere sahip CRUD uygulamalarından ibaret.
NextJS gibi framework'ler, aşırı karmaşık istemci sorununu düzeltmek için React'i sunucuya taşımaya çalışıyor; ancak çoğu zaman karmaşıklığı azaltmak yerine artırıyor.
O halde React'i stack'ten çıkarmak daha doğru olmaz mı? Karmaşık bir istemci söz konusuysa DOM ve JavaScript'i pas geçip canvas ve derlenmiş WebAssembly kullanabilirsiniz. Karmaşık bir sunucu söz konusuysa sunucu yönlendirmeli, ince taneli DOM güncellemeleri kullanabilirsiniz.
Bu yaklaşımda görünen sorun şu: Web sitelerinin karmaşıklığı çoğunlukla sunucuda olsa da, neredeyse her zaman istemcide olması gereken birkaç yüksek karmaşıklıklı iş vardır. Görsel düzenleme, gerçek zamanlı sıralama/filtreleme/hesaplama, sürükleme ve dokunma jestleri gibi.
Hibrit bir yaklaşım gerekiyor. Sadece uyumlu olmak yetmez. htmx ve React aynı web sayfasında kullanılabilir, ama birbirlerinden izole edilmeleri gerekir. Benim istediğim izolasyon değil, temelden entegrasyon.
İdeal framework, DOM için reaktif ve ince taneli güncellemeleri desteklerken, karmaşık istemci işlerini üstlenen derlenmiş WebAssembly ile de sıkı biçimde entegre olmalı.
Tüm kodu JavaScript olmayan, güçlü bir dilde yazmak istiyorum. Debugger hem sunucuyu hem istemciyi ele almalı ve ikisi arasındaki fark ortadan kalkmalı. Gerçek full-stack geliştirme, yani tek stack uygulaması olmalı.
Clojure + ClojureScript tek stack uygulamasına yakın görünüyor, ama bu sadece yüzeysel.
Common Lisp için öldürücü bir framework çıkarsa, tek stack uygulaması tam yerine oturacak gibi.
Hibrit yaklaşım, Astro'nun savunduğu islands yaklaşımıdır: https://docs.astro.build/en/concepts/islands/
Bu yaklaşım htmx ve benzerleriyle iyi uyum sağlıyor; biz de htmx projesinde etkileşim gereken kısımlarda basit vanilla JavaScript eşliğinde kullanıyoruz.
Küçük ve orta ölçekli projeler ile küçük ekipler için bu kadarı yeterli olabilir. Geliştirici araçlarını açıp sayfanın bir bölümünü işaret ettiğinizde, yalnızca HTML'e ve küçük JS parçalarına bakarak o kısmın tamamını anlayabilmek gerçekten ferahlatıcı.
Sunucu da olsa istemci de olsa C# ile aynı şekilde kod yazıyorsunuz. İlk sayfa yüklemesinde her şey sunucu tarafında render ediliyor; ardından WebAssembly kademeli olarak devralıyor ve sunucu verisi gerektirmeyen UI etkileşimlerini hızlandırmak için istemciye C# kodu yüklemeye başlıyor.
İyi çalışıyor, ancak şu anki zorluk WebAssembly dosya boyutunu küçültmek. Şimdilik birkaç MB seviyesinde.
https://visualstudiomagazine.com/articles/2023/04/20/blazor-...
Tebrikler. Htmx ile küçük bir proje yapmak eğlenceliydi, ama sonunda openlayers'ı yoğun kullanmam gerektiği için başka bir şey seçtim.
Harita kütüphaneleri istemci tarafı JavaScript'inin ağır olmasıyla ünlüdür ve bu iş için Svelte daha iyi bir araçtı.
İleride Golang projelerinde tekrar kullanmayı planlıyorum ve gelişimini takip edeceğim.
Uygulamanızın basit ya da orta karmaşıklıkta bir frontend'e ihtiyacı varsa, özellikle de hâlihazırda template fragments[0] kullanıyorsanız HTMX'i mutlaka denemenizi öneririm. JavaScript dünyasından gelen biri olarak bile onunla çalışmak oldukça keyifli.
Ayrıca Twitter hesabını[1] yöneten kişi gerçekten çok komik.
[0] https://htmx.org/essays/template-fragments/
[1] https://twitter.com/htmx_org
htmx’i modern web uygulamaları veya siteler geliştirmek için bir araç olarak ciddiye almak zor. Kullanıcıların artık beklediği özellikleri yapmayı imkânsız hâle getiriyormuş gibi geliyor
Örneğin tarihleri önceki·arası·sonrası şeklinde filtreleyen ama filtreleri yalnızca kullanıcı istediğinde gösteren faceted search, sonuç ekranını farklı sütunlara ya da harita ve grafik gibi canvas’a çizilen görünümlere dönüştürme gibi özellikler var
htmx ile bunların bir kısmı yapılabilir ama bir noktada eninde sonunda JSON’a ihtiyaç duyacaksınız
Angular da bunları yapabilir; SolidJS gibi bir şey kullanırsanız bunları geliştirmek gerçekten epey keyifli bile olabilir
JSON API başka uygulamalarda da yeniden kullanılabilir, oysa htmx bana birinin Thymeleaf’i yeniden icat etmiş gibi geliyor
Ben de aynı fikirdeydim; videoda faceted search’ün htmx ile nasıl uygulandığı somut olarak ele alınıyor
İkinci kısmı muhtemelen doğrudan JavaScript yazarak ya da hyperscript ile halledersiniz
Bunun iyi bir yaklaşım olup olmadığını anlamak için gerçekten geliştirip yoğun kullanmak gerekir, ama kesinlikle iyi uyduğu senaryolar da aklıma geliyor
JSON API konusundaki nokta geçerli. Herkese açık bir API gerekiyorsa bu karar sürecine dahil edilmeli. Ama her proje böyle bir kısıta sahip değil
Akıllı telefonların bile bin satırlık tabloda arama yapmakta hiçbir sorunu yok
Böyle durumlarda htmx ile kullanıcıya geniş bir veri aralığı verir, ardından daha ayrıntılı gerçek zamanlı filtrelemeye JS ile izin verirdim
İlk başta görünmeyen verilerin de aranabilir olmasını istiyorsanız bunları gizli bir CSS sınıfıyla birlikte gönderip, arama sonucu bulunduğunda o sınıfı kaldırabilirsiniz
htmx de diğer teknolojiler gibi belirli bir problem kümesine çok iyi uyar. İyi yapamadığı numaraları zorla yaptırmazsanız sorun olmaz
Bu tür şeyler, bir miktar kapsamlı script kullanımını gerektirecek kadar karmaşık; ben de buna başlı başına karşı değilim
https://htmx.org/essays/hypermedia-friendly-scripting/
Kariyerimdeki dönemeçler sayesinde frontend JavaScript framework savaşlarını büyük ölçüde pas geçtim; bu yüzden sıradan eski HTML’in güçlenerek geri döndüğünü görmek hoşuma gidiyor
Bu, graceful degradation açısından bir geri adım
htmx ile yapılmış etkileyici örneklere ihtiyaç olduğunu düşünüyorum. Yeni tür bir web deneyiminin önünü açan “made with htmx” örnekleri olsa iyi olurdu
İnsanlar htmx’i, “ciddi silahları” çıkarmayı gerektirmeyen basit kullanım senaryolarına yönelik diye kalıplaştırdı
Bunda bir ölçüde haklılık var ama sınırlayıcı. htmx ile ilişkili sunucuya geri dönme yaklaşımı, çeşitli nedenlerle daha önce yeterince araştırılamamış ayrı bir kategori
HTMX, backend’e bağlı olmayan bir şekilde eski uygulama kategorilerini yeniden canlandırmakla ilgili
Yeni olan ya da “yeni uygulama kategorisi”ni haklı çıkaracak bir şey yapmıyor
Alışveriş katalogları, forumlar, yönetici frontend’leri, bloglar gibi hypermedia, yani içerik odaklı siteler yapmanın bir yolu
jquery/liveview/turbolinks’e benziyor; ama backend’den bağımsız ve frontend JS mantığını çok az, hatta hiç sürdürmeniz gerekmiyor
Google Docs veya Figma gibi ağır etkileşimler gerektiğinde htmx’in sağladığı avantajlar ciddi ölçüde azalır
https://htmx.org/essays/a-real-world-react-to-htmx-port/
HTMX ve Hyperscript ile yazılmış bir e-ticaret frontend’i
https://www.makaron.cz/
TodoMVC HTMX frontend’i yapılabilir, ama backend’de ne kullanacaksınız? Go, C#, Rust ve birkaç seçenek doğal görünüyor; ama her zaman duruma bağlı
C#’tan bahsetmemin nedeni ASP.Net MVC + Razor’ın HTMX paradigması ile çok temiz uyuyor görünmesi
Bunlarla hiçbir ilgim yok, ama htmx ve daha karmaşık işlevler için biraz JS ile yapılmış
htmx’in açıkça eski güzel yaklaşımı genişletme hedefi taşıdığını düşünürsek, “yeni tür bir web deneyimi” sunup sunamayacağından pek emin değilim
htmx ilk başta iyi görünüyor, ama açılır menü düğmesi gibi normalde JavaScript, ister vanilla ister bir framework olsun, kullanılabilecek bir şey yapmaya çalışınca sonunda hyperscript’i değerlendirmeye başlıyorsunuz
Sonra örneklere bakınca kodun içinde cümleye benzeyen şeyler olduğunu görüp bundan hoşlanmıyor ve başka bir şeye geçiyorsunuz
htmx’i hyperscript olmadan denemek gerekebilir ya da hyperscript’e biraz daha zaman tanımak gerekebilir
Ama birkaç yıl bakımını yapacağınızı düşünüyorsanız fazla yabancı geliyor; ileride bir daha kullanmayacak olursanız ona bağlı kalmak istemezsiniz
htmx tarafı, istemci tarafı etkileşim için hangi aracı kullandığınızı hiç umursamadığından, bu htmx’in faydalı olup olmamasından ayrı bir konu
Kişisel olarak JS build araçlarını vb. dışarıda bırakmaya çalışsaydım htmx + Alpine.js’i seçerdim
Ölçek büyüyüp karmaşıklaştığında bunun altından nasıl kalkılabilir?
htmx kullanan bir uygulamaya yardımcı olmuştum ve iki sorun vardı. Benzer bir deneyimi olan var mı, sorunun teknolojiyi yanlış kullanmaktan mı kaynaklandığını, yoksa bunu çözmeye yönelik bir çalışma yürütülüp yürütülmediğini merak ediyorum
Birincisi, endpoint’in tam sayfa HTML mi döndürmesi gerektiğine yoksa yalnızca htmx’in ihtiyaç duyduğu parçayı mı döndürmesi gerektiğine karar vermek için controller’da çok sayıda özel middleware gerekiyordu
htmx tarafında basit görünüyor, ama muhtemelen htmx kullanan her projenin yeniden yapmak zorunda kaldığı bir kısım
İkincisi,
hx-triggeretrafında kayıt tutma ihtiyacı vardı. UI karmaşıklaştıkça birçok öğenin dış değişikliklere tepki vermesi gerekiyorBir durumu okuyup framework’ün güncellemeyi zamanlamasını beklemek yerine, tepki verilecek event listesini elle yönetmek gerekiyordu
Benzer hisseden var mı?