HN Tanıtımı: Tarayıcıda %100 Uygulanan HTMX Playground
(lassebomh.github.io)- Kurulum veya yerel ayar gerektirmeden doğrudan tarayıcı içinde HTMX denemelerine başlanabilen bir kod sandbox'ıdır
server.jsiçinde endpoint'ler ve şablon render etme ele alınır; HTMX istekleri tarayıcı içindeki sahte sunucu tarafından yakalanır- İstek işleme ve şablon yaklaşımı Django kullanıcılarına tanıdık gelir; HTMX dışındaki kütüphaneleri denemek için de kullanılabilir
- Paylaşım, “Copy as JSON” ile dışa aktarıp Gist raw URL'sini “Load Playground” alanına ekleme yöntemiyle yapılır
- Sayfa gezinmesinin olmaması, sınırlı mobil destek ve ilk iframe yüklemesinin neden olduğu
on.get("/")durum güncellemesi kaybına dikkat edilmelidir
Tarayıcı içinde çalışan HTMX sandbox'ı
- HTMX Playground, HTMX'i kurulum olmadan denemeyi sağlayan basit bir kod sandbox'ıdır
- Orijinal htmx.org examples örneklerinden uyarlanmış örnekler sunar
- Tarayıcı içinde backend'e benzer bir akışla kod yazabilirsiniz
server.jsiçinde endpoint'ler tanımlanır- Şablonlar doğrudan render edilebilir
- HTMX'ten çıkan istekleri yakalayan bir sahte sunucu çalışır
- İstek işleme ve şablon motoru, Django kullanıcılarına tanıdık gelecek bir yapıdadır
- Proje yalnızca HTMX ile sınırlı değildir; başka kütüphaneler de denenebilir
- Kod GitHub üzerinde açık olarak yayınlanmıştır
Kaydetme·paylaşma yöntemi ve bilinen kısıtlar
-
Kaydetme ve paylaşma
- Sağ üstteki “Copy as JSON” düğmesine basarak içeriği kopyalayın
- Kopyalanan içeriği Gist'e yükleyin
- raw URL'yi “Load Playground” alanına girin
- Sayfa URL'si güncellendiğinde paylaşabilirsiniz
-
Kısıtlar
- Sayfa gezinmesi yoktur
- Mobil destek sınırlıdır
server.js, Click to Edit örneğinde olduğu gibi durum tutabilir- Durum
on.get("/")görünümünde güncellenirse bu güncelleme kaybolabilir- Bunun nedeni, ilk sayfa yüklemesinin ekrandaki iframe güncellenmeden önce ayrı bir iframe içinde önce alınmasıdır
-
Kullanılan kütüphaneler
- Svelte
- Ace
- PollyJS
- Nunjucks
1 yorum
Hacker News görüşleri
htmx'in yaratıcısıyım; bunu yaptığınız için gerçekten minnettarım ve çok harika buldum
Mevcut bir sayfada formu doldurup gönderdiğimde yanıt tüm sayfa olarak geliyor; htmx'e “tüm sayfa dönse bile sadece #my-form güncellensin” diyebilsek, sunucuda “eğer htmx isteğiyse” gibi bir ayrım eklemek gerekmezdi diye düşünüyorum
Bu, sitenin JavaScript olmadan da çalışmasını isteyenler için iyi olurdu ve yorumlar, e-posta aboneliği, beğeni düğmesi gibi çeşitli özellikler de tek bir backend endpoint'i ile yönetilebilirdi
HTMX'i ciddi biçimde kullanmayı düşündüm ama geliştirici havuzu çok küçük olduğu için işe alımın zor olacağından endişeliyim
Intershop'un isml'i gibi Thymeleaf'e benzeyen kapalı bir framework'e alışkındım; son dönemde ise özel frontend geliştiricileri bulmak daha kolay olduğu için Angular frontend stack'ine geçmeyi düşünüyordum
htmx gibi bir yaklaşım karmaşıklaşabilir; geliştiriciler spagetti canavarıyla savaşmak istemez ve frontend sadece HTML üretip backend her şeyi birleştirmek zorunda kalırsa backend geliştiricisi darboğaz olabilir
HTMX'in bu tür tuzakları hesaba katıp katmadığını ve buna nasıl yaklaştığını merak ediyorum
Yine de HTMX her durumu çözmez; bazen JavaScript framework'ü kullanan bir single-page app gerekir
Angular gibi framework'ler yapı sağlar ama karmaşıklık yerinde durur, hatta muhtemelen çok daha büyük olabilir
Sonuçta gereken şey, JavaScript, CSS, HTML ve browser API'leri gibi web stack'ini iyi bilen frontend geliştiricileridir; böyle insanlar işe uygun araçları ve framework'leri seçebilir ve HTMX gibi bir şeyi de çok hızlı öğrenir
https://risingstars.js.org/2023/en#section-framework
React'in hemen arkasında, Vue, Svelte ve Angular'ın önünde yer alıyor; bu açıdan geleceği parlak görünüyor. Yine de ilk heyecan yatışınca sıralamasının düşeceğini tahmin ediyorum
htmx oldukça basit; çoğu web geliştiricisi bir gün içinde öğrenebilir, ancak geliştirme tarzı organizasyonu geliştiricinin özelliğin tamamına sahip olduğu bir full-stack paradigmasına iter; bu yüzden yalnızca geliştiricilerin değil, PM'lerin ve mimarların da zihniyet değiştirmesi gerekir
Ücretsiz bir çevrimiçi kitap da var: https://hypermedia.systems
Dokümantasyonun (https://htmx.org/docs, okunması yaklaşık bir saat) yanı sıra, htmx ve genel olarak hipermedyanın felsefi ve pratik meselelerini ele alan yazılar da var: https://htmx.org/essays
htmx'in temel fikirleri çok az; lazy loading gibi yararlı davranışlar bile iki öznitelikle uygulanabiliyor, bu yüzden “genişletilebilir” olacak şekilde tasarlanmaya çalışılıyor: https://htmx.org/examples/lazy-load
Aynı zamanda event'ler, event filter'ları gibi hook'lar ve daha derin özellikler de var; daha derine indikçe istediğiniz davranışı uygulayabiliyorsunuz
Spagetti kod, tüm yazılım geliştirmede her zaman var olan bir risktir; bir single-page app kütüphanesinin bunu önlediğine kişisel olarak hiç ikna olmadım
htmx'te çabayı backend'e odaklamak ve uygulamayı sunucu tarafı ortamın sunduğu araçlarla iyi şekilde parçalamak daha doğru olur
htmx, istediğiniz sunucu teknolojisini seçmenize izin verdiği için, frontend'de zaten büyük bir JavaScript/TypeScript uygulaması bulunup backend'i de o yöne iten single-page app yaklaşımına kıyasla uygulama mantığını organize etmek için daha fazla seçenek ve paradigma sunar
htmx'in hangi tür uygulamalar için iyi bir seçim olduğunu burada da özetlemeye çalışmıştım: https://htmx.org/essays/when-to-use-hypermedia/
htmx birçok durumda iyi bir araçtır ama sonuçta sadece bir araçtır; web geliştirme için her derde deva değildir
Biraz frontend yapabilen backend geliştiricileri işe almış oluyorsunuz; bu yüzden özgeçmişte HTMX yazması gerekmez, JavaScript gibi temel bilgilere sahip olması yeterlidir
Web geliştiricilerinin çoğu bu tanıma uyar
MapLibre'ı Django ve htmx ile birlikte kullanıyordum; başkalarıyla paylaşabilmek için bir örnek yüklemeyi denemeliyim
Kimse kullanmıyor ama o projeyi de görmek isterim
Bildiğim kadarıyla Monaco tasarımı gereği mobilde çalışmıyor, bu yüzden mobilde Ace kullanılıyor
En azından GitHub issue'suna en son baktığımda durum buydu
[0] https://github.com/Microsoft/monaco-editor/issues/246
Bu ActiveX de destekliyor mu?
İlk sürümlerde tüm arayüz ActiveX'ti ve bir sürü DLL kurulum ilerleme çubuğu gördüğümü hatırlıyorum
Bunu bir Service Worker kullanarak yapabilirler ve keşif için başka sekmelerde birden fazla sayfa açılmasına da izin verebilirler
Çok da zor görünmüyor; sayfa oluşturmak için saf JavaScript ya da kullanıcının istediği herhangi bir şey kullanılabilir
Svelte ile yapılmışsa, MPA saflıkçıları ve dirgenler nerede?
htmx'in fikrini sevdiğim için bugün kitabı okumaya başladım ama bir gün yerel mobil uygulamaları da desteklemek gerektiğini düşündüğümde kullanmakta tereddüt ediyorum
Bu durumda yalnızca frontend'i değil, backend'in önemli bir kısmını da yeniden yazmak gerekecek gibi görünüyor
hyperview.org'u biliyorum ama ilgilendiğim kullanım senaryoları için React Native uygulaması yeterli değil
Domain mantığını controller'ların dışında tutmanız yeterli
Service Worker içinde tanımlanmış sanal sunucu ve HTML/HTMX istek-yanıt yaklaşımıyla çevrimdışı uygulamalar yapan biri var mı diye merak ediyorum
htmx'i seviyorum ama çevrimdışı da çalışması gereken durumlarda kullanamadım
Sunucu kodunu worker içinde olduğu gibi çalıştırabilmek harika bir hack olurdu
Teoride kendi kendine barındırılabilen herhangi bir sunucu yığınıyla bu mümkün
Amaç, dış servislere bağımlılığı olmayan tek bir ikili dosya oluşturmak ve bunun için Go kullanıyorum
Kendi kendini güncelleyen yerel servis, çoğaltılmış veritabanı gibi bileşenler zaten büyük ölçüde hazır ve birden çok işletim sistemi ile mimari için çapraz derlemek de kolay
Her şeyi tarayıcının içine koymaya alternatif olarak, ayrı bir süreç çalıştırılabildiği varsayımında bu yaklaşım oldukça makul görünüyor
Yine de Go'da da Deno'daki gibi izin yönetimi olmasını isterdim
Kişisel uygulamalarımın hepsinde bu deseni kullanıyorum, yalnız kendi yaptığım küçük bir htmx benzeri kütüphaneyi kullanıyorum
HTMX'e geçmek de o kadar zor görünmüyor
HATEOAS'ı masaüstü ya da mobil uygulamalara taşımaya çalışmanın iyi bir fikir olup olmadığını merak ediyorum; ilginç bir deney olabilir
Çalışıyor ama web kadar esnek değil; bağlantı verilebilen her ekranı katı bir kara kutu yaklaşımıyla geliştirmek gerekiyor
Denemesi eğlenceliydi ama prodüksiyonda ne kadar değerli olduğundan emin değilim
REST, SOAP canavarlarını basitleştirdiği için memnuniyetle karşılandı ama beraberinde ciddi bir doktrinerlik de getirdi
REST'in temel amacını anlıyorum çünkü kullanıcıya doğal gelen kavramları, veriyi ve servis mimarisini hizalıyor
Ama HATEOAS, kullanıcı deneyiminin bu model sayesinde iyileşip iyileşmediğine odaklanmaktan çok, mimari toplantılarında daha fazla doktrinerlik ve gösteriş istemenin sonucu gibi görünüyordu
HATEOAS'ın temel ilke olması gerektiğini gösteren bir UI örneği olup olmadığını merak ediyorum
Sonuçta her sayfada doğal olarak “sonra ne yapmalı” bağlantıları vardır ve HATEOAS, böyle bir durum modelini REST servis çağrılarına taşımanın gösterişli bir yolu gibi geliyor