HTMX इतना शानदार लगा कि मैंने खुद ही बना लिया (2024)

 (dbushell.com)
1 पॉइंट द्वारा GN⁺ 5 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • HTMX सर्वर-रेंडर्ड HTML को केंद्र में रखकर फ्रंटएंड को क्रमिक रूप से बेहतर बनाता है, और यह उस तरीके का विकसित रूप है जो React-शैली के आधुनिक JavaScript UI के भारी होने से पहले प्रचलित था
  • अपनी self-hosted podcast web app के server refactoring में SvelteKit को DinoSsr से बदलने पर page navigation से audio playback रुकने की समस्या आई, और HTMX से `` क्षेत्र ही अपडेट करके audio component को बनाए रखा जा सका
  • HTMX फ्रंटएंड library के रूप में वितरित होता है, लेकिन इसके implementation का बड़ा हिस्सा backend templates और server configuration में रहता है, और HTML लौटाने वाले HTTP requests व्यवहारतः HTMX API की भूमिका निभाते हैं
  • hx-* attributes, clickable `` examples, और inline JavaScript वाले कई advanced examples, declarative attribute templates की सीमाएँ और documentation से जुड़ी असंतुष्टि दिखाते हैं
  • खुद बनाए गए छोटे implementation में 304 caching, History API, `` replacement, और pointer event आधारित preload मुख्य तत्व थे, और नतीजे में browser JavaScript घटा कर codebase को छोटा और सरल बनाया गया

HTMX की जगह

  • HTMX आधुनिक JavaScript UI को अस्वीकार कर server-rendered HTML को प्राथमिकता देता है, और यह उस तरीके का विकसित रूप है जो React के कारण फ्रंटएंड के भारी हो जाने से पहले प्रचलित था
  • infinite scroll और real-time search results HTMX के लोकप्रिय उदाहरण हैं, और HTMX React आदि जिन सभी समस्याओं को हल करना चाहते हैं उन्हें हल नहीं करता और सीमित दिख सकता है, लेकिन उन सीमाओं के भीतर यह बहुत मूल्यवान tool है
  • HTMX कोई “magic bullet” नहीं है, और HTMX के पीछे के कुछ विचार HTMX स्वयं से भी अधिक महत्वपूर्ण हैं — यही मुख्य दृष्टिकोण है

प्रयोग

  • सिर्फ documentation पढ़ना पर्याप्त नहीं था, इसलिए वास्तविक उपयोग का परीक्षण किया गया, और self-hosted podcast web app का server refactoring HTMX लागू करने का लक्ष्य बना
  • पिछला implementation SvelteKit पर आधारित था, और SvelteKit पसंदीदा tool है, लेकिन छोटे websites के लिए यह कुछ भारी framework हो सकता है
  • जिस चीज़ से प्रतिस्थापन किया गया वह स्वयं बनाया जा रहा DinoSsr था, और वही project static site builds और bookmark blog उपलब्ध कराने में भी इस्तेमाल होता है
  • DinoSsr मुख्यतः server-side आधारित है, और frontend “islands” के रूप में components दे सकता है, लेकिन पूरी page interaction उपलब्ध नहीं कराता
  • audio player component को page navigation के दौरान भी बना रहना चाहिए, और यदि navigation पर पूरी page reload हो जाए तो playback experience बहुत जल्दी टूट जाता है
  • SvelteKit UI updates और frontend routing संभालता था, लेकिन नए build में केवल audio player component frontend JavaScript का उपयोग करता है और DinoSsr जानबूझकर client-side routing की कोशिश नहीं करता
  • कुछ pages में केवल `` section अलग होता है, इसलिए HTMX से links को क्रमिक रूप से बेहतर बनाकर और सिर्फ यही क्षेत्र अपडेट करके पूरी page reload किए बिना audio component को बनाए रखा जा सकता था
  • HTMX का उपयोग अच्छी तरह चला, लेकिन जल्द ही HTMX हटा दिया गया और उसी विचार पर आधारित अपने छोटे version में बदला गया

HTMX पर कुछ विचार

  • इस प्रयोग में HTMX frontend Svelte का विकल्प था, लेकिन React की तरह तुरंत जोड़ देने वाला विकल्प नहीं बल्कि सोचने के तरीके में बड़ा बदलाव था
  • HTMX frontend को क्रमिक रूप से बेहतर बनाने वाली JavaScript library के रूप में वितरित होता है, लेकिन इसका अधिकांश implementation backend में होता है, और server templates तथा configuration स्वयं तैयार करने पड़ते हैं
  • HTML देने वाले HTTP requests व्यवहारतः HTMX API की भूमिका निभाते हैं, और सही caching के लिए HTTP headers सेट करने जैसी बारीकियाँ महत्वपूर्ण हैं
  • standard data-* attributes और dataset मौजूद होने के बावजूद non-standard hx-* prefixed attributes का उपयोग करना एक छोटी शिकायत है
  • HTMX documentation में `` examples बहुत हैं, और नीचे दिया गया example ऐसा ढाँचा दिखाता है जिसमें user div पर click करने पर /messages पर PUT request भेजता है और response उसी div में load हो जाता है
विज्ञापन

    Put To Messages
  • ऐसे examples जिनमें user को `` element पर click करना पड़े, उन्हें वांछनीय नहीं माना जा सकता — यह एक आलोचना है
  • inline JavaScript इस्तेमाल करने वाले कुछ advanced HTMX examples कुछ गंदे लगते हैं, और declarative attribute templates की सीमाएँ दिखाते हैं
  • आलोचनाओं के बावजूद HTMX सीमित लेकिन उपयोगी feature set देता है, और कई सामान्य web design patterns को बेहतर बनाने वाला tool है

खुद बनाना

  • HTMX को सफलतापूर्वक जोड़ने के तुरंत बाद हटा दिया गया, और उसी विचार का उपयोग करके खुद एक छोटा version implement किया गया
  • cached fetch requests की अनुमति देने के लिए last-modified, if-modified-since HTTP headers और 304 responses का उपयोग किया गया
  • बुनियादी history integration के लिए pushState और popstate का उपयोग किया गया
  • `` element को extract और replace करने वाला code जोड़ा गया, और HTMX preload extension से प्रेरित होकर pointer event आधारित preload को built-in किया गया
  • pointer event आधारित preload, click event होने से पहले fetch request शुरू कर देता है, जिससे हल्का performance improvement मिलता है
  • प्रयोगात्मक source code बहुत बुनियादी है, लेकिन यह दिखाता है कि browser में वास्तव में बहुत कम JavaScript की ज़रूरत होती है
  • HTMX या “we have HTMX at home” तरीके से codebase काफ़ी छोटा और सरल हो गया

फ्रंटएंड JavaScript

  • templates और components बहुत छोटे website से आगे बढ़ते ही code organization और reuse के लिए लगभग आवश्यक हो जाते हैं, और इन्हें PHP, Ruby, Go, JavaScript आदि के साथ server-side पर भी लागू किया जा सकता है
  • इस संरचना को browser में दोहराने या केवल browser में ही लागू करने की ज़रूरत नहीं है, लेकिन React आदि की लोकप्रियता के कारण कई developers ने यह सवाल पूछना ही बंद कर दिया है
  • frontend JavaScript fatigue वास्तविक है, और यह पुराने server templates को पसंद करने के साथ-साथ JS UI को ज़रूरत से ज़्यादा design करने के अनुभव से जुड़ी समस्या है
  • भले ही HTMX स्वयं बहुत महान न लगे, इसकी philosophy इतनी मजबूत है कि वह आधुनिक JavaScript developers को शर्मिंदा कर देने लायक मूल्य रखती है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 5 시간 전
Lobste.rs की राय

  • छोटी-सी आपत्ति है, लेकिन जहाँ data-* इस्तेमाल होना चाहिए वहाँ hx-* prefixed HTML attributes का इस्तेमाल मुझे खास पसंद नहीं है Htmx काफी समय से data- prefix को support करता है इस बात से सहमत हूँ कि यूज़र से `` element क्लिक नहीं करवाना चाहिए; इस मामले में anchors और form tags पर htmx का hx-boost इस्तेमाल करना सबसे अच्छा है। यह इन tags को सही तरीके से अपने-आप enhance कर देता है, इसलिए clickable divs से बचा जा सकता है यह ऐसा प्रोजेक्ट है जो दिखाता है कि browser को वास्तव में कितनी कम JavaScript चाहिए, और आगे चलकर इसका maintenance शायद बहुत कम होगा तथा security patches की भी लगभग ज़रूरत नहीं पड़ेगी। बधाई बनती है

  • HTMX सब कुछ render करता है, तो क्या यह server पर बहुत ज़्यादा load नहीं डालता? यह कुछ वैसा लगता है जैसा पहले CGI समस्या हुआ करती थी

    • लगभग निश्चित रूप से नहीं। CGI की समस्या मुख्य रूप से बहुत-से short-lived processes चलाने की लागत थी, और FastCGI जैसी चीज़ों से यह हल हो गई थी HTML generate करना कोई खास महँगा काम नहीं है, और यह कहना भी मुश्किल है कि वैकल्पिक तरीकों में उतनी ही मात्रा का JSON बनाने से यह ज़्यादा महँगा है
    • “हम” से आपका क्या मतलब है, समझ नहीं आया। मेरा ब्लॉग CGI-आधारित है और server HTML render करता है, JavaScript बिल्कुल नहीं है 1999 से अब तक कोई समस्या नहीं हुई, और हमेशा की तरह असली bottleneck कहाँ है यह profiling से ही पता करना चाहिए
    • इसे आम तौर पर server-side rendering कहा जाता है, लेकिन असल में यह server पर raw HTML बनाने के ज़्यादा करीब है। वास्तविक rendering और DOM creation अब भी browser ही करता है, और हमेशा से करता आया है अगर PHP को भी CGI की श्रेणी में रख दें, तो इसका मतलब होगा कि आप web development के उस लगभग डेढ़ दशक को छोड़ रहे हैं जब यही सामान्य तरीका था यह सही है कि इसमें server से ज़्यादा काम लिया जाता है, लेकिन इतने समय में बहुत-सी processing को client पर भेजने का मुख्य कारण मुझे cost reduction के लिए लिया गया एक calculated risk ज़्यादा लगता है। कई end users को शायद पता भी न चले कि browser ज़्यादा काम कर रहा है, लेकिन पुराने या कमज़ोर devices पर आज भी, खासकर शुरू में, अनुभव खराब हुआ है फिर भी HTMX पूरी तरह server-side rendering जैसा नहीं है। इसमें API JSON में data भेजती है और client उसे HTML में render करता है—ऐसा नहीं; बल्कि server वही data HTML fragments के रूप में भेजता है। इसलिए अगर server पिट रहा है, तो संभव है कि वजह यह न हो कि यह REST API की तुलना में मूल रूप से ज़्यादा resources खाता है, बल्कि कुछ और कारण हों
    • benchmark के बिना पक्के तौर पर कहना मुश्किल है, लेकिन दोनों काफ़ी समान लगते हैं। दोनों ही स्थितियों में आखिरकार characters का एक ढेर output होता है; फर्क बस इतना है कि text rendering ज़्यादा महँगी है या JSON generation मेरे अनुभव में JSON इस्तेमाल करते समय लोग अक्सर ज़्यादा चीज़ें serialize कर देते हैं, लेकिन इसे सही तरह से compare करने का तरीका मुझे नहीं पता
    • server-side applications में वास्तविक HTML rendering step का bottleneck होना बहुत कम होता है; bottleneck आम तौर पर उससे पहले की प्रक्रिया में होता है

  • इसी तरह की वजहों से मैं htmx से बहुत मिलता-जुलता alpine-ajax इस्तेमाल कर रहा हूँ

    • alpine-ajax भी मुझे सच में बहुत पसंद है। अगर मैं “SSR से SPA के फायदे लेना” फिर से शुरू करता, तो शायद उसी दिशा में जाता क्योंकि client-side reactivity के लिए मैं वैसे भी alpine इस्तेमाल कर रहा हूँ। हाँ, अभी repository में htmx पहले से काफी जगह पर है, और htmx से कोई शिकायत भी नहीं है
    • मैं datastar इस्तेमाल कर रहा हूँ, और इसके साथ काम करना काफ़ी सुखद रहा है