10 पॉइंट द्वारा GN⁺ 2025-10-11 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • HTMX इस्तेमाल करने पर कोड की मात्रा लगभग 70% तक कम की जा सकी, लेकिन UI सिंक्रोनाइज़ेशन की समस्याओं के साथ frontend state management की जटिलता बढ़ गई
  • Datastar अपनाने के बाद, रियल-टाइम multi-user application बनाते समय WebSockets के बिना भी संक्षिप्त कोड संरचना और आसान maintainability संभव हुई
  • जहाँ HTMX HTML attributes के इर्द-गिर्द behavior logic को बिखेरता है, वहीं Datastar server-driven update model के ज़रिए logic की consistency और maintainability बढ़ाता है
  • Datastar API में attributes कम हैं, जिससे कोड की readability और productivity बढ़ी हुई महसूस होती है
  • Datastar Server-Sent Events(SSE), Web Components, CSS View Transitions जैसी web-native technologies का सक्रिय उपयोग करता है, जिससे रियल-टाइम collaboration और reusable component structure संभव होती है

परिचय और प्रेरणा

स्विच करने की वजह बने मुद्दे

  • FlaskCon 2025 प्रस्तुति की तैयारी के दौरान HTMX और AlpineJS को मिलाकर UI सिंक करने की कोशिश की, लेकिन UI synchronization की समस्या सामने आई
    • दोनों लाइब्रेरी अलग-अलग डेवलपर्स द्वारा बनाए गए अलग टूल हैं, इसलिए वे आपस में communicate नहीं कर पातीं, और integration का काम डेवलपर को खुद करना पड़ता है
    • अलग-अलग समय पर components initialize करना और events को coordinate करना, उम्मीद से ज़्यादा कोड और debugging time लेने लगा
  • Datastar दोनों लाइब्रेरी की क्षमताओं को जोड़ते हुए भी 11KB से कम आकार में मिलता है, इस बात ने ध्यान खींचा और इसे आज़माया गया
    • यह mobile users के लिए page-load performance बेहतर करने में फायदेमंद है

Datastar का बेहतर API डिज़ाइन

  • Datastar का API, HTMX की तुलना में काफी हल्का महसूस होता है, और मनचाहा परिणाम पाने के लिए कम attributes जोड़ने पड़ते हैं
  • HTMX में ज़्यादातर interactions के लिए कई attributes चाहिए होते हैं
    • URL define करना, target element तय करना, response handling का तरीका सेट करना — ये सब अलग-अलग attributes से करना पड़ता है
    • आम तौर पर हर बार 2~3 attributes उपयोग होते हैं, और कभी-कभी inheritance chain ऊपर तक जाकर यह देखना पड़ता है कि attribute कैसे काम कर रहा है
    <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 आम तौर पर सिर्फ एक attribute से वही काम कर देता है
    <a data-on-click="@get('/rebuild/status-button')"></a>  
    
    • कुछ महीनों बाद कोड दोबारा देखने पर भी उसका व्यवहार आसानी से समझा जा सकता है

काम करने के तरीके में अंतर

  • HTMX एक frontend library है जिसका लक्ष्य HTML spec का विस्तार करना है, जबकि Datastar एक server-driven library है जिसका लक्ष्य high-performance web-native रियल-टाइम update application बनाना है
  • HTMX, request trigger करने वाले element पर attributes जोड़कर behavior define करता है, इसलिए चाहे पेज के दूर मौजूद elements को update करना हो, logic कई layers में बिखर जाता है
  • Datastar में server तय करता है कि क्या बदलना है, इसलिए सारी update logic एक जगह केंद्रित रहती है
  • HTMX उदाहरण

    <div>  
      <div id="alert"></div>  
        <button hx-get="/info"   
                hx-select="#info-details"   
                hx-swap="outerHTML"  
                hx-select-oob="#alert">  
            Get Info!  
        </button>  
    </div>  
    
    • बटन दबाने पर /info को GET request भेजी जाती है, response के info-details ID वाले element से बटन बदल दिया जाता है, और response के alert ID वाले element से पेज के उसी ID वाले element को replace किया जाता है
    • बटन element को बहुत ज़्यादा जानकारी पहले से जाननी पड़ती है, और server क्या लौटाएगा यह भी पहले से पता होना चाहिए, इसलिए HTMX का "locality of behavior" सिद्धांत कमजोर पड़ जाता है
  • Datastar का बेहतर तरीका

    <div>  
        <div id="alert"></div>  
        <button id="info-details"  
        data-on-click="@get('/info')">  
            Get Info!  
        </button>  
    </div>  
    
    • server वही ID रखने वाले दो root elements शामिल करते हुए HTML string लौटाता है
      <p id="info-details">These are the details you are looking for…</p>  
      <div id="alert">Alert! This is a test.</div>  
      
    • यह सरल और performance के लिहाज़ से बेहतर विकल्प है

component स्तर पर सोचना

  • बेहतर तरीका यह है कि HTML को components की तरह माना जाए
  • उस component की असल प्रकृति को समझा जाए
    • यूज़र किसी खास item के बारे में अतिरिक्त जानकारी कैसे प्राप्त करता है
    • यूज़र बटन क्लिक करे तो जानकारी दिखाई देती है, या जानकारी न होने पर error render होती है; दोनों ही स्थितियों में component एक स्थिर state में पहुँच जाता है
  • state के हिसाब से component अलग करना

    • placeholder state:
      <!-- info-component-placeholder.html -->  
      <div id="info-component">  
          <button data-on-click="@get('/product/{{product.id}}/info')">  
              Get Info!  
          </button>  
      </div>  
      
    • information display state:
      <!-- info-component-get.html -->  
      <div id="info-component">  
          {% if alert %}<div id="alert">{{ alert }}</div>{% endif %}  
          <p>{{product.additional_information}}</p>  
      </div>  
      
    • server HTML render करता है और Datastar पेज को अपने-आप update कर देता है
    • component-level सोच गलत state में जाने या user state खो देने से बचाती है

कई components को एक साथ update करना

  • David Guillot की प्रस्तुति में प्रभावशाली बात यह थी कि जब app पसंदीदा items की संख्या update करता था, तो बदला हुआ component और उससे बहुत दूर मौजूद count element भी साथ में update हो जाता था
    • HTMX में इसके लिए JavaScript event trigger करना पड़ता है, जो फिर remote component पर GET request trigger करता है
  • Datastar में synchronous function के भीतर भी कई components को एक साथ update किया जा सकता है
  • shopping cart उदाहरण

    • cart में item जोड़ने वाला component:
      <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>  
      
    • cart count दिखाने वाला component:
      <div id="cart-count">  
          <svg viewBox="0 0 10 10" xmlns="http://www.w3.org/2000/svg">  
              <use href="#shoppingCart">  
          </svg>  
          {{count}}  
      </div>  
      
    • Django में एक ही request से दोनों components update करना:
      from datastar_py.consts import ElementPatchMode  
      from datastar_py.django import (  
          DatastarResponse,  
          ServerSentEventGenerator as SSE,  
      )  
      
      def add_item(request):  
          # महत्वपूर्ण state update छोड़ा गया  
          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 दर्शन

  • Datastar Discord community के माध्यम से यह समझ आया कि Datastar सिर्फ helper script नहीं, बल्कि web के मूल primitives का उपयोग करके app बनाने की philosophy है
  • जहाँ HTMX HTML spec को आगे बढ़ाने की कोशिश करता है, वहीं Datastar web-native features को अपनाने में ज़्यादा रुचि रखता है
    • CSS view transitions
    • Server-Sent Events
    • Web Components आदि
  • जटिल AlpineJS components को refactor करके सरल Web Components निकालना और उन्हें कई जगह reuse करना एक बड़ी उपलब्धि रही
  • React जैसे tools के बिना भी custom HTML elements बनाकर उच्च locality of behavior और reusability हासिल करने का यह एक शानदार pattern है

multi-user apps के लिए रियल-टाइम updates

  • collaboration को first-class feature की तरह रखने वाले apps अलग दिखते हैं, और Datastar इस चुनौती को हल करता है
  • ज़्यादातर HTMX developers या तो polling के ज़रिए server से जानकारी लेते हैं, या custom WebSocket code लिखकर complexity बढ़ा देते हैं
  • Datastar Server-Sent Events(SSE) नाम की एक सरल web technology का उपयोग करता है, जिससे server connected clients को updates "push" कर सकता है
    • यूज़र comment जोड़ता है या state बदलती है, तो server तुरंत browser update कर देता है, और अतिरिक्त कोड बहुत कम लगता है
    • custom JavaScript के बिना भी रियल-टाइम dashboard, admin panel और collaboration tools बनाए जा सकते हैं
  • अगर client connection टूट जाए, तो browser अपने-आप reconnect की कोशिश करता है, और इसके लिए अतिरिक्त कोड नहीं चाहिए
    • server को "last received event" भी बताया जा सकता है

अनावश्यक जटिलता से बचना

  • Datastar Discord community ने web apps बनाने को लेकर Datastar की सोच समझने में मदद की
    • push-based UI updates
    • complexity में कमी
    • Web Components जैसे tools से local complex situations संभालना
  • community नए users को यह समझने में मदद करती है कि वे कहीं ज़रूरत से ज़्यादा जटिल approach तो नहीं अपना रहे

मुख्य सुझाव

  • पूरे component को फिर से render करके भेजने से डरना नहीं चाहिए
    • यह आसान है और performance पर बड़ा असर नहीं डालता
    • बेहतर compression मिल सकती है, और browser HTML string को बहुत तेज़ी से parse करता है
  • server ही source of truth है, और वह browser से ज़्यादा शक्तिशाली है
    • ज़्यादातर state server को संभालने दें; संभव है कि आपको उतने reactive signals की ज़रूरत ही न पड़े जितना आप सोचते हैं
  • Web Components ऐसे custom elements में logic encapsulate करने के लिए बेहतरीन हैं जिनमें locality of behavior ऊँची हो
    • Datastar website के header का starfield animation इसका अच्छा उदाहरण है
    • <ds-starfield> element starfield animation का सारा कोड encapsulate करता है और internal state बदलने के लिए तीन attributes expose करता है
    • Datastar range input बदलने या mouse के element पर move करने पर उन attributes को drive करता है

सीमाओं से आगे की संभावनाएँ

  • Datastar जो संभावनाएँ खोलता है, वही सबसे रोमांचक हिस्सा है
  • community नियमित रूप से ऐसे projects बनाती है जो दूसरे tools इस्तेमाल करने वाले developers की सीमाओं से बहुत आगे जाते हैं

उल्लेखनीय उदाहरण

  • example page पर database monitoring demo
    • Hypermedia का उपयोग करके JavaScript conference में दिखाए गए demo की speed और memory usage में बड़ा सुधार किया गया
  • Anders Murphy का 1 billion checkboxes
    • जब 1 million checkboxes वाला प्रयोग server capacity से बाहर चला गया, तो Datastar का उपयोग करके कम लागत वाले server पर 1 billion checkboxes लागू किए गए
  • एक web app जो अमेरिका के सभी radar stations का data दिखाता है
    • radar signal बदलते ही UI का संबंधित point 100 milliseconds के भीतर बदल जाता है
    • प्रति सेकंड 800,000 से अधिक points update होते हैं, और user अधिकतम 1 घंटे पीछे तक scrub कर सकता है (700 milliseconds से कम latency)
    • एक Hypermedia app के रूप में यह संभव होना दिखाता है कि Datastar क्या-क्या सक्षम कर सकता है

वर्तमान उपयोग अनुभव

  • अभी भी Datastar को explore करने के चरण में हूँ, और standard HTMX-style UI update AJAX handling को जल्दी और आसानी से implement कर पा रहा हूँ
  • Datastar से और अधिक हासिल करने के लिए अलग-अलग patterns सीख रहा हूँ और प्रयोग कर रहा हूँ
  • दशकों से रियल-टाइम updates के माध्यम से बेहतर user experience देने के तरीकों में रुचि रही है, और Datastar का synchronous code में भी push-based updates संभव बनाना अच्छा लगता है
  • HTMX का उपयोग शुरू करते समय जो बड़ा आनंद महसूस हुआ था, Datastar पर आने के बाद ऐसा नहीं लगा कि कुछ खोया है; बल्कि काफी ज़्यादा हासिल हुआ महसूस होता है
  • अगर HTMX इस्तेमाल करते हुए आपको खुशी मिली थी, तो Datastar में भी वही छलांग फिर महसूस होगी — जैसे web को उसका मूल काम करते हुए फिर से खोज लेना

2 टिप्पणियां

 
GN⁺ 2025-10-11
Hacker News की राय
  • Chris ने अपनी comfort zone से बाहर निकलकर चुनौती ली और वह अनुभव हमारे साथ साझा किया, इसके लिए आभार। मैं 4 साल से htmx के साथ webapp बना रहा हूँ, इसलिए थोड़ा पक्षपाती हो सकता हूँ, लेकिन मुझे लगता है कि Datastar और htmx के बीच मुख्य architectural अंतर साफ दिखता है: htmx HTML-driven है, जबकि Datastar server-driven है। यह सच है कि client-side API सरल है, लेकिन ऐसा इसलिए है क्योंकि server-side logic अधिक जटिल हो जाता है। उदाहरण के लिए, अगर HTML element को यह जानकारी नहीं है कि server से लौटा fragment कहाँ insert करना है, तो वह जानकारी server side पर रखनी पड़ती है, यानी जटिलता किसी न किसी तरफ तो रहेगी ही। architectural choice मुझे पसंद-नापसंद का मामला लगता है। उदाहरण में ‘less attributes’ वाली दलील 100% निष्पक्ष नहीं लगती, क्योंकि उसमें htmx के ऐसे optional attributes भी गिन लिए गए हैं जिन्हें लगाना ज़रूरी नहीं है; जैसे hx-trigger="click" हटा दें तो 20% attributes कम हो जाते हैं। और <span> की जगह <button> जैसे अधिक accessible HTML का उपयोग किया जाए तो तर्क और विश्वसनीय लगेगा। आखिरकार Datastar की ताकत यह लगती है कि Alpine या Stimulus जैसी क्षमताएँ इसमें built-in हैं, और यह वाकई प्रभावशाली है
    • Datastar का उपयोग करें तो पेज के दूसरे हिस्सों को real-time में अपडेट करने के लिए अलग से eventing implement करने की ज़रूरत नहीं पड़ती; एक बार में सब कुछ नीचे भेजकर अपडेट किया जा सकता है, इसलिए complexity काफी कम हो जाती है। हालांकि, कुछ स्थितियों में event-based तरीका या बाद में लोड करना बेहतर हो सकता है
    • “Alpine या Stimulus की functionality HTMX में built-in हो” वाली बात देखकर मैं सोच रहा हूँ कि क्या personal project के लिए HTMX चुनूँ। क्या ऐसा कोई resource है जो समझाता हो कि AlpineJS या Stimulus जैसी अतिरिक्त library वास्तव में ज़रूरी होती है?
    • अगर HTML element में यह जानकारी न हो कि fragment किस जगह insert करना है, और server को यह पता रखना पड़े, तो क्या ऐसे में frontend हल्का और तेज़ नहीं हो जाएगा? खासकर तब जब elements बहुत अधिक हों?
    • यह संरचना कुछ हद तक Pharo के Seaside framework जैसी लगती है। हमारी कंपनी में जब हम Pharo से B2B apps बनाते थे, तब UI state backend पर manage होने के कारण frontend और backend के बीच बहुत आना-जाना होता था। real-time या latency जहाँ महत्वपूर्ण नहीं है, ऐसे B2B में यह ठीक है, लेकिन highly scalable B2C app में यह उपयुक्त नहीं है
  • Datastar और HTMX दोनों खुद इस्तेमाल करने के बाद भी, Datastar के साथ app बनाते समय बहुत बड़ा अंतर क्या होगा, यह अभी तक साफ नहीं है। मैं FastAPI, HTMX, Alpine.js, और SSE को साथ में इस्तेमाल करके real-time log display, deploy status updates जैसी चीज़ें कर रहा हूँ। Datastar के examples देखकर मुझे समझ नहीं आता कि यह setup उससे कितना अधिक सरल बनाता है। (कोड संदर्भ: devpush SSE partial). Web Components भी पहले Basecoat बनाते समय आजमाए थे, लेकिन styling issues, state management वगैरह के कारण अंततः फिर से पारंपरिक HTML/CSS/JS पर लौट आया। devpu.sh, basecoatui.com
    • HTMX में भी Datastar जैसी functional extensibility पर विचार करें तो अक्सर पूरी list को एक साथ refresh कर देना ज़्यादा सरल हो जाता है। हर individual deploy status को update करने की बजाय पूरी list अपडेट कर दी जाए तो pagination जैसे edge cases की चिंता नहीं रहती, इसलिए चीज़ें बहुत सरल हो जाती हैं और code भी हल्का रहता है
  • अगर किसी को लगता है कि Datastar real-time/collaboration/multiplayer के लिए पर्याप्त नहीं है, तो मैं 3 demos दिखाना चाहता हूँ जो PRO features के बिना चलते हैं और यहाँ तक कि 5 डॉलर के VPS पर Hacker News front page तक पहुँचे थे। ये दिखाते हैं कि Datastar कितनी अच्छी तरह बना हुआ है: Checkboxes, Cells, Game of Life Example. Checkboxes और Cells examples में view rendering काफी fluid है, इसलिए बहुत ज़्यादा zoom out किया जा सकता है, और virtual scrolling में backpressure भी है
    • अगर मैंने code structure सही समझा है, तो लगता है कि यह वास्तव में datastar की recommended diff/patch approach का उपयोग नहीं करता, बल्कि हर बार पूरा page फिर से render करता है। सच कहूँ तो server पर client state को बारीकी से track करने वाले examples की तुलना में यह mental model कहीं अधिक सरल लगता है, इसलिए मुझे यह और आकर्षक लग रहा है। उत्सुकता है कि क्या सामान्य जटिल apps भी इस तरीके से बनाए जा सकते हैं। जब user अलग-अलग pages पर जाते हैं और विभिन्न widget states को track करते हुए तुरंत re-render करना हो, तो यह कैसे किया जाए—इस पर कोई अच्छा text हो तो बताइए
    • Checkboxes/Cells examples में कहा गया कि zoom out किया जा सकता है, लेकिन यह ठीक-ठीक कैसे होता है, यह जानना चाहूँगा। और अगर current view के URL को संबंधित coordinates (x=123&y=456 आदि) के साथ अपने-आप update करने के लिए data-replace-url जैसा कोई option होता, तो और अच्छा लगता
    • PRO features वाली बात देखकर पता चला कि यह open-core model है (कुछ हिस्सा open source, बाकी paid, 299 डॉलर license)। मैं इसे छोड़ना चाहूँगा
  • हाल ही में मैंने यह लेख पढ़ा (htmx, datastar, greedy developer), और सुना कि Datastar की कुछ अच्छी core features paid (Pro) में डाल दी गई हैं। चाहे open source हो या paid, मैं framework को financially support करना चाहता हूँ, लेकिन ऐसा precedent थोड़ा चिंताजनक लगता है
    • मैं भी Datastar को कई महीनों से follow कर रहा था और 1.0.0 release का इंतज़ार कर रहा था, लेकिन अब मेरा उत्साह पूरी तरह खत्म हो गया है। “open source है, लेकिन वास्तव में नहीं” जैसी चीज़ों का कई बार सामना कर चुका हूँ, इसलिए भरोसा नहीं बनता
    • सच तो यह है कि मैं पहले लिख चुका हूँ कि मुझे Datastar बहुत पसंद नहीं, लेकिन इस बार उसका थोड़ा बचाव करने का मन है। framework बनाने वाले ने अपना code MIT license के तहत मुफ़्त जारी किया था, इसलिए जो features पहले free जारी हुए थे, उन्हें अब भी MIT के तहत इस्तेमाल किया जा सकता है। अगर आपने योगदान दिए बिना सिर्फ इस्तेमाल किया है, तो पुराने version पर निर्भर रहना आपका अपना चुनाव है। अब आगे paid model अपनाना product owner की स्वतंत्रता है, और ज़रूरत हो तो बस fork कर लीजिए
    • मैंने 299 डॉलर देकर PRO license खरीदा है, लेकिन अभी तक PRO features का वास्तव में इस्तेमाल नहीं किया। मैं एक Google Sheets clone बनाना चाहता था, लेकिन PRO के बिना भी वह पर्याप्त रूप से संभव था। (cells demo देखें)
    • मुझे कभी-कभी लगा कि Datastar की तरफ़ से HTMX Discord में Datastar कितना अच्छा है यह लगातार promote करने से आगे बढ़कर थोड़ा aggressive रवैया दिखता है। reddit पर भी मैंने ऐसे comments देखे हैं जिनका भाव था, “अगर ज़रूरी features सब हैं, तो beta forever इस्तेमाल करो; open source किसी का ऋणी नहीं है”
    • Datastar का उपयोग करते समय मुझे पुराने Meteor.js का मामला तुरंत याद आ गया। (Meteor.js HN चर्चा)
  • इस पोस्ट में दिए गए example code मुझे ठीक से समझ नहीं आते। उदाहरण के लिए, नीचे वाला htmx example <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> शायद इस तरह के datastar code में बदलता है: <span data-on-click="@get('/rebuild/status-button')"></span> और आगे के दूसरे examples तो और भी उलझाने वाले हैं। आखिर htmx से Datastar पर जाने की वजह मुझे समझ नहीं आती
    • मूल रूप से HTMX का मतलब है: “इस span पर click होने पर /rebuild/status-button से HTML लाओ, फिर लौटे हुए HTML में से #rebuild-bundle-status-button element चुनो और मौजूदा element को replace करो।” जबकि Datastar का मतलब है: “span पर click होने पर /rebuild/status-button से मिले निर्देशों का पालन करो।” अगर server कई ID वाले elements लौटाता है, तो Datastar उन्हें पहचानकर संबंधित elements को अपने-आप replace कर देता है। यानी target, select, swap सब लिखने की ज़रूरत नहीं; सिर्फ ID होने से इच्छित behavior मिल जाता है
    • Datastar की संरचना backend में logic को केंद्रित कर देती है। यह पुराने पारंपरिक HTML की तरह है जहाँ request भेजो, HTML पाओ और browser render कर दे; लेकिन Datastar में एक बार page लोड होने के बाद हर interaction पर backend को request जाती है और केवल बदलाव लाकर apply किए जाते हैं। यह उस SPA (single-page app) का उल्टा ढाँचा है जिसमें frontend logic नहीं होता और backend सारी state manage करता है। मूल रूप से backend/frontend logic distribution की वही पुरानी बहस दोहराई जा रही है, लेकिन Datastar server (backend) पर logic केंद्रित रखते हुए भी dynamic interface बनाए रखने देता है
    • लेकिन click के लिए span tag क्यों इस्तेमाल किया जा रहा है, यह समझ नहीं आता। button या link tag ज़्यादा उचित नहीं होगा?
  • विडंबना यह है कि इस लेख का विषय hypermedia है, लेकिन Datastar की official site का link ही नहीं है। वह यहाँ है: https://data-star.dev/
  • HTMX की बड़ी खूबियों में से एक यह है कि client को server से लौटने वाले data structure के बारे में पता होने की ज़रूरत नहीं होती, लेकिन अगर client को individual elements की ID या अर्थ तक जानना पड़े तो लगता है कि यह वादा टूट जाता है। हालाँकि व्यवहार में कई projects में OOB (Out of Band) का उपयोग होता ही है, इसलिए पूर्ण structural separation शायद वास्तविकता से कुछ दूर भी है। अच्छा होगा अगर दोनों दुनियाओं के फायदे मिलाने का कोई रास्ता निकले
    • वास्तव में client को कुछ भी जानने की ज़रूरत नहीं है। client पर action चलाते ही server पूरे page का view भेज सकता है। client उसे तुरंत render कर देता है। यह video game के immediate mode model जैसा है
  • Datastar का यह server-side HTML patching वाला ढाँचा separation of concerns के लिहाज़ से अच्छा नहीं लगता, और app जितना बड़ा होगा, server से HTML के हिस्से inject करते रहना उतना ही झंझटभरा लगेगा
    • लेकिन अगर JS अलग-अलग जगहों से fragment के रूप में HTML inject करने लगे, तो वह भी ज़रूरी नहीं कि बेहतर हो
    • server से HTML fragments देने वाले endpoints की यह design approach मुझे थोड़ी अटपटी लगती है
  • Datastar मुझे htmx से अधिक polished लगता है। मैंने htmx से कई projects सफलतापूर्वक बनाए हैं, लेकिन event handling के कारण JS glue code (खासकर AlpineJS आदि) अलग से जोड़ना पड़ता था, यही बात हमेशा खलती रही। अगर Datastar इस ज़रूरत को भी कम कर दे, तो यह सचमुच रोमांचक होगा
    • Datastar site पर grugs around the fire essay पढ़ने की सिफारिश करता हूँ
  • मैं hypermedia trend से अपेक्षाकृत देर से जुड़ा, लेकिन पहले Datastar इस्तेमाल किया और अब इन दिनों HTMX की तरफ़ आ गया हूँ। Datastar API कुछ बेहतर है, लेकिन htmx 2.0 में OOB (Out-Of-Band) updates आने के बाद से मैं ज़्यादातर htmx के पक्ष में हूँ
    • “hypermedia में देर से आया” वाली बात दिलचस्प लगी। Ted Nelson ने 1965 में पहली बार यह शब्द इस्तेमाल किया था, और उस समय उन्होंने कहा था कि “hyperfilm— a browsable or vari-sequenced movie— is only one of the possible hypermedia that require our attention”. संबंधित paper देखें
    • HTMX में OOB elements संभालते समय मेरी शिकायतें: 1. अगर OOB है तो htmx-swap-oob="true" अनिवार्य है, वरना यह अपेक्षा के अनुसार काम नहीं करता 2. उल्टा, अगर OOB नहीं है तो htmx-swap-oob="true" होने पर वह ignore हो सकता है या गड़बड़ कर सकता है। इस वजह से एक ही component को OOB/non-OOB दोनों रूप में reuse करने के लिए server से हर बार isOob flag भेजना पड़ता है, जो बहुत झंझट है
    • मुझे alpine-ajax का API ज़्यादा पसंद है। सिर्फ कई targets निर्दिष्ट कर दें, तो बिना JS के अलग-अलग elements को एकसमान तरीके से replace कर देता है। Datastar का signal/state concept मुझे उल्टा complexity बढ़ाने वाला लगता है, इसलिए पसंद नहीं आता