HTMX'ten Datastar'a geçmemin nedeni

 (everydaysuperpowers.dev)
10 puan yazan GN⁺ 2025-10-11 | 2 yorum | WhatsApp'ta paylaş
  • HTMX kullanırken kod miktarını yaklaşık %70 azaltmak mümkün oldu, ancak UI'lar arası senkronizasyon sorunlarıyla birlikte frontend durum yönetiminin karmaşıklığının arttığı görüldü
  • Datastar benimsendikten sonra, gerçek zamanlı çok kullanıcılı uygulamalar geliştirirken WebSockets olmadan daha yalın bir kod yapısı ve daha kolay bakım sağlandı
  • HTMX, çalışma mantığını HTML öznitelikleri etrafında dağıtırken, Datastar sunucu güdümlü güncelleme modeli ile mantığın tutarlılığını ve bakım kolaylığını artırıyor
  • Datastar API'sinde daha az öznitelik bulunuyor; bunun da kodun okunabilirliğini ve üretkenliği artırdığı hissediliyor
  • Datastar, Server-Sent Events(SSE), Web Components, CSS View Transitions gibi web-native teknolojileri etkin biçimde kullanarak gerçek zamanlı iş birliğini ve yeniden kullanılabilir bileşen yapısını mümkün kılıyor

Giriş ve motivasyon

Geçişi tetikleyen sorunlar

  • FlaskCon 2025 sunumunu hazırlarken, HTMX ve AlpineJS'i birleştirerek UI'ı senkronize etmeye çalıştı ancak senkronizasyon sorunlarıyla karşılaştı
    • İki kütüphane de farklı geliştiriciler tarafından yapılmış ayrı araçlar olduğu için birbirleriyle iletişim kuramıyor, entegrasyonu geliştiricinin kendisinin yapması gerekiyor
    • Bileşenleri farklı anlarda başlatmak ve olayları koordine etmek, beklenenden çok daha fazla kod yazımı ve hata ayıklama süresi gerektirdi
  • Datastar'ın bu iki kütüphanenin işlevlerini birleştirirken 11KB'den küçük bir boyutta sunulmasına dikkat çekildi ve denenmeye karar verildi
    • Bu, mobil cihaz kullananlar için sayfa yükleme performansı açısından avantaj sağlıyor

Daha iyi bir Datastar API tasarımı

  • Datastar API'si, HTMX'e kıyasla çok daha hafif bir his veriyor ve istenen sonucu almak için eklenmesi gereken öznitelik sayısı daha az
  • HTMX, çoğu etkileşim için birden fazla öznitelik gerektiriyor
    • URL tanımı, hedef öğenin belirtilmesi ve yanıtın nasıl işleneceği gibi ayarlar ayrı ayrı özniteliklerle yapılıyor
    • Genelde her seferinde 2-3 öznitelik kullanılıyor; bazen de özniteliklerin nasıl çalıştığını anlamak için kalıtım zinciri boyunca yukarı çıkmak gerekiyor
    <a hx-target="#rebuild-bundle-status-button"  
   hx-select="#rebuild-bundle-status-button"  
   hx-swap="outerHTML"  
   hx-trigger="click"  
   hx-get="/rebuild/status-button"></a>
  • Datastar ise aynı işlevi genellikle tek bir öznitelikle gerçekleştiriyor 
    <a data-on-click="@get('/rebuild/status-button')"></a>
    • Koda aylar sonra geri dönüldüğünde bile nasıl çalıştığını anlamak kolay oluyor

Çalışma mantığındaki fark

  • HTMX bir frontend kütüphanesi olarak HTML spesifikasyonunu genişletmeyi hedeflerken, Datastar sunucu güdümlü bir kütüphane olarak yüksek performanslı, web-native, gerçek zamanlı güncelleme yapan uygulamalar kurmayı hedefliyor
  • HTMX, davranışı isteği tetikleyen öğeye eklenen özniteliklerle tanımlıyor; sayfanın uzağındaki başka öğeleri güncellese bile mantık farklı katmanlara dağılmış oluyor
  • Datastar'da ise neyin değişeceğine sunucu karar veriyor ve tüm güncelleme mantığı tek bir yerde toplanıyor

  • HTMX örneği

    <div>  
  <div id="alert"></div>  
    <button hx-get="/info"   
            hx-select="#info-details"   
            hx-swap="outerHTML"  
            hx-select-oob="#alert">  
        Get Info!  
    </button>  
</div>
    • Düğmeye basılınca /info adresine bir GET isteği gönderiliyor, yanıttaki info-details kimliğine sahip öğe ile düğme değiştiriliyor ve yanıttaki alert kimliğine sahip öğe ile sayfadaki aynı kimlikteki öğe değiştiriliyor
    • Düğme öğesinin bilmesi gereken şey çok fazla ve sunucunun ne döndüreceğini önceden bilmek gerektiğinden HTMX'in "locality of behavior" ilkesi zayıflıyor

  • Datastar'ın iyileştirilmiş yaklaşımı

    <div>  
    <div id="alert"></div>  
    <button id="info-details"  
    data-on-click="@get('/info')">  
        Get Info!  
    </button>  
</div>
    • Sunucu, aynı kimliğe sahip iki kök öğe içeren bir HTML dizgesi döndürüyor 
      <p id="info-details">These are the details you are looking for…</p>  
<div id="alert">Alert! This is a test.</div>
    • Basit ve performansı yüksek bir seçenek

Bileşen düzeyinde düşünmek

  • Daha iyi yaklaşım, HTML'i bileşen olarak ele almak
  • O bileşenin özünü kavramak gerekiyor
    • Kullanıcının belirli bir öğe hakkında ek bilgiyi nasıl aldığı
    • Kullanıcı düğmeye tıkladığında bilgi görünür ya da bilgi yoksa bir hata render edilir; her iki durumda da bileşen statik bir duruma geçer

  • Duruma göre bileşenleri ayırmak

    • Yer tutucu durumu: 
      <!-- info-component-placeholder.html -->  
<div id="info-component">  
    <button data-on-click="@get('/product/{{product.id}}/info')">  
        Get Info!  
    </button>  
</div>
    • Bilgi gösterme durumu: 
      <!-- info-component-get.html -->  
<div id="info-component">  
    {% if alert %}<div id="alert">{{ alert }}</div>{% endif %}  
    <p>{{product.additional_information}}</p>  
</div>
    • Sunucu HTML'i render ettiğinde Datastar sayfayı otomatik olarak güncelliyor
    • Bileşen düzeyinde düşünmek, geçersiz bir duruma girilmesini veya kullanıcı durumunun kaybolmasını önlüyor

Aynı anda birden fazla bileşeni güncellemek

  • David Guillot'nun sunumundaki etkileyici noktalardan biri, uygulama favori sayısını güncellerken değişen bileşenin yanı sıra ondan çok uzaktaki sayaç öğesinin de birlikte güncellenmesiydi
    • HTMX burada JavaScript olayı tetikliyor ve bu olay da uzak bileşenin GET isteği göndermesini tetikliyor
  • Datastar, senkron bir fonksiyon içinde bile birden fazla bileşeni aynı anda güncelleyebiliyor

  • Alışveriş sepeti örneği

    • Sepete ekleme bileşeni: 
      <form id="purchase-item"  
      data-on-submit="@post('/add-item', {contentType: 'form'})">"  
>  
  <input type=hidden name="cart-id" value="{{cart.id}}">  
  <input type=hidden name="item-id" value="{{item.id}}">  
  <fieldset>  
    <button data-on-click="$quantity -= 1">-</button>  
    <label>Quantity  
      <input name=quantity type=number data-bind-quantity value=1>  
    </label>  
    <button data-on-click="$quantity += 1">+</button>  
  </fieldset>  
  <button type=submit>Add to cart</button>  
  {% if msg %}  
    <p class=message>{{msg}}</p>  
  {% endif %}  
</form>
    • Sepet sayısını gösteren bileşen: 
      <div id="cart-count">  
    <svg viewBox="0 0 10 10" xmlns="http://www.w3.org/2000/svg">  
        <use href="#shoppingCart">  
    </svg>  
    {{count}}  
</div>
    • Django'da iki bileşeni aynı istekle güncellemek: 
      from datastar_py.consts import ElementPatchMode  
from datastar_py.django import (  
    DatastarResponse,  
    ServerSentEventGenerator as SSE,  
)  

def add_item(request):  
    # önemli durum güncellemesi atlandı  
    return DatastarResponse([  
        SSE.patch_elements(  
            render_to_string('purchase-item.html', context=dict(cart=cart, item=item, msg='Item added!'))  
        ),  
        SSE.patch_elements(  
            render_to_string('cart-count.html', context=dict(count=item_count))  
        ),  
    ])

Web-native felsefesi

  • Datastar Discord topluluğu sayesinde Datastar'ın sadece basit bir yardımcı script değil, web'in temel primitiflerini kullanarak uygulama kurma felsefesi olduğu anlaşıldı
  • HTMX HTML spesifikasyonunu ilerletmeye çalışırken, Datastar daha çok web-native özelliklerin benimsenmesini teşvik etmeye odaklanıyor
    • CSS view transitions
    • Server-Sent Events
    • web components vb.
  • Karmaşık AlpineJS bileşenlerini refactor edip basit web components çıkararak bunları birden çok yerde yeniden kullanmak büyük bir kazanım oldu
  • React gibi araçlar olmadan da özel HTML öğeleri oluşturarak yüksek davranış yerelliği ve yeniden kullanılabilirlik elde etmek çok iyi bir desen sunuyor

Çok kullanıcılı uygulamalar için gerçek zamanlı güncellemeler

  • İş birliğini birinci sınıf özellik olarak sunan uygulamalar diğerlerinden ayrışıyor ve Datastar bu sorunu çözüyor
  • HTMX kullanan geliştiricilerin çoğu, sunucudan bilgi almak için polling kullanıyor ya da karmaşıklığı artıran özel WebSocket kodları yazıyor
  • Datastar, Server-Sent Events(SSE) adlı basit bir web teknolojisini kullanarak sunucunun bağlı istemcilere güncellemeleri "push" etmesini sağlıyor
    • Kullanıcı yorum eklediğinde veya durum değiştiğinde sunucu tarayıcıyı anında güncelliyor; gereken ek kod çok az
    • Özel JavaScript olmadan gerçek zamanlı dashboard'lar, yönetim panelleri ve iş birliği araçları kurulabiliyor
  • İstemci bağlantısı kesilirse tarayıcı otomatik olarak yeniden bağlanmayı dener; ek kod gerekmez
    • Sunucuya "en son alınan olay" bilgisini de verebilir

Aşırı karmaşıklıktan kaçınmak

  • Datastar Discord topluluğu, Datastar'ın web uygulaması geliştirmeye dair vizyonunu anlamaya yardımcı oluyor
    • Push tabanlı UI güncellemeleri
    • Karmaşıklığın azaltılması
    • Web components gibi araçlarla yerelde karmaşık durumların ele alınması
  • Topluluk, yeni kullanıcıların yaklaşımı gereğinden fazla karmaşıklaştırdığını fark etmelerine de yardımcı oluyor

Temel ipuçları

  • Tüm bileşeni yeniden render edip göndermekten çekinmeyin
    • Bu daha kolaydır ve performansa büyük bir etkisi olmaz
    • Daha iyi sıkıştırma oranı elde edilebilir, ayrıca tarayıcı HTML dizgelerini çok hızlı parse eder
  • Gerçeğin durumu sunucudadır ve sunucu tarayıcıdan daha güçlüdür
    • Durumun büyük bölümünü sunucu yönetsin; düşündüğünüz kadar reaktif sinyale ihtiyaç olmayabilir
  • Web components, mantığı yüksek davranış yerelliğine sahip özel öğeler içinde kapsüllemek için mükemmeldir
    • Datastar web sitesindeki başlıktaki yıldız alanı animasyonu buna iyi bir örnek
    • <ds-starfield> öğesi yıldız alanı animasyonuna ait tüm kodu kapsüllüyor ve iç durumu değiştirmek için üç öznitelik sunuyor
    • Datastar, range input değiştiğinde veya fare öğenin üzerinde hareket ettiğinde bu öznitelikleri sürüyor

Sınırları aşan olanaklar

  • En heyecan verici olan, Datastar'ın mümkün kıldığı potansiyel
  • Topluluk düzenli olarak, başka araçları kullanan geliştiricilerin yaşadığı sınırların çok ötesine geçen projeler üretiyor

Dikkat çeken örnekler

  • Örnek sayfadaki veritabanı izleme demosu
    • Hypermedia kullanarak, JavaScript konferanslarında sunulan demolara kıyasla hız ve bellek kullanımında büyük iyileşme sağlıyor
  • Anders Murphy'nin 1 milyar checkbox projesi
    • 1 milyon checkbox deneyi sunucu kapasitesini aşınca, Datastar kullanılarak düşük maliyetli bir sunucuda 1 milyar checkbox gerçekleştirildi
  • ABD'deki tüm radar istasyonlarının verilerini gösteren bir web uygulaması
    • Radardaki sinyal değiştiğinde UI'daki ilgili nokta 100 milisaniyenin altında değişiyor
    • Saniyede 800 binden fazla nokta güncelleniyor ve kullanıcılar en fazla 1 saat öncesine kadar scrub yapabiliyor (700 milisaniyenin altında gecikmeyle)
    • Bunun bir hypermedia uygulaması olarak mümkün olması, Datastar'ın neler sağladığını gösteriyor

Güncel kullanım deneyimi

  • Datastar hâlâ keşif aşamasında olsa da, standart HTMX tarzı UI güncelleme AJAX işlemlerini hızlı ve kolay biçimde uygulayabiliyor
  • Datastar ile daha fazlasını başarmaya yönelik çeşitli desenler öğreniliyor ve deneniyor
  • Onlarca yıldır gerçek zamanlı güncellemelerle daha iyi kullanıcı deneyimi sunma yollarına ilgi duyuluyordu; Datastar'ın senkron kodda bile push tabanlı güncellemeler sağlayabilmesi beğeniliyor
  • HTMX kullanılmaya başlandığında büyük bir heyecan hissedilmişti; ancak Datastar'a geçtikten sonra hiçbir şey kaybedilmediği, aksine çok daha fazlasının kazanıldığı düşünülüyor
  • HTMX kullanırken aynı heyecanı hissettiyseniz, Datastar'da da benzer bir sıçramayı yeniden hissedeceksiniz; bu, adeta web'in en başta yapması gereken şeyi yeniden keşfetmek gibi

İlgili okumalar

2 yorum

 
GN⁺ 2025-10-11
Hacker News görüşleri
  • Chris’in konfor alanından çıkıp kendini zorlamasına ve bu deneyimi bizimle paylaşmasına minnet duyuyorum. Ben 4 yıldır htmx ile web uygulamaları geliştiriyorum, bu yüzden biraz taraflı olabilirim; ama bence burada Datastar ile htmx arasındaki temel mimari fark ortaya çıkıyor: htmx HTML odaklı, Datastar ise sunucu odaklı. İstemci tarafı API’sinin daha basit olduğu doğru, ama bunun nedeni sunucu tarafı mantığının daha karmaşık hale gelmesi. Örneğin bir HTML öğesinin, sunucudan dönen fragment’i nereye yerleştireceğine dair bilgi yoksa, bu bilginin sunucu tarafında tutulması gerekir; yani karmaşıklık bir tarafta mutlaka vardır. Mimari seçimi biraz tercih meselesi gibi. Örnekteki “less attributes” (daha az attribute) mantığı, htmx’te isteğe bağlı eklenebilen attribute’ları da örneğe kattığı için %100 adil görünmüyor; örneğin hx-trigger="click" kaldırılırsa attribute sayısı %20 azalıyor. Ayrıca <span> yerine <button> kullanmak gibi daha erişilebilir HTML yazılsa güvenilirliği artardı. Sonuçta Datastar’ın güçlü yanı, sanki Alpine ya da Stimulus işlevlerini içine gömülü olarak sunması gibi görünüyor; bu gerçekten etkileyici
    • Datastar kullanınca, sayfanın başka bölümlerini gerçek zamanlı güncellemek için eventing mekanizmasını ayrıca kurmaya gerek kalmadan her şeyi tek seferde indirip güncelleyebilmek, karmaşıklığı ciddi biçimde azaltmıyor mu diye düşünüyorum. Tabii bazı durumlarda event tabanlı yaklaşım ya da sonradan yükleme daha iyi olabilir
    • “HTMX’e Alpine ya da Stimulus işlevleri gömülü gibi” yorumunu görünce kişisel projede HTMX kullanmayı düşünmeye başladım. AlpineJS ya da Stimulus gibi ek kütüphanelerin de gerektiğini anlatan bir kaynak var mı merak ediyorum
    • Eğer HTML öğesinde fragment’in nereye ekleneceğine dair bilgi yoksa sunucunun bunu bilmesi gerektiği konuşuluyordu; ama böyle durumlarda frontend daha hafif ve hızlı olmaz mı diye de düşündüm. Özellikle çok sayıda öğe varsa daha da öyle değil mi?
    • Bu yapı biraz Pharo’nun Seaside framework’üne benziyor. Şirketimizde Pharo ile B2B uygulamalar yaparken UI durumunu backend’de yönettiğimiz için frontend ile backend arasında çok fazla gidip gelme oluyordu. Gerçek zaman ve gecikmenin kritik olmadığı B2B için sorun değil ama yüksek ölçekli B2C uygulamalarda uygun değil
  • Datastar ve HTMX’i bizzat kullanmış biri olarak, Datastar ile uygulama geliştirirken neyin büyük fark yaratacağını hâlâ pek göremiyorum. FastAPI, HTMX, Alpine.js ve SSE’yi birlikte kullanarak logları gerçek zamanlı göstermek, dağıtım durumunu güncellemek gibi işler yapıyorum. Datastar örneklerine bakınca bunun mevcut yapımdan daha basit olan kısmını pek seçemiyorum. (Kod için: devpush SSE partial). Web Components’ı da daha önce Basecoat geliştirirken denedim ama stil sorunları ve state yönetimi gibi nedenlerle sonunda yine geleneksel HTML/CSS/JS’ye döndüm. devpu.sh, basecoatui.com
    • HTMX’te de Datastar’daki gibi işlevsel genişletilebilirlik düşünülüyorsa, çoğu zaman tüm listeyi baştan sona güncellemek daha basit oluyor. Tek tek deployment durumlarını güncellemeye çalışmak yerine tüm listeyi yenilersen pagination gibi edge case’leri de düşünmek gerekmiyor; böylece çok daha sade ve daha hafif kod çıkıyor
  • Datastar’ın gerçek zamanlı/işbirlikli/multiplayer senaryolar için yetersiz olduğunu düşünenler varsa, PRO özellikleri olmadan da çalışan ve hatta 5 dolarlık bir VPS üzerinde HN ana sayfasına çıkan şu 3 demoyu göstermek isterim. Datastar’ın ne kadar iyi tasarlanmış bir teknoloji olduğunu gösteriyorlar: Checkboxes, Cells, Game of Life Example. Checkbox ve Cells örneklerinde görünüm oldukça akıcı render ediliyor; epey uzaklaştırma yapılabiliyor ve sanal kaydırmada backpressure desteği de var
    • Kodu doğru anladıysam, aslında datastar’ın önerdiği diff/patch yaklaşımı kullanılmıyor; her seferinde tüm sayfa yeniden render ediliyor gibi. Dürüst olmak gerekirse bu zihinsel model, sunucunun istemci durumunu ince ayrıntısına kadar takip ettiği örneklerden çok daha basit göründüğü için daha çekici geliyor. Genel olarak karmaşık uygulamalar da bu şekilde kurulabilir mi merak ediyorum. Kullanıcılar farklı sayfalara geçerken çeşitli widget durumlarını da takip edip anında yeniden render etmek için nasıl bir yaklaşım gerekir, buna dair okunabilecek bir metin varsa görmek isterim
    • Checkboxes/Cells örneklerinde “uzaklaştırma” yapılabildiği söylenmiş; bunun tam olarak nasıl yapıldığını merak ediyorum. Ayrıca mevcut görünümün URL’sinin ilgili koordinatlarla (x=123&y=456 gibi) otomatik güncellenmesini sağlayan data-replace-url benzeri bir seçenek olsa daha iyi olurdu
    • PRO özellikleriyle ilgili yorumu görünce bunun open-core bir model olduğunu fark ettim (bir kısmı açık kaynak, kalanı ücretli, 299 dolarlık lisans). Ben pas geçerim
  • Kısa süre önce şu yazıyı okudum: htmx, datastar, greedy developer. Datastar’ın iyi olan bazı temel özelliklerinin ücretli (Pro) sürüme taşındığını duydum. Framework’leri ister açık kaynak ister ücretli olsun maddi olarak desteklemek isterim ama böyle emsaller biraz endişe verici
    • Ben de Datastar’ı birkaç aydır takip ediyor, 1.0.0 sürümünü bekliyordum; ama artık hevesim tamamen kaçtı. “Açık kaynak ama aslında değil” durumlarını çok kez gördüğüm için güven vermiyor
    • Aslında daha önce Datastar’dan pek hoşlanmadığımı yazmıştım ama bu kez biraz Datastar’ı savunmak istiyorum. Framework’ün geliştiricisi kendi kodunu MIT lisansıyla ücretsiz yayımladı; yani geçmişte ücretsiz yayımlanan özellikler hâlâ MIT kapsamında kullanılabiliyor. Hiç katkı yapmadan sadece kullanmış biri olarak eski sürümlere bağlı kalmak da kişinin kendi tercihi. Bundan sonra ücretli modele geçmek ürün sahibinin hakkı; gerekirse fork’lanır diye düşünüyorum
    • PRO lisansını 299 dolara bir kere ödeyip aldım ama henüz PRO özelliklerini fiilen kullanmadım. Bir Google Sheets klonu yapmayı düşünmüştüm ama PRO olmadan da yeterince uygulanabiliyordu. (cells demosuna bakın)
    • Datastar tarafı, HTMX Discord’unda Datastar’ın ne kadar iyi olduğunu sürekli övmenin ötesinde bazen biraz saldırgan geliyordu. Reddit’te de “ihtiyacın olan her şey varsa beta’yı sonsuza kadar kullan, açık kaynak kimseye borçlu değildir” tonunda yorumlar bıraktıklarını görmüştüm
    • Datastar’ı kullanırken aklıma gelen eski örnek doğrudan Meteor.js oldu. (Meteor.js HN tartışması)
  • Bu gönderideki örnek kodlar bana çok anlaşılır gelmedi. Örneğin aşağıdaki htmx örneği <span hx-target="#rebuild-bundle-status-button" hx-select="#rebuild-bundle-status-button" hx-swap="outerHTML" hx-trigger="click" hx-get="/rebuild/status-button"></span> şu datastar koduna dönüşüyor gibi görünüyor: <span data-on-click="@get('/rebuild/status-button')"></span> Dahası, diğer örnekler daha da kafa karıştırıcı. Sonuç olarak insanların neden htmx’ten Datastar’a geçtiğini anlamıyorum
    • Temelde HTMX burada “bu span’e tıklandığında /rebuild/status-button adresinden HTML al, dönen HTML içinden #rebuild-bundle-status-button öğesini seç ve mevcut öğeyle değiştir” demek. Datastar’da ise “span’e tıklanınca /rebuild/status-button tarafından verilen komutları uygula” anlamına geliyor. Sunucu birden fazla ID’li öğe döndürürse Datastar bunların hepsini otomatik olarak tanıyıp değiştiriyor. Yani target, select, swap kullanmadan, sadece ID vererek istenen davranış elde edilebiliyor
    • Datastar’ın yapısı, mantığın backend’de toplandığı bir model. Eski geleneksel HTML’de olduğu gibi istek yapılıyor, HTML geliyor ve tarayıcı render ediyor; ama Datastar’da PWA benzeri şekilde sayfa bir kez yüklendikten sonra her etkileşimde backend’e istek gidiyor ve sadece değişiklikler uygulanıyor. Bu, frontend’de mantık olmayan ama tüm state’in backend tarafından yönetildiği, SPA’nin tersine bir yapı. Özünde yine backend/frontend mantığının nerede duracağı tartışması dönüp geliyor; Datastar da mantığı sunucuda yoğunlaştırırken dinamik arayüzü korumaya çalışıyor
    • Ama neden tıklama için span kullanılıyor, onu da anlamıyorum. button ya da link etiketi daha uygun olmaz mı?
  • İşin ironik yanı, bu yazının konusu hypermedia ama Datastar’ın resmi sitesine link yok. Resmî site burada: https://data-star.dev/
  • HTMX’in büyük avantajlarından biri, istemcinin sunucudan dönen veri yapısını bilmek zorunda olmaması. Eğer istemcinin tek tek öğelerin ID’sini ya da anlamını bilmesi gerekiyorsa bu vaat biraz bozuluyor gibi. Tabii pratikte birçok projede OOB (Out of Band) kullanıldığı için yapının tamamen ayrışması da gerçek hayattan biraz uzak olabilir. İki dünyanın avantajlarını birleştiren bir yaklaşım çıksa güzel olurdu
    • Aslında istemcinin hiçbir şey bilmesi gerekmiyor. İstemcide bir aksiyon çalıştırıldığında sunucu tüm sayfa görünümünü geri gönderebilir. İstemci de bunu anında bütünüyle render eder. Bu, video oyunlarındaki immediate mode modeline benziyor
  • Datastar’ın sunucudan HTML patch ederek çalışması, separation of concerns açısından iyi görünmüyor; uygulama büyüdükçe sunucudan sürekli HTML parçaları enjekte etmek yönetmesi çok zahmetli hale gelmez mi?
    • Ama JavaScript’in oradan buradan fragment olarak HTML enjekte etmesi de daha iyi sayılmaz
    • Sunucudan HTML parçaları saçan endpoint’ler tasarlama fikri bana da biraz itici geliyor
  • Datastar, htmx’ten daha olgun hissettiriyor. htmx ile birkaç projeyi başarıyla yaptım ama event işleme için ek JS glue code’u, özellikle de AlpineJS gibi araçları kullanmak zorunda kalmak hep can sıkıcıydı. Datastar bunu da azaltabiliyorsa gerçekten heyecan verici
    • Datastar sitesindeki grugs around the fire denemesini okumayı öneririm
  • Ben hypermedia trendine nispeten geç katıldım; önce Datastar kullandım ama son zamanlarda HTMX’e geçtim. Datastar API’si biraz daha iyi olsa da htmx 2.0’da OOB (Out-Of-Band) güncellemeleri desteklenince artık çoğu durumda htmx’i tercih ediyorum
    • “Hypermedia’ya geç kaldım” ifadesi ilginç. Ted Nelson’ın bu terimi ilk kez 1965’te kullandığını ve o dönemde “hyperfilm— a browsable or vari-sequenced movie— is only one of the possible hypermedia that require our attention” dediğini düşününce daha da ilginç oluyor. İlgili makale
    • HTMX’te OOB öğeleri işlerken can sıkan noktalar: 1. OOB ise htmx-swap-oob="true" mutlaka gerekli; bu attribute yoksa beklenmedik davranıyor 2. Tersi durumda OOB değilse htmx-swap-oob="true" varsa ya yok sayılıyor ya da yanlış çalışıyor. Bu yüzden aynı bileşeni OOB ve OOB olmayan durumda yeniden kullanmak istediğinde sunucunun her seferinde isOob bayrağı göndermesi gerekiyor; bu da gerçekten uğraştırıcı
    • Ben alpine-ajax API’sini daha çok seviyorum. Birden fazla target tanımlayınca JS yazmadan her öğeyi tutarlı biçimde değiştiriyor. Datastar’daki signal/state kavramları ise bence tam tersine karmaşıklığı artırıyor ve hoşuma gitmiyor