</> Htmx – The Fetch()ening

• htmx 4.0 मौजूदा XMLHttpRequest-आधारित संरचना को पूरी तरह fetch()-केंद्रित asynchronous संरचना से बदलने वाला एक बड़ा rebuild version है
• attribute inheritance पद्धति को implicit से बदलकर :inherited explicit declaration किया गया है, जिससे code clarity और maintainability बेहतर होती है
• history cache को local snapshot storage के बजाय network request-आधारित restore पद्धति में सरल बनाया गया है, जिससे stability बढ़ती है
• streaming responses, SSE, DOM morphing, <partial> tag, View Transition queue जैसी कई नई features को core में शामिल किया गया है
• लंबे समय में codebase simplification और extensibility improvement, और मौजूदा 2.0 users के लिए भी लगातार support की योजना

---

htmx 4.0 का overview

• htmx 4.0 मौजूदा संरचना को पूरी तरह फिर से लिखता है, और इसमें fixi.js development experience तथा 5 साल के maintenance lessons को शामिल किया गया है
• मुख्य बदलावों को 3 core changes में संक्षेपित किया जा सकता है: fetch() migration, explicit attribute inheritance, और history cache simplification

The fetch()ening

• Ajax infrastructure को modernize करने के लिए XMLHttpRequest को fetch() से बदला गया है
  • ज़्यादातर use cases पर इसका बड़ा असर नहीं होगा, लेकिन event model fetch() की asynchronous प्रकृति के अनुसार बदलेगा
• यह बदलाव code simplification और future feature expansion के लिए आधार देता है

explicit attribute inheritance

• मौजूदा implicit inheritance की जगह अब :inherited modifier के साथ explicit declaration किया जाएगा
  • उदाहरण:

    <div hx-target:inherited="#output">
        <button hx-post="/up">Like</button>
        <button hx-post="/down">Dislike</button>
    </div>
    

  • अगर hx-target को explicit रूप से घोषित नहीं किया गया, तो child elements उसे inherit नहीं करेंगे
• ज़्यादातर users के लिए यह सबसे बड़ा upgrade change है

history cache simplification

• htmx 2.0 का local DOM snapshot cache third-party modifications, hidden state आदि के कारण unstable था
• 4.0 में इसे network request के जरिए restore करने वाले approach में बदल दिया गया है
  • cache expansion को optional (opt-in) रूप में दिया जाएगा
• इससे codebase सरल होता है और default behavior की reliability बढ़ती है

जो तत्व बने रहेंगे

• hx-get, hx-post, hx-target, hx-boost, hx-swap, hx-trigger जैसे core API वही रहेंगे
• :inherited जोड़ने के अलावा, ज़्यादातर projects में मौजूदा code वैसे ही काम कर सकता है
• long-term maintainability और stability बेहतर होगी

upgrade policy

• 2.0 users को upgrade project की ज़रूरत होगी, लेकिन 2.0 को स्थायी support मिलता रहेगा
• 4.0 को 2.x के साथ parallel distribution में जारी किया जाएगा, और latest में switch 2027 की शुरुआत में अपेक्षित है
• 2.0 behavior को restore करने वाला extension भी दिया जाएगा

नई features का सार

streaming responses और SSE integration

• fetch() के Readable Streams support का उपयोग करके partial DOM replacement संभव होगा
• SSE(Server Sent Events) को core feature के रूप में फिर से integrate किया गया है, जिससे progressive content updates संभव होंगे

Morphing Swap

• Idiomorph algorithm के आधार पर DOM merge के दौरान node preservation और deletion decisions बेहतर किए गए हैं
• morphInner, morphOuter swap को core में शामिल किया गया है

<partial> tag support

• मौजूदा Out-of-band swap की जटिल syntax को सरल बनाया गया है
• <partial> एक template element है, जिसमें hx-target, hx-swap जैसे standard attributes इस्तेमाल किए जा सकते हैं
• Out-of-band swap को फिर से id-based simple replacement तक सीमित किया गया है

View Transition improvements

• visual conflicts को रोकने के लिए transition queue जोड़ी गई है
• CSS transitions मौजूदा तरीके से ही काम करेंगे, लेकिन asynchronous runtime के कारण संरचना सरल होगी
• यह default रूप से enable होगा या नहीं, यह अभी तय नहीं है

event order stabilization

• fetch()-आधारित asynchronous संरचना के कारण event order guarantee करना आसान होगा
• एक नया event naming convention पेश किया गया है:
  htmx:<phase>:<system>[:<optional-sub-action>]
  • उदाहरण: htmx:before:request

extensibility improvement

• async के आधार पर preload और optimistic update extensions दिए जाएंगे
• request/response/swap cycle को extension developers के लिए खोल दिया जाएगा, और fetch() implementation भी बदली जा सकेगी
• बिना hack के मनचाहा behavior implement किया जा सकेगा

hx-on improvements

• standardized syntax hx-on:<event name> अपनाया गया है
• asynchronous API support के साथ simple DOM scripting संभव है

  <button hx-post="/like"
          hx-on:htmx:after:swap="await timeout('3s'); ctx.newContent[0].remove()">
      Get A Response Then Remove It 3 Seconds Later
  </button>
  

• eval() disabled environment में भी यह काम करेगा, हालांकि कुछ features सीमित रहेंगी

overall direction

• htmx 4.0 का लक्ष्य 2.0 जैसा familiar usage experience बनाए रखते हुए bugs कम करना और features बेहतर बनाना है
• code simplification, explicit structure, और asynchronous extensibility के जरिए ज़्यादा stable और modern htmx उपलब्ध कराया जाएगा

development timeline

• alpha version(htmx@4.0.0-alpha1) अभी उपलब्ध है
• official 4.0.0 release 2026 की शुरुआत से मध्य तक अपेक्षित है
• 2027 की शुरुआत में इसे latest बनाया जाएगा
• development progress को GitHub four branch और four.htmx.org पर देखा जा सकता है

---

[GN⁺]

Hacker News राय

• आखिरकार उन्होंने अपना मन बदल लिया और htmx का नया major version जारी करने का फैसला किया
  लेकिन, “3.0 नहीं होगा” वाले वादे को निभाने के लिए अगले version का नाम htmx 4.0 रखा
  इस पर हल्के-फुल्के अंदाज़ में कहा गया कि तकनीकी रूप से यह सही है

  • यह मज़ेदार समाधान है, लेकिन पहले गायब हो चुके PHP 6 की तरह यह यूज़र्स में भ्रम भी पैदा कर सकता है
    शायद ईमानदारी से इसे 3.0 ही जारी करना बेहतर होता
  • मज़ाक में कहा गया कि सीधे htmx 4.1 पर चले जाएँ और “xhtmx 1.0” बना दें
  • कहा गया कि इसमें Leisure Suit Larry 4: The Missing Floppies जैसी भावना आती है
  • यह भी कहा गया कि अच्छा हुआ उन्होंने “तीसरा version है ही नहीं” ऐसा नहीं कहा था, इसलिए अभिव्यक्ति की थोड़ी गुंजाइश बची रही

• कहा गया कि htmx 2.0 को स्थायी रूप से support किया जाएगा, इसलिए upgrade करने का कोई दबाव नहीं है
  आज के बार-बार बदलते API वाले दौर में इस तरह का रवैया सराहनीय है

• लगा कि स्थिरता चाहने वाले लोग अक्सर इससे गलत सीख ले लेते हैं
  Python 3.0 की तरह एक बार में बड़े बदलाव ठूँसने के बजाय, क्रमिक release strategy बेहतर है
  उदाहरण के लिए 2.1, 4.0, 5.0 जैसी releases में बदलाव बाँटकर लाए जाएँ तो उन्हें संभालना बहुत आसान होता है
  Django की तरह कई versions में compatibility चरण बनाए रखने का तरीका अपनाने की सिफारिश की गई

• hx-target attribute का विवरण उलझाऊ लगा
  “inherited” की जगह “inheritable” या “inherit” ज़्यादा स्वाभाविक लगता है

  • एक व्यक्ति ने कहा कि उसने इसे “बच्चा विरासत में लेता है” वाले अर्थ में पढ़ा, इसलिए “pass-down” जैसा शब्द ज़्यादा स्पष्ट हो सकता है
  • कहा गया कि “inherited” गलत शब्द है और “inherit” छोटा और बेहतर है
    मज़ाक में “bequeath” भी सुझाया गया
  • कहा गया कि वे कई अभिव्यक्तियों पर विचार कर रहे हैं और सुझाव स्वीकार करने को तैयार हैं
  • “heritable” या “cascade” जैसे विकल्प भी सामने आए

• HTMX का विचार और Hypermedia दर्शन शानदार लगा
  SPA माहौल से निकलकर Datastar चुना गया, क्योंकि सीखने में लगाए गए प्रयास के मुकाबले इसकी scalability ज़्यादा लगी
  सर्वर से ब्राउज़र तक signals को सीधे push करके polling code हटा दिया गया, जिससे complexity काफी कम हुई
  Alpine.js पर निर्भरता भी खत्म हो गई, इसलिए code सरल हुआ, और streaming-आधारित full view refresh भी compression की वजह से प्रभावी ढंग से काम करता है
  अगर आप SPA पृष्ठभूमि से आते हैं, तो Datastar और HTMX दोनों आज़माने की सलाह दी गई

• fetch() पर स्विच करके Readable Stream का उपयोग करना दिलचस्प लगा
  HTMX का काफी इस्तेमाल करने के बावजूद, Datastar की SSE-आधारित streaming ज़्यादा आकर्षक लगी, इसलिए इन दिनों उसी को प्राथमिकता दी जा रही है

• HTMX की प्रगति का स्वागत किया गया, लेकिन Datastar को अधिक standards-friendly और flexible API देने वाला माना गया
  कहा गया कि छोटे से package में Fetch, SSE, declarative signals, DOM morphing जैसी कई सुविधाएँ शामिल हैं
  इसलिए सवाल उठाया गया: “फिर HTMX क्यों इस्तेमाल करें?”

  • बताया गया कि Datastar Pro open source नहीं है, इसलिए उस पर भरोसे से जुड़े जोखिम हैं
  • यह विडंबना भी बताई गई कि Datastar के निर्माता पहले HTMX में ऐसे features जोड़ना चाहते थे
  • समझाया गया कि HTMX की ताकत request/response paradigm के लिए अनुकूल सरल interface है
    Datastar event stream-केंद्रित है, इसलिए real-time dashboard या games के लिए उपयुक्त हो सकता है, लेकिन ज़्यादातर web apps के लिए HTMX की सरलता अधिक फ़ायदेमंद है
    संबंधित संदर्भ: Datastar निबंध, Less HTMX is More
  • कहा गया कि HTMX ब्राउज़र की URL history management को आसानी से support करता है, जबकि Datastar ने इस feature को paid (Pro) तक सीमित रखा है

• “यह इतना परफेक्ट है कि अब कोई major version नहीं आएगा” जैसी बात से आखिरकार विकास की ज़रूरत को मान लेने पर चुटकी ली गई
  “अब event naming standard बदला जाएगा” वाले हिस्से का हवाला देते हुए इसे JavaScript से बचने की कोशिश पर व्यंग्य कहा गया

  • तंज कसते हुए कहा गया, “आखिर JavaScript न लिखने की कोशिश में custom syntax को JS से interpret करवाने तक बात पहुँच गई”
    फिर भी यह माना गया कि HTML में इरादा व्यक्त कर पाने की सुविधा उपयोगी है
  • मज़ाक में कहा गया, “शायद यही सचमुच आखिरी version होगा”
  • इसे सकारात्मक रूप से लेते हुए कहा गया, “फिर भी JavaScript सीधे लिखने से तो बेहतर है”
  • यह भी कहा गया कि “लेखक की सोच बदल गई तो इसमें दिक्कत क्या है?”, और आलोचनात्मक लहज़े पर सवाल उठाया गया

• कहा गया कि लेख बहुत स्पष्ट था और उससे API design philosophy के बारे में काफी कुछ सीखा जा सकता है

• fetch और HTMX को साथ इस्तेमाल करने के लिए xhr-fetch-proxy बनाया गया था,
  और कहा गया कि इस बदलाव से अब और ज़्यादा संभावनाएँ खुलेंगी
  प्रोजेक्ट लिंक

  • कहा गया कि 4.0 में request cycle पूरी तरह खुली होगी, इसलिए हर request पर fetch implementation को बदला जा सकेगा
    यह विचार fixi.js से सीखा गया बताया गया