Htmx पर एक संतुलित आलोचना

• Htmx का बुनियादी और सरल विचार वाकई पसंद आता है, लेकिन पूरी टीम में इसका इस्तेमाल करने के बाद पता चला कि व्यवहार में यह सरल नहीं बल्कि काफ़ी जटिल है

Htmx attribute inheritance निश्चित रूप से एक गलती है

• कोड के टुकड़ों में attribute inheritance अप्रत्यक्ष है और चौंकाने वाला लगता है
• CSS की तरह inheritance एक सस्ता hack है, लेकिन इसकी कीमत चुकानी पड़ती है
• यह लेखक के locality of behavior वाले दावे के विपरीत है
• कई attributes में default inheritance अलग है (उदाहरण: hx-delete inherit नहीं होता, लेकिन hx-confirm और hx-ext inherit होते हैं)
• अपवाद याद रखने पड़ते हैं और हर चीज़ को explicitly लिखना पड़ता है, जिससे inheritance बेमानी हो जाता है

ज़्यादातर दिलचस्प web apps DOM elements को पूरी तरह replace नहीं कर सकते

• DOM elements के पास लगभग हमेशा browser-local state होती है (उदाहरण: <details> element का open/closed state, <input> element का input value, dropdown element का open/closed state)
• जब Htmx outerHTML को सीधे replace करने वाला सरल तरीका अपनाता है, तो यह सारी state खो जाती है
• Morphdom extension भी उम्मीद के विपरीत कुछ elements को overwrite कर देता है

DOM elements के भीतर ही state store करना एक बुरा विचार है

• Morphdom पिछले खंड की समस्या हल करने के लिए है, लेकिन पता चलता है कि Htmx का काम करने का तरीका elements को wholesale replace करने पर आधारित है
• यह request queue को DOM elements के भीतर ही store करता है
• जब कोई request शुरू होती है, तो उस element या उसे point करने वाले किसी दूसरे element पर request queue बनती है
• DOM element को पूरी तरह replace करने पर queue reset हो जाती है, जिससे कुछ खराब failure modes से बचा जा सकता है
• लेकिन Morphdom में element बचा रहता है, इसलिए queue भी बची रहती है
• इससे एक तरह का undefined behavior वाला क्षेत्र बन जाता है, जहाँ Htmx का design टूटता हुआ लगता है

default queueing mode बिखरा हुआ है

• default रूप से, अगर Htmx उसी queue (element) में कोई दूसरी request trigger करता है, तो वह चल रही request को cancel कर देता है
• यही default strategy है
• यह बात लेखक को बाद में पता चली
• यह बहुत ही गैर-स्वाभाविक है और इसका मतलब है कि काम खो सकता है

event triggers स्थानीय नहीं होते

• event triggers अक्सर कुछ घटित कराने में मदद करते हैं, लेकिन उनके effects स्थानीय नहीं होते, और उनमें attribute inheritance जैसी ही समस्याएँ हैं
• server-side language में DSL का उपयोग करके इसे कुछ हद तक संभाला जा सकता है, लेकिन यह पुराने JavaScript callback-based programming जैसा महसूस होता है
• event होने पर आप उसे "subscribe" करते हैं और कुछ करते हैं

component state को ठीक से बनाए रखना मुश्किल है

• DOM element state वाली समस्या जैसी ही, लेकिन उससे भी व्यापक समस्या यह है कि आपके अपने components की भी अपनी state होती है
  • उदाहरण के लिए, अगर आप तीन sections वाला एक page चाहते हैं, जिनकी अपनी state server के लिए ज़रूरी हो (जैसे result set का page), और React या WebComponents के लिए भी state हो, तो parent और child components के बीच state sync करने की समस्या आती है
• Htmx इसके लिए कोई अच्छा तरीका नहीं देता
  • query parameters, hidden form inputs, event triggers आदि के कुछ विचार हैं, लेकिन सभी के साथ बड़े caveats हैं
• React और Halogen के पास इसका जवाब है
  • दोनों में child components की अपनी state होती है, और parent "advice" जैसी "props" दे सकता है
  • उनकी अपनी internal state भी होती है, जो props को ignore कर सकती है या उन पर priority ले सकती है
  • props आम तौर पर server से आती हैं या server से derive होती हैं, जबकि state आम तौर पर client-side state होती है
• तैयार React components, या वे components जिन्हें इस्तेमाल करना ज़रूरी हो, अक्सर React की मांग करते हैं
  • React और Htmx साथ में अच्छी तरह काम नहीं करते
  • लेखक ने WebComponents के साथ कुछ संतोषजनक नहीं रहने वाला काम किया, लेकिन उनमें हैरान करने वाली अजीब सीमाएँ हैं
  • server-side language से उपयोग होने वाले React components तक सीधे bridge भी बनाए गए, लेकिन आम तौर पर Htmx और React state flow और DOM element management को लेकर लड़ते रहते हैं
  • Alpine आज़माया गया, जो अच्छा है, लेकिन वह एक और client-side programming library है, इसलिए अगर codebase में React पहले से है तो यह दोहराव बन जाता है

फिर भी इसके फ़ायदे हैं

• server-side language का उपयोग कर पाना बहुत बड़ा, साफ़ और निर्विवाद लाभ है
• टीम में कोई भी यह सारा business logic TypeScript में फिर से नहीं लिखना चाहेगा
• DB types से frontend types तक serialization की ज़रूरत नहीं होती
  • न data leak होता है, न GraphQL की ज़रूरत पड़ती है
• server-side language की ज़्यादा शक्तिशाली abstraction क्षमता का उपयोग किया जा सकता है
• एक ही validation के लिए frontend और backend दोनों implementations करने के बजाय server-side language के form builders का उपयोग किया जा सकता है
• लेकिन ऊपर बताए गए नुकसान भी वास्तविक हैं

Htmx-in-React?

• एक आकर्षक भविष्य दिशा यह हो सकती है कि React में Htmx को फिर से implement किया जाए
  • server अगर JSON blob भेजे, तो React उसे virtual DOM components में बदल दे
  • तब component state की समस्या हल हो सकती है
  • React components का उपयोग करने के लिए किसी विशेष bridge की ज़रूरत नहीं होगी
  • React से जुड़े web fetching libraries का उपयोग किया जा सकेगा, और Htmx की एक खास queueing choice से सावधानी से बचा जा सकेगा
  • Morphdom की समस्या और browser DOM input elements की समस्या भी हल हो जाएगी, क्योंकि React में ये लगभग हल की हुई समस्याएँ हैं
• इस तरह Htmx dependency हटाते हुए भी उसके विचारों के लाभ बनाए रखे जा सकते हैं, बशर्ते इतना बड़ा काम शुरू करने का बजट उपलब्ध हो

GN⁺ की राय

• Htmx का मूल विचार आकर्षक है, लेकिन वास्तविक उपयोग में कई जटिल समस्याओं का सामना करना पड़ सकता है
• attribute inheritance, DOM element replacement, queueing mode जैसी Htmx की कुछ designs सहज नहीं हैं और अनपेक्षित व्यवहार पैदा कर सकती हैं
• React या WebComponents के साथ integration भी आसान नहीं लगता
• इसके बावजूद server-side language का उपयोग कर पाना एक बड़ा फ़ायदा है
• आगे चलकर React-आधारित Htmx reimplementation भी एक दिलचस्प दिशा हो सकती है

[felizgeek]

दिलचस्पी, उदासीनता से बेहतर है~ मुझे HTMX पसंद है। उसकी philosophy भी।
SQLite से भी इसका vibe काफ़ी मिलता-जुलता है, हाहा

[savvykang]

SQLite और HTMX किस तरह से समान हैं?

[aer0700]

Sqlite जैसा?

[halfenif]

टिप्पणी गहरी है। दर्शनशास्त्र, हाँ..

[savvykang]

अगर आपके पास SPA आने से पहले server-side rendering और jQuery के साथ web development करने का अनुभव है, तो आप तुरंत समझ जाएंगे कि यह उसी तरह की तकनीक है। शायद जो लोग SPA के साथ web development में आए हैं, वे कुछ नया खोजते-खोजते इसे गलत समझ रहे हैं।

[heycalmdown]

मुझे लगता है कि यह लेख कोरिया में लिखा गया लेख नहीं है।

[ndrgrd]

सही कहा। यह शायद साधारण पेजों के लिए बनाया गया टूल है, लेकिन अजीब उदाहरण या use case लाकर यह बहस क्यों होती है कि यह उसके लिए उपयुक्त नहीं है, यह मुझे समझ नहीं आता।

[roxie]

जैसा कि htmx के मुख्य पेज से समझा जा सकता है, htmx का रुख़ लगभग ऐसा है कि (अगर सिर्फ़ वही हो) तो react सहित modern frontend technologies की ज़रूरत नहीं है।

[rlrsbtm80879]

यह htmx के ध्यान आकर्षित करने की वजह से जुड़ा हुआ है। यह लेख भी एक विदेशी योगदान लेख का अनुवाद है, और विदेशों में लोग react के तरह-तरह के state management से थक चुके हैं। इसलिए react जैसी सुविधाएँ देने के बावजूद react की तरह state management की ज़रूरत न रखने वाले htmx को react के विकल्प के रूप में देखा गया। इसी वजह से htmx की तुलना बार-बार react से की जाती है।

[ndrgrd]

खैर। अगर वजह वही है, तो क्या React को replace कर सकने का दावा करने वाली किसी चीज़ को लाकर उसकी तुलना करना सही नहीं होगा?

इस पेज पर सूचीबद्ध features को ही देखें, तो HTMX कोई ऐसी चीज़ नहीं है जिसे complex page में डाला जा सके, और यह बिल्कुल भी ऐसा कुछ नहीं है जो React को replace कर सके।

[GN⁺]

Hacker News राय

• attribute inheritance पर राय बंटी हुई है। इसे htmx.config.disableInheritance option से disable किया जा सकता है

  • client-side state और htmx replacement हमेशा अच्छे से मेल नहीं खाते। खासकर simple cases में
  • events शक्तिशाली हैं, लेकिन complex हैं और debug करना कठिन है। यह event-driven programming की प्रकृति है
  • default queue mode से सहमत नहीं हैं। मौजूदा request को cancel करके replace करने के बजाय, current request को बनाए रखता है और सिर्फ एक additional request को queue में रखता है
  • htmx को नापसंद करने वालों के लिए mug का प्रचार

• frontend में नहीं कूदने का कारण यह है कि विकल्प बहुत हैं, आलोचना बहुत है, और tech trends अक्सर बदलते रहते हैं

  • backend और systems programming में भी मतभेद होते हैं, लेकिन frontend जितना भ्रमित करने वाला नहीं है

• HTMX का उपयोग करके high-performance storefront बना रहे हैं, और नतीजे संतोषजनक हैं

  • Brazil के एक बड़े clothing retailer में HTMX और partial rendering strategy का उपयोग हो रहा है

• "HTMX in React" का विचार React Server Components को फिर से आविष्कार करने जैसा है

  • server JSON भेजता है और React उसे virtual DOM components में बदल देता है
  • component state की समस्या हल हो सकती है, और किसी special bridge के बिना React components का उपयोग किया जा सकता है
  • React से जुड़ी web fetching libraries का उपयोग किया जा सकता है, और HTMX की queue choice से बचा जा सकता है
  • morphdom issues और browser DOM input element issues को हल किया जा सकता है
  • RSC अभी भी experimental है, और default implementation मानती है कि server पर JS चलता है

• default queue mode को अव्यवहारिक मानने वाली राय से सहमत नहीं हैं

  • अगर user input submit करता है, बीच में उसे बदलता है, और फिर से submit करता है, तो request cancel हो जाना चाहिए
  • अगर response किसी दूसरे ID के content को replace करता है, तो दूसरा response उसी तरह replace नहीं कर सकता

• HTMX को पहली बार इस्तेमाल करने पर लगा कि simple tasks में इसे आसानी से लागू किया जा सकता है, और यह मज़ेदार था

  • इसे complex projects में उपयोग करेंगे या नहीं, इस पर अभी भरोसा नहीं है

• state को लेकर शिकायत पढ़कर लगता है कि लेखक ने React से पहले कभी website नहीं बनाई

  • उदाहरण समझ नहीं आता, और लगता है कि उन्होंने htmx को React की तरह इस्तेमाल करने की कोशिश की और अलग नतीजा देखकर निराश हुए

• जानना चाहते हैं कि क्या HTMX में Turbo Mount जैसी कोई सुविधा है

  • इसे Hotwire/Turbo इस्तेमाल करने के सबसे अच्छे तरीकों में से एक मानते हैं

• morphdom के अनपेक्षित रूप से कुछ elements को overwrite कर देने वाली समस्या के बारे में और जानना चाहते हैं

  • input elements और detail elements की state बनाए रखना morphdom जैसी libraries की मुख्य विशेषताओं में से एक है