Hotwire: Wire Üzerinden HTML teknolojisi

 (hotwired.dev)
2 puan yazan GN⁺ 2024-06-03 | 1 yorum | WhatsApp'ta paylaş
  • Hotwire, JSON yerine HTML göndererek modern web uygulamaları oluşturmayı amaçlayan bir yaklaşım olup, çok fazla JavaScript olmadan hızlı ilk yükleme ve yüksek tepki kabiliyeti hedefler
  • Render işlemini sunucu şablonlarında bıraktığı için, kullanılan dilden bağımsız olarak geliştirme akışını daha basit tutabilir
  • 37signals'ın HEY için geliştirdiği framework'ler birlikte kullanılarak, web'den farklı platformlara uzanan bir Hotwire ekosistemi oluşturur
  • Temel bileşen olan Turbo, sayfa geçişlerini, form gönderimlerini, bileşenlere ayırmayı ve WebSocket tabanlı kısmi güncellemeleri JavaScript yazmadan yönetir
  • Turbo'nun yetmediği özelleştirilmiş etkileşimleri Stimulus tamamlar; Hotwire Native ise mevcut web uygulamalarını temel alarak yerel mobil uygulamalar oluşturmayı mümkün kılar

HTML'i sunucuda render edip gönderme yaklaşımı

  • Hotwire, HTML-over-the-wire yöntemiyle modern web uygulamaları kurmak için alternatif bir yaklaşımdır
  • JSON yerine HTML'i ağ üzerinden göndererek, çok fazla JavaScript olmadan uygulama geliştirmeyi mümkün kılar
  • Hızlı ilk sayfa yüklemesi, sunucu tarafı şablon render'ını koruma ve daha basit, daha üretken bir geliştirme deneyimi hedefler
  • Geleneksel tek sayfa uygulamalarda beklenen hız ve tepki kabiliyetinden vazgeçmeyen bir yaklaşım benimser
  • HTML-over-the-wire, kendi araçlarınızı oluşturmak için referans bir yöntem olarak kullanılabilir ya da 37signals'ın HEY için geliştirdiği Hotwire framework'leri doğrudan kullanılabilir

Turbo, Stimulus ve Hotwire Native'in rolleri

  • Turbo, Hotwire'ın temel bileşenidir
    • Sayfa geçişlerini ve form gönderimlerini hızlandıran tamamlayıcı teknikler sunar
    • Karmaşık sayfaları bileşenlere ayırır ve WebSocket ile kısmi sayfa güncellemelerini akış halinde iletir
    • Bu işlevleri JavaScript yazmadan sağlar
  • Stimulus, yalnızca Turbo'nun yeterli olmadığı durumlarda gereken özelleştirilmiş kod için kullanılır
    • Turbo, geleneksel olarak JavaScript gerektiren etkileşimlerin en az %80'ini genellikle karşılar
    • Stimulus, durum ve bağlantıları HTML merkezli bir yaklaşımla ele almayı mümkün kılar
  • Hotwire Native, yerel mobil uygulamalar oluşturmak için web öncelikli bir framework'tür
    • Mevcut web uygulamalarını kullanarak mobil uygulama geliştirmek için gereken araçları sağlar

İlgili okumalar

1 yorum

 
GN⁺ 2024-06-03
Hacker News yorumları

  • Bu özelliğin daha az pazarlanmış bir sürümü olarak htmx var: https://htmx.org/
    Tek bir JavaScript dosyasıyla bu tür özellikleri mümkün kılıyor ve çoğunlukla Go backend ile birlikte kullanıldığını gördüm, ama oldukça esnek görünüyor. Yaklaşık 1 yıldır bir ara denemeyi düşünüyordum

    • En azından Hacker News ölçütüne göre htmx çok daha fazla öne çıktı diye düşünüyorum
      Sadece son 1 yılda bile HN gönderileri yüzlerce kez yapıldı 0 ve 1000 puanı geçen yazılar da vardı. Buna karşılık Hotwire son 1 yılda 30'dan az kez gönderildi 1 ve bunların içinde en popüler olanı bu yazı
    • htmx'in daha az pazarlanmış olduğunu anlamıyorum. Hotwire'ı ilk kez duyuyorum ama htmx'i her yerde fazlasıyla görüyorum
      Sadece YouTube'a kısa bir bakmak bile programcı influencer'ların htmx'i yüzlerinin olduğu küçük görsellerle sürekli öne çıkardığını görmeye yetiyor
    • Başka özellikler de içeren https://unpoly.com de anılmaya değer
    • HTMX muhtemelen herhangi bir framework'ten daha iyi pazarlanmış durumda
      Twitter'da da çok aktif, The Primeagen'in YouTube kanalında da sık sık çıkıyor ve oldukça popüler
    • Daha az mı pazarlanmış? Tüm sosyal platformlarda htmx fışkırıyor gibi geliyor

  • PHP/Laravel tarafında benzer bir şey arıyorsanız Livewire'ı şiddetle tavsiye ederim: https://laravel-livewire.com/
    Daha karmaşık projelerde hâlâ React kullanıyorum ama reaktif UI öğelerini korurken her şeyi Blade/PHP ile yazabilmek her zaman ferahlatıcı geliyor. Gerektiğinde Livewire içinde React/Vue bileşenlerini render etmenizi sağlayan paketler de gördüğümü hatırlıyorum: https://minglejs.unitedbycode.com/. Mevcut paketleri içeri çekmek gerektiğinde ilginç bir çıkış yolu gibi görünüyor

  • Eskiden Hotwire/Livewire'a oldukça olumsuz bakıyordum ama şimdi bunun duruma uygun bir araç olduğunu düşünüyorum
    Wire üzerinden kısmi şablonlar göndermek bir hypermedia yaklaşımı ve bugünlerde sadece hypermedia uygulamalarını iyi inşa etmiyoruz. htmx ve RTF'nin REST makalesini yeniden okuyunca bu noktaya geldim; hypermedia'nın özünde daha üstün bir mimari olduğunu düşünmüyorum ama birçok seçenek arasında meşru bir eşdeğer ve yavaş da olsa gelişmeye devam etmesi güzel

  • React/Vue/Svelte tavşan deliğine düşmeden PWA yapmanın en kolay yoluna yakın
    Onları da kullandım ve harika olduklarını düşünüyorum ama htmx ile karşılaştırınca teknoloji odaklı olmaktan çok geliştirici deneyimi odaklı geliyorlar. İkisi arasındaki rekabetin sonunda hangi backend framework'üyle daha iyi entegre olduklarına bağlı olacağını düşünüyorum

    • Mobil uygulama sadece bir WebView ise olabilir. Aksi takdirde mobil uygulama için REST API ile HTML parçaları gönderen Hotwire/Livewire istek işleyicisini birlikte korumanız gerekir
      Kişisel olarak PWA'nın bir istemci sorunu olduğunu düşünüyorum; sunucu bağımlılığı eklemek yerine bunu istemci tarafında çözmek gerekir
    • Bunun, bahsettiğiniz alternatiflerden neden daha az tavşan deliği olduğunu merak ediyorum

  • Bunun ilk çıktığı döneme daha yakın olan 2020 HN tartışması burada: https://news.ycombinator.com/item?id=25507942

  • Neredeyse tam bir tur atmışız gibi geliyor. 2005 ya da 2006 civarında tıklamaları yakalayıp parametre ekleyerek, yalnızca render edilmiş HTML parçasını alıp gövdeyi .innerHTML ile değiştirdiğimiz bir yöntemi kullandığımızı hatırlıyorum

    • 2000’lerin başında AJAX çıkmadan önce Adam Rifkin, kendi girişimi KnowNow’un demosunu göstermişti; o zamanlar bir web sayfasının yenileme olmadan kendi kendine güncellenmesi sarsıcıydı
      İşin püf noktası HTTP isteğini sürekli açık tutup sunucunun ara sıra güncelleme göndermesiydi ve bu güncellemeler de HTML’di. O zamanlar DOM manipülasyonu bile yapılamıyor olabilirdi; bu yüzden kelimenin tam anlamıyla kapanmayan etiketleri olan bir sayfa bile olabilir
    • Buna tam bir tur atmaktan ziyade, farklı web UI paradigmalarının kapsama alanını genişletmesi demek daha doğru
      Sunucu tarafı render framework’leri istemci etkileşimini daha kolay hale getiriyor, React ise RSC ile sunucu tarafı render’ı kolaylaştırıyor. Çok yüksek etkileşimli web uygulamaları için SPA hâlâ avantajlı
    • Hotwire ya da benzeri kütüphaneler her gündeme geldiğinde bunu duyuyorum ama gerçekte AJAX tabanlı basit CRUD hiçbir zaman ortadan kalkmadı
      Çok fazla SPA projesi var ama bu dünyadaki tüm web sitelerini açıklamıyor
    • https://animasci.com/ benzer bir yaklaşım kullanıyor
      Sayfalama, aşağı kaydırıp “Show more”a basınca sunucudan bir sonraki sayfayı HTML parçası olarak isteyip görünmeyen bir iframe’e yüklemek, yükleme bitince de mevcut sayfaya eklemek şeklinde yapılmıştı
    • 2000’lerin sonlarında Wicket’i epey seviyordum ve JavaScript’ten hoşlanmıyordum ama UI durumunu ve şablonları sunucuda yönetmek, ekip ortamında performans ve ölçeklenebilirlik açısından kolayca tuzağa dönüşebiliyordu
      Bu arada web’in, JavaScript’in ve TypeScript’in ne kadar geliştiğini düşününce bu yaklaşıma yeniden heyecanlanmak zor

  • Çok yüksek etkileşimli frontend gerektiren web uygulamalarıyla çok uğraşmadım ama e-ticaret mağazalarında ve şirket içi Rails uygulamalarında Turbo ve Stimulus, yeni geliştiricilerin öğrenmesi gereken şeyi ciddi biçimde azalttı

    • Stack’i sade tutarsanız aslında işler o kadar da zor değildi
      Örneğin bir Django projesinde, kendini kanıtlamış KnockoutJS ile ofis içi bir aracı baştan sona hızla yaptım; bu da bir ölçüde HTMX’in ruhuyla örtüşüyor. Hâlâ erken aşamada olan Arrow.JS de benzer. Karmaşıklık, özellikle de UI tarafındaki karmaşıklık, çoğunlukla kendi yarattığımız bir şeydi; eski yöntemler hiç eskimedi, aksine geri dönüyor. Sektörün tüm web uygulamalarını aşırı karmaşık ve katlanılmaz yığınlara dönüştürmesi gerektiğine insanları ikna etmeye çalıştığı en aptal dönemde sektöre giren genç bir geliştirici kuşağı var
    • Stimulus kullanmış biri olarak Stimulus berbattı ve bir daha kullanmam. Hotwire ise fena değildi

  • Hey’i çıktığı günden beri ücretli kullanıyorum; eğer Hey web uygulaması deneyimi Hotwire’ın en iyi örneği ise, ben almayayım
    Yavaş bağlantılarda kötü. Bunun sebebi geliştiricinin yüklenme durumu ya da hata durumu eklememesi olabilir, karmaşıklığın fazla olması olabilir ya da Hey’in bir bug’ı olabilir. Bilmiyorum ama iyi değil
    Orta ile yüksek gecikme arasında davranış öngörülemez ya da bug’lı gibi hissettiriyor. İçi boş kutular açılıyor, bağlantılar beklendiği gibi çalışmıyor ve art arda hızlıca birden fazla işlem yaptığınızda bunlar sezgisel bir şekilde iptal edilmiyor. Her şey biraz kaymış gibi hissettiriyor
    SPA ne kadar kötü olursa olsun, bu bana UI’ın yerel ve doğal hissettirmesi yönünden bir adım geri gibi geliyor

  • Bu yazının şimdi yeniden gündeme gelmesinin nedeni, geçen hafta birinin Hey’de modal açmanın yavaş olduğunu paylaşmasıydı: https://x.com/noahflk/status/1795758603577545035
    Hey, DHH tarafından yapıldı; DHH aynı zamanda Hotwire ve Rails’in de yaratıcısı. Sonrasında DHH’nin orijinal videonun kısıtlı ağda çekildiğine dair itirazı, modal yüklemek zaman alıyorsa bunun Hotwire’ın ağa fazla bağımlı olduğunu söyleyen tepkiler, Rails/Hotwire savunuları ve bu yaklaşıma itirazlar birbirine karıştı ve hararetli bir tartışma çıktı. Geçen hafta Twitter’da büyük bir konuydu

    • DHH’nin, orijinal videonun kısıtlı ağda çekildiğini söylemesi doğruydu
      Paylaşımı yapan kişi de “gösterim amacıyla bilerek yavaşlattım” dedi: https://x.com/noahflk/status/1795855075526471915. “SF’de iyi bir MacBook ve gigabit internet” kullananların deneyimini göstermeye çalışmadığını, yavaş mobil internet ve ucuz dizüstü bilgisayar kullananları kastettiğini söyledi. Google Calendar SPA’nın çok daha yavaş olduğuna dair yorumlar da vardı ve seçenekler sadece “SF gigabit internet” ile “ağır biçimde kısıtlanmış 3G” değil. Orijinal paylaşım çok yanıltıcıydı ve fiilen yalan sayılabilecek kadar kötüydü
    • DHH’nin doğrudan yanıtı: https://x.com/dhh/status/1796163806650868149
    • Yaklaşık 1 yıl önce Hey’e baktığımda, Pasifik’in öbür ucundan bile oldukça hızlı görünüyordu
      Özellikle sayfa yapısı etkileyiciydi. Örneğin bağlam menüsü overlay’inde details/summary/anchor kombinasyonunu progressive enhancement yaklaşımıyla kullanmışlardı; JavaScript kapalı olsa ya da asset’ler yüklenmese bile, basit bir düzen içinde menü içeriğini zarif biçimde yükleyebiliyordu. Bunun dışında da Web API’lerin dikkatli kullanıldığı birçok yer vardı ve istemci kodu da neredeyse hiç obfuscate edilmemişti; diye hatırlıyorum, source map’ler de ekliydi. DHH hayranı değilim ve o haftaki dramayı takip etmeyi de düşünmüyorum ama bu kez 37signals’ın işi doğru yaptığını düşündüm
    • Bunu zaten düzeltmişler. Güncellemeyi burada görebilirsiniz: https://x.com/dhh/status/1797370923391357143

  • Aynı fikri daha minimal biçimde uygulayan Swap JS’yi 2 yıl önce yaptım: https://github.com/josephernest/Swap
    Birkaç projede kullandım ve iyi çalıştı