- htmx को पहले GitHub Open Source Accelerator के लिए चुना गया है, जिससे उसे परिपक्व open source projects के साथ सहयोग करने और उनसे सीखने का अवसर मिलेगा
- यह भागीदारी hypermedia और htmx के approach को व्यापक developer community तक पहुँचाने का अवसर बनेगी
- htmx, Accelerator की अवधि का उपयोग htmx 2.0 पर काम शुरू करने के लिए करने की योजना बना रहा है
- project को बनाए रखने और development जारी रखने के लिए htmx पर काम को full-time job में बदलने का तरीका सीखना भी एक महत्वपूर्ण चुनौती बना हुआ है
- साथ चुने गए projects security, documentation, authentication, notifications, CMS जैसे विभिन्न open source क्षेत्रों को कवर करते हैं, जो GitHub Accelerator के दायरे को दिखाते हैं
htmx को मिलने वाला अवसर
- htmx को पहले GitHub Open Source Accelerator class में चुना गया है
- इस चयन से वह सफल open source developers और projects से सीख सकेगा और उनके साथ सहयोग कर सकेगा
- htmx का मानना है कि इस प्रक्रिया के जरिए hypermedia और htmx को अधिक व्यापक रूप से परिचित कराया जा सकेगा
- Accelerator में भागीदारी की अवधि के दो मुख्य लक्ष्य हैं
- htmx 2.0 पर काम शुरू करना
- htmx पर काम को full-time job में बदलने का तरीका सीखना
साथ चुने गए open source projects
- BoxyHQ: security और privacy के लिए API products का समूह, जो engineering teams को compliant cloud applications अधिक तेजी से बनाने और deploy करने में मदद करता है
- Cal.com: ऐसा scheduling tool जो बार-बार emails भेजे बिना meetings schedule करने में मदद करता है
- Crowd.dev: community, product और customer data को centralized करके यह समझने में मदद करता है कि कौन-सी companies open source projects में भाग ले रही हैं
- Documenso: open source DocuSign alternative, जिसका लक्ष्य self-hosting और अंदरूनी workings की review के जरिए भरोसा हासिल करना है
- Erxes: open source HubSpot alternative, जिसमें single XOS के जरिए विभिन्न business types के लिए experiences बनाए जा सकते हैं
- Formbricks: user journey के किसी भी point पर segmented user groups को surveys भेज सकता है, और targeted micro-surveys के जरिए 6 गुना तक अधिक insights जुटा सकता है
- Forward Email: custom domains के लिए free email forwarding service, जिसे 6 साल से अधिक समय से creators, developers और companies इस्तेमाल कर रही हैं
- GitWonk: developer experience पर केंद्रित होकर design और build किया गया open source technical documentation tool
- Hanko: passkey युग के लिए open source authentication और user management tool, जिसे web और mobile apps में कुछ ही मिनटों में integrate किया जा सकता है
- Infisical: teams, devices और infrastructure में secrets और configurations को सुरक्षित रूप से manage करने वाला open source end-to-end encrypted platform
- Novu: developers के लिए open source notification infrastructure, जो सभी communication channels को एक जगह manage करने के लिए components और APIs प्रदान करता है
- OpenBB: open source financial ecosystem के जरिए investment research को democratize करता है, और OpenBB Terminal से कहीं से भी investment research की जा सकती है
- Sniffnet: internet traffic को आसानी से track करने में मदद करने वाला network monitoring tool
- Typebot: अनोखे chat experiences बनाने के blocks प्रदान करता है, और apps में कहीं भी embed करके results collect किए जा सकते हैं
- Webiny: open source enterprise-grade serverless CMS, जो data ownership, scaling और customization पर जोर देता है
- Webstudio: Webflow के open source alternative के रूप में चुना गया
1 टिप्पणियां
Hacker News की राय
नमस्ते, जैसा कि आपमें से कई लोग जानते होंगे, मैं htmx का निर्माता हूं और इससे जुड़े सवालों के जवाब दे सकता हूं
htmx की लोकप्रियता fireship dev के वीडियो(https://www.youtube.com/watch?v=r-GSGH2RxJs) और लोकप्रिय Twitch स्ट्रीमर ThePrimeagen की वीडियो सीरीज़ की वजह से काफी बढ़ी
HN पाठकों के लिए htmx और सामान्य तौर पर hypermedia पर मेरे लिखे लेखों का संग्रह https://htmx.org/essays भी दिलचस्प हो सकता है, और हाल ही में कुछ लेखकों के साथ प्रकाशित hypermedia, htmx, और mobile hypermedia Hyperview से जुड़ी किताब https://hypermedia.systems भी देखने लायक है
जाहिर है मैं htmx का फैन हूं, लेकिन मेरे हिसाब से ज्यादा गहरी असल बात hypermedia है। रोज़मर्रा के development में htmx इस्तेमाल करने की योजना न भी हो, तो भी यह explore करने लायक concept है
37signals के Hotwire या htmx के बाद मेरी पसंदीदा https://unpoly.com जैसी कई शानदार hypermedia-oriented libraries भी हैं
यह कई Django developers के लिए बहुत मददगार है
कुछ महीने पहले जब मैं article like feature बना रहा था, htmx से पहले jQuery से JSON API server call करके like count update करना पड़ता था, लेकिन HTMX इस्तेमाल करने पर Django logic के साथ बस सामान्य HTML इस्तेमाल करने जैसा लगा
अब तक जो मिला है उनमें यह बेहतरीन चीज़ों में से एक है, और form handling भी बहुत आसान है। HTMX user experience और developer experience, दोनों को बहुत बेहतर बना देता है
यह देखते हुए कि बहुत लोकप्रिय projects में भी आम तौर पर मौजूदा contributors ही code का ज्यादातर काम करते हैं, यह मजबूत growth signal है
https://devboard.gitsense.com/bigskysoftware/htmx
वैसे, यह tool मैंने बनाया है
website और examples को थोड़ा देखने पर लगता है कि server HTTP response पूरा markup रखता है और उसी के आधार पर client state update होती है—यानी DOM rewrite पर ज्यादा जोर है
मुझे जानना है कि htmx client-only triggers या client-generated content के लिए भी कोई concession देता है या नहीं
आज के JavaScript-centric client frameworks की खूबी यह है कि जितना ज्यादा संभव हो उतना काम browser को सौंपकर server के data और CPU usage को कम किया जा सकता है। web-scale apps में यह बड़ा फर्क है
मैं जानना चाहता हूं कि HTMX ऐसे engineering goals भी पूरा कर सकता है या यह पूरी तरह किसी अलग मकसद का project है। मैं समझता हूं कि Facebook जैसा client hypermedia-oriented नहीं है, लेकिन फिर भी तुलना से बचना मुश्किल होगा
यह natural लगता है, अपने-आप documentation जैसा महसूस होता है, और अच्छी तरह designed है। सच में HTML का natural extension जैसा लगता है
मेरे लिए htmx में जो एकमात्र missing piece है वह component model है, और जो लोग ऐसी चीज़ ढूंढ रहे हैं उनके लिए यह Astro[1] के साथ बहुत अच्छी तरह fit हो सकता है। Astro, Vue या React जैसे runtime burden के बिना HTML components define और use करने देता है
[1] http://astro.build
Htmx मुझे Tailwind की याद दिलाता है, क्योंकि इसने ऐसे attribute names और values बनाए हैं जिन्हें runtime पर एक library पढ़ती है
frontend build की जरूरत न होना उन ज्यादातर developers के लिए बहुत बड़ा फायदा है जो npm और webpack को छूना नहीं चाहते, और जिन्हें ऐसा करने की जरूरत भी नहीं होनी चाहिए
page size की सीमा किसी छोटी single-page app जैसी लगती है, और अगर यह बहुत बड़ी हो जाए तो शायद इसे किसी दूसरी single-page app में बांटा जा सकता है
React/Vue developers को खास तौर पर जिस बात की कमी खलेगी, वह शायद यह नजरिया है कि global state दिखाने वाला एक single object होता है, और component codebase में hierarchy के तौर पर defined एक function उसे UI में render करता है
हालांकि यह नजरिया अपने-आप में भी भारी है और बहुत सारे मतभेद व emotional drain पैदा करता है, और frontend build तथा उसके उलझे हुए variants भी साथ ले आता है
मैं अभी इसका इस्तेमाल नहीं करता, लेकिन पहले से ही बड़ा fan हूं
अच्छी खबर है
पिछले 1 साल से htmx इस्तेमाल करते हुए मुझे अच्छे नतीजे और संतोषजनक अनुभव मिले हैं, और Clojure में hiccup के साथ server-side rendering करते समय यह खास तौर पर शानदार रहा
htmx को एक बार समझ लेने पर यह कितना सरल और flexible है, यह लगभग चौंका देता है। यकीन करना मुश्किल है कि HTML hypermedia के रूप में इस तरह क्यों विकसित नहीं हुआ
यह बहुत स्पष्ट हो जाता है कि web development को असल में इसी तरह evolve होना चाहिए था। उम्मीद है कि किसी दिन htmx JavaScript से जो काम कर रहा है, वह सीधे HTML और browser client में built-in हो जाएगा
अगर आप htmx को Angular की कोई derivative चीज़ समझने की गलती करते हैं, या hypermedia architecture को आगे बढ़ाने के इसके महत्व को नहीं समझते, तो site के बेहतरीन लेख ज़रूर पढ़ने की सलाह दूंगा। तब आप समझेंगे कि REST क्या है और असली HATEOAS क्यों महत्वपूर्ण है: https://htmx.org/essays/
एक मुफ्त किताब भी है: https://hypermedia.systems/
10~15 साल पहले हमने शुरुआती web के नए और शक्तिशाली idea, hypermedia, को expand और enrich करने के बजाय JSON API architecture के साथ web के ऊपर फिर से thick client बनाने की कोशिश की, और एक महंगे गलत रास्ते पर चले गए
मुझे खुशी है कि htmx मौजूद है और बहुत लोगों के लिए अच्छा fit है, लेकिन मेरे काम में यह अक्सर सबसे अच्छा विकल्प नहीं रहा। और यह ठीक है
web का कई अलग-अलग तरीकों से grow कर पाना शानदार बात है, और यह मानने की ज़रूरत नहीं कि web को किसी एक तय दिशा में ही evolve होना चाहिए था
पिछले करीब 10 सालों में web development की सबसे बड़ी गलती यह सोच थी कि एक ही सही जवाब होना चाहिए
चाहे अगला Gmail बनाना हो या static blog, industry का cargo cult कहता है कि सब कुछ एक ही तरीके से करना चाहिए, लेकिन common sense कहती है कि ऐसा नहीं है
web के 98% से ज्यादा हिस्से के लिए यह पर्याप्त होगा। बाकी 1.9% के लिए छोटी JavaScript library इस्तेमाल की जा सकती है
बचे हुए 0.1% ही pure JavaScript web apps हैं
लगता है idea वही है: HTML में कुछ attributes छिड़क कर आसान cases को dynamic बना देना
Angular 1, Vue आदि कई frameworks इसी तरह शुरू हुए, और कुछ popularity पाने के बाद ज्यादा कठिन cases की real demand के कारण full single-page app framework में बढ़ गए
अगर मुझे “Angular 1 जैसा” framework चुनना हो, तो मैं ऐसा चुनूंगा जो boundaries को साफ़ तौर पर document करे और जब उन boundaries से आगे जाना पड़े तो mature single-page app framework इस्तेमाल करने का clear path दे। अगर किसी को ऐसा framework पता हो तो शेयर करें
मैं HTMX का “कूल बनने से पहले से” फैन रहा हूँ
हाल की दिलचस्पी और सफलता देखकर बहुत अच्छा लग रहा है, और frontend की तरफ़ से आने वाली मज़ाकिया चुटकियों और विरोध का भी मैं काफ़ी आनंद ले रहा हूँ, जहाँ वे मानते हैं कि वेब 2013 में invent हुआ था और वही लोग उस शहर के निर्माता हैं
Backbone.js के दौर से ही मेरा एक bias रहा है; तब भी दर्द का कुछ हिस्सा समझता था, लेकिन कुछ हद तक skeptical था
बाद में React आया और युवा, जोशीले लोग 5-पेज की बेहद simple website को frontend framework की Rube Goldberg machine में बदलने लगे, तो मैंने अपने tech chips cash out कर लिए और उन चीज़ों को हाथ नहीं लगाया
implementation details काफ़ी अलग हैं, लेकिन hypermedia-driven applications का idea हमारे हर काम के केंद्र में था
दुर्भाग्य से, लंबे समय में यह लोगों का दिल नहीं जीत पाया, और blog-driven development, यानी cargo cult, ने हमारी कोशिशों की जगह ले ली
अब HTMX की popularity बढ़ती दिख रही है, तो कुछ हद तक मेहनत का फल मिलने जैसा लगता है। यह देखकर अच्छा लगता है कि इन concepts में सोचने वाले हम अकेले नहीं थे
बेशक, अगर concept मजबूत था तो इसका मतलब यह भी हो सकता है कि मेरी execution कमज़ोर थी, इसलिए शायद बहुत ज़्यादा खुश नहीं होना चाहिए
मैंने यह भी सुना कि band ने guitar बेचकर turntable खरीद लिए
मैंने सुना कि HTTP endpoint को JSON return करने के लिए फिर से लिखा गया, और वही REST था
मैंने यह भी सुना कि band ने turntable बेचकर guitar खरीद लिए
मैंने सुना कि HTTP endpoint को templated HTML fragments return करने के लिए फिर से लिखा गया, और वही HATEOAS था
मैं feel खो रहा हूँ, फिर पा रहा हूँ, फिर खो रहा हूँ, फिर पा रहा हूँ
हालांकि Backbone थोड़ा loose था, और Angular आने तक यह बहुत enterprise-जैसा नहीं था
खैर, मेरे आसपास इस तरह के web application flow के popular होने की वजह यह थी कि backend और frontend अलग हो जाते थे, और एक backend, आम तौर पर REST/JSON, mobile और web clients दोनों को अलग-अलग feed कर सकता था
इसी वजह से हमने single-page apps बनाए थे, लेकिन अब लगता है यह फिर से भुला दिया गया है
मेरी दुनिया में, login के पीछे वाले apps के लिए यह बात समझ में आती थी। लेकिन “वे” web shop जैसी public internet sites को भी single-page app बनाना चाहते थे
यह भी समझ आता है। मैंने Gatsby से कुछ websites बनाई हैं, और navigation पागलों जैसी तेज़ होती है, फिर भी search engines में indexed रहती हैं
लेकिन कुछ cases में यह धीरे-धीरे और complex होता गया और server-side React जैसी चीज़ें भी आ गईं। शुक्र है मुझे उसे छूना नहीं पड़ा
एक तरफ़, मैं चाहता हूँ कि htmx, और आम तौर पर hypermedia, एक tool के रूप में अपनाया जाए। यह useful है, लेकिन आखिरकार सिर्फ़ एक tool है
frontend के उन लोगों के बीच भी इसे ऐसे ही स्वीकार किया जाए, जिन्होंने कुछ समय से hypermedia पर गहराई से नहीं सोचा है
मैं दोनों approaches को परस्पर exclusive नहीं मानता, और Rich Harris के Transitional web applications concept से सहमत हूँ, यानी दोनों approaches को mix करने का तरीका
बस hypermedia छोड़कर ज़्यादा sophisticated client-side approach पर जाने की रेखा मैं उनसे अलग जगह खींचता हूँ
मैं तो निश्चित रूप से ऐसा ही सोचता हूँ
मैंने 1996 में Perl से शुरुआत की थी और PHP, jQuery, Drupal, Backbone, Node, Angular, ClojureScript, React, GraphQL, NextJS तक लगभग हर trend देखा है
Htmx उस धारा से अलग निकली हुई शाखा जैसा लगता है, और इस पर सोचने लायक है
Htmx एक अच्छा सवाल पूछता है। “आपके काम की complexity मूल रूप से server में है या client में?”
ज़्यादातर websites में complexity मूल रूप से server में होती है। हम में से ज़्यादातर लोग Figma या Google Sheets नहीं बना रहे हैं। कई websites बहुत interactive होने पर भी बस अच्छे interface वाली CRUD apps ही होती हैं
NextJS जैसे frameworks React को server पर ले जाकर over-complex client problem को ठीक करने की कोशिश करते हैं, लेकिन अक्सर complexity घटाने के बजाय बढ़ा देते हैं
तो क्या stack से React हटाना सही नहीं होगा? अगर complex client है, तो DOM और JavaScript को छोड़कर canvas और compiled WebAssembly इस्तेमाल कर सकते हैं। अगर complex server है, तो server-driven fine-grained DOM updates इस्तेमाल कर सकते हैं
इस approach में दिखने वाली समस्या यह है कि भले ही ज़्यादातर websites की complexity server में हो, लगभग हमेशा कुछ high-complexity tasks ऐसे होते हैं जिन्हें client में ही होना चाहिए। जैसे image editing, real-time sorting/filtering/calculation, drag/touch gestures वगैरह
Hybrid approach की ज़रूरत है। सिर्फ compatible होना काफी नहीं है। htmx और React को एक ही webpage में इस्तेमाल किया जा सकता है, लेकिन उन्हें अलग-थलग रखना पड़ता है। मुझे isolation नहीं, बल्कि मूलभूत integration चाहिए
आदर्श framework को DOM के लिए reactive fine-grained updates support करने चाहिए, और साथ ही complex client tasks संभालने वाले compiled WebAssembly के साथ गहराई से integrate होना चाहिए
मैं सारा code JavaScript के बजाय किसी powerful language में लिखना चाहता हूँ। debugger को server और client दोनों संभालने चाहिए, और दोनों का फर्क खत्म हो जाना चाहिए। यह असली full-stack development, यानी single-stack application होना चाहिए
Clojure + ClojureScript single-stack application के करीब लगता है, लेकिन सिर्फ सतही तौर पर
अगर Common Lisp में कोई killer framework आ जाए, तो single-stack application बिलकुल fit बैठेगा
Hybrid approach वही islands approach है जिसका Astro दावा करता है: https://docs.astro.build/en/concepts/islands/
यह approach htmx और उसके साथियों के साथ अच्छी तरह fit बैठता है, और हम htmx project में जिन हिस्सों में interaction चाहिए, वहाँ simple vanilla JavaScript जोड़कर इस्तेमाल कर रहे हैं
छोटे-मध्यम projects और छोटी teams के लिए यह पर्याप्त हो सकता है। developer tools खोलकर page के किसी हिस्से की ओर इशारा करना, और सिर्फ HTML व छोटे JS snippets देखकर उस हिस्से को पूरी तरह समझ पाना सचमुच ताज़गी भरा है
server हो या client, C# में एक ही तरीके से code करते हैं। पहले page load पर सब कुछ server-side render होता है, और उसके बाद WebAssembly धीरे-धीरे takeover करता है और server data की जरूरत न रखने वाले UI interactions को तेज़ करने के लिए client में C# code load करना शुरू करता है
यह अच्छी तरह काम करता है, लेकिन अभी चुनौती WebAssembly file size घटाने की है। फिलहाल यह कई MB के स्तर पर है
https://visualstudiomagazine.com/articles/2023/04/20/blazor-...
बधाई। Htmx से छोटे projects बनाना मज़ेदार था, लेकिन आखिरकार openlayers का बहुत इस्तेमाल करना पड़ा, इसलिए मैंने कुछ और चुना
map libraries client-side JavaScript भारी होने के लिए मशहूर हैं, और उस काम के लिए Svelte बेहतर tool था
आगे Golang projects में इसे फिर से इस्तेमाल करने की योजना है और इसके विकास पर नज़र रखना चाहूँगा
अगर आपकी app को simple या medium complexity वाला frontend चाहिए, और खासकर अगर आप पहले से template fragments[0] इस्तेमाल कर रहे हैं, तो HTMX जरूर आज़माएँ। JavaScript दुनिया से आने वाले व्यक्ति के लिए भी इसके साथ काम करना काफी मज़ेदार है
और Twitter account[1] चलाने वाला व्यक्ति वाकई मज़ेदार है
[0] https://htmx.org/essays/template-fragments/
[1] https://twitter.com/htmx_org
htmx को आधुनिक webapp या site बनाने के tool के रूप में गंभीरता से लेना मुश्किल है। ऐसा लगता है कि यह वे features बनाना असंभव कर देता है जिनकी users अब उम्मीद करने लगे हैं
उदाहरण के लिए, तारीखों को पहले·बीच·बाद के हिसाब से filter करना लेकिन filter तभी दिखाना जब user चाहे—यानी faceted search—या results screen को किसी दूसरे column, map, chart जैसी canvas पर draw होने वाली view में बदलना
htmx से इनमें से कुछ चीज़ें की जा सकती हैं, लेकिन किसी point पर आखिरकार आपको JSON की ज़रूरत पड़ेगी
Angular भी ये सब कर सकता है, और SolidJS जैसी चीज़ इस्तेमाल करें तो असल में इसे बनाना काफी मज़ेदार हो सकता है
JSON API को दूसरी apps में भी reuse किया जा सकता है, लेकिन htmx ऐसा लगता है जैसे किसी ने Thymeleaf को फिर से invent कर दिया हो
मेरी भी यही सोच थी, लेकिन video में खास तौर पर बताया गया है कि faceted search को htmx से कैसे implement किया गया
दूसरा हिस्सा शायद सीधे JavaScript लिखकर या hyperscript से handle किया जाएगा
इसे सच में बनाकर और intensively use करके ही पता चलेगा कि तरीका अच्छा है या नहीं, लेकिन कुछ scenarios साफ़ तौर पर दिखते हैं जहाँ यह अच्छी तरह fit होता है
JSON API वाला point सही है। अगर public API चाहिए, तो इसे decision-making में शामिल करना चाहिए। लेकिन हर project पर ऐसी constraint नहीं होती
smartphones को भी हजार rows वाली table search करने में कोई समस्या नहीं होती
ऐसे case में मैं htmx से user को data का बड़ा range दूँगा, और उसके बाद ज्यादा detailed real-time filtering JS से allow करूँगा
अगर आप चाहते हैं कि शुरू में न दिखने वाला data भी searchable हो, तो उसे hidden CSS class के साथ भेज दें, और search में match होने पर वह class हटा दें
htmx भी बाकी technologies की तरह कुछ खास problem sets के लिए बहुत अच्छी तरह fit होता है। उससे ऐसे करतब जबरदस्ती न करवाएँ जिनमें वह अच्छा नहीं है, तो ठीक है
ऐसी चीज़ें इतनी complex होती हैं कि कुछ हद तक full scripting की जरूरत पड़ती है, और मैं इसके खिलाफ नहीं हूँ
https://htmx.org/essays/hypermedia-friendly-scripting/
अपने career के उतार-चढ़ाव की वजह से मैं frontend JavaScript framework wars से लगभग बच गया, इसलिए plain old HTML को मजबूत होकर लौटते देखना अच्छा लग रहा है
यह progressive degradation के लिहाज से पीछे की ओर कदम है
मुझे लगता है htmx से बने impressive examples की जरूरत है। “made with htmx” examples अच्छे होंगे, जो किसी नए तरह के web experience की शुरुआत करें
लोगों ने htmx को simple use cases तक सीमित stereotype कर दिया है, जहाँ “serious weapons” निकालने की जरूरत नहीं होती
इसमें कुछ हद तक बात है, लेकिन यह सीमित नजरिया है। htmx से जुड़ा server पर वापस जाना approach एक अलग category है, जिसे कई कारणों से पहले उतना explore नहीं किया गया
HTMX backend पर निर्भर न रहने वाले तरीके से पुरानी app category को फिर से जिंदा करता है
यह कोई नई चीज़ नहीं कर रहा, न ही ऐसा कुछ जो “नई app category” को justify करे
यह shopping catalog, forum, admin frontend, blog जैसे hypermedia, यानी content-centric sites बनाने का तरीका है
jquery/liveview/turbolinks जैसा, लेकिन backend-agnostic है और frontend JS logic को बहुत कम, या बिल्कुल भी, maintain करने की जरूरत नहीं होती
जब Google Docs या Figma जैसी heavy interaction की जरूरत पड़ती है, तो htmx से मिलने वाले फायदे काफी कम हो जाते हैं
https://htmx.org/essays/a-real-world-react-to-htmx-port/
यह HTMX और Hyperscript से लिखा गया e-commerce frontend है
https://www.makaron.cz/
TodoMVC HTMX frontend बनाया जा सकता है, लेकिन backend में क्या इस्तेमाल करेंगे? Go, C#, Rust और कुछ options natural लगते हैं, लेकिन यह हमेशा context पर निर्भर करता है
C# का ज़िक्र इसलिए कर रहा हूँ क्योंकि ASP.Net MVC + Razor HTMX paradigm के साथ बहुत साफ़-सुथरे तरीके से fit होता दिखता है
इनसे मेरा कोई लेना-देना नहीं है, लेकिन यह htmx और ज्यादा complex features के लिए कुछ JS से बनाया गया है
htmx का explicit goal पुराने अच्छे approach को extend करना है, यह देखते हुए मुझे नहीं पता कि यह “नए तरह का web experience” दे पाएगा या नहीं
शुरुआत में htmx अच्छा लगता है, लेकिन अगर आप dropdown button जैसा कुछ बनाना चाहें—जिसके लिए आम तौर पर JavaScript, चाहे vanilla हो या कोई framework, इस्तेमाल करने लायक होता है—तो अंत में आप hyperscript पर विचार करने लगते हैं
फिर जब उदाहरण देखते हैं, तो code के अंदर वाक्य जैसी चीज़ें दिखना अच्छा नहीं लगता और आप किसी और चीज़ की ओर बढ़ जाते हैं
हो सकता है htmx को hyperscript के बिना आज़माना पड़े, या hyperscript को थोड़ा और समय देना पड़े
लेकिन अगर इसे कई साल तक maintain करने की उम्मीद हो, तो यह बहुत अपरिचित लगता है, और अगर बाद में इसे फिर कभी इस्तेमाल न करना पड़े तो मैं इससे बंधना नहीं चाहूँगा
htmx को इस बात से कोई फर्क नहीं पड़ता कि आप client-side interaction के लिए कौन-सा tool इस्तेमाल करते हैं, इसलिए यह htmx की उपयोगिता से अलग मुद्दा है
व्यक्तिगत रूप से, अगर मैं JS build tools वगैरह से बचना चाहूँ, तो htmx + Alpine.js चुनूँगा
जब scale बढ़ेगा और complexity बढ़ेगी, तो इसे कैसे संभाला जा सकेगा?
मैंने htmx इस्तेमाल करने वाली एक application में मदद की थी, और उसमें दो समस्याएँ थीं। जानना चाहता हूँ कि क्या किसी और का अनुभव भी ऐसा रहा है, क्या ये technology को गलत तरीके से इस्तेमाल करने से आई समस्याएँ थीं, या इन्हें हल करने पर कोई काम चल रहा है
पहली बात, controllers में बहुत सारे custom middleware की ज़रूरत पड़ी ताकि तय किया जा सके कि endpoint पूरी page HTML लौटाए या सिर्फ वह fragment जिसकी htmx को ज़रूरत है
htmx की तरफ से यह सरल दिखता है, लेकिन शायद htmx इस्तेमाल करने वाले हर project को यह हिस्सा फिर से बनाना पड़ता होगा
दूसरी बात,
hx-triggerके आसपास bookkeeping की ज़रूरत पड़ी। UI जटिल होने पर कई elements को बाहरी बदलावों पर react करना होता हैकोई state पढ़कर framework से update schedule करने की उम्मीद करने के बजाय, जिन events पर react करना है उनकी list खुद manage करनी पड़ी
क्या किसी और को भी ऐसा ही लगा?