Gumroad ने htmx क्यों नहीं चुना

 (htmx.org)
6 पॉइंट द्वारा GN⁺ 2024-10-04 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Gumroad ने अपने नए प्रोजेक्ट Helper में हल्के फ्रंटएंड की उम्मीद के साथ htmx पर विचार किया, लेकिन जटिल UX जरूरतें बढ़ने पर React/Next.js पर शिफ्ट कर गया
  • सरल interactions के लिए htmx promising था, लेकिन dynamic validation और conditional fields वाले forms में server-side logic लंबा हो गया और development flow अप्राकृतिक लगा
  • workflow builder का drag-and-drop, real-time collaboration, complex state management, और dynamic form generation React ecosystem और component model में ज्यादा सीधे तौर पर लागू हुए
  • problem-solving resources और AI tool support Next.js और React की तरफ ज्यादा भरपूर थे, जबकि htmx open source training data की कमी के कारण development speed में disadvantage पर था
  • htmx मौजूदा server-rendered apps या simple interaction models के लिए सही हो सकता है, लेकिन Helper जैसे state-heavy interfaces के लिए React और Next.js ज्यादा फिट थे

Helper में htmx पर विचार करने की पृष्ठभूमि

  • Gumroad ने नया प्रोजेक्ट Helper शुरू करते समय htmx को frontend candidate के रूप में देखा
  • शुरुआती उम्मीद React जरूरत से ज्यादा भारी है वाले पुराने अनुभव से आई थी, और माना गया कि htmx simple interactions को हल्के तरीके से जोड़ने का रास्ता हो सकता है
  • team के अंदर यह राय भी थी कि htmx जटिल हो चुके JavaScript ecosystem पर कटाक्ष करने वाले meme जैसा है
    • जैसे Tailwind inline CSS की अलग syntax जैसा दिखता है, वैसे ही htmx भी inline JavaScript की अलग syntax के करीब है—ऐसा नजरिया था
  • Tailwind Gumroad के tool system में जगह बना चुका था, लेकिन htmx Helper के उद्देश्य के अनुरूप scale नहीं हुआ और ग्राहकों के लिए सबसे अच्छा user experience नहीं दे पाया

जहां React/Next.js ज्यादा natural लगा

  • Development experience और form handling

    • htmx से भी सही implementation संभव था, लेकिन Gumroad को लगा कि Next.js में features को काम में लाने की प्रक्रिया ज्यादा intuitive है
    • dynamic validation और conditional fields वाले complex forms में React का client-side work ज्यादा सरल था, जबकि htmx में server-side logic लंबा हो गया

  • UX और interaction constraints

    • htmx apps को Rails/CRUD तरीके की ओर धकेलने की प्रवृत्ति रखता है, जिससे default experience साधारण या generic form का हो जाना आसान था
    • workflow builder का drag-and-drop interface htmx में workaround implementation मांगता था, और React libraries से मिलने वाले smooth experience की तुलना में rough लगा

  • AI tools और problem solving speed

    • AI tools Next.js से परिचित हैं, लेकिन htmx से कम; इसकी वजह open source training data की कमी बताई गई
    • React/Next.js की तरफ resources ज्यादा होने से समस्या आने पर solution खोजने की speed ज्यादा तेज थी

  • Complexity और scalability

    • project जितना complex होता गया, htmx की simplicity advantage से ज्यादा constraint जैसी लगने लगी
    • real-time collaboration और complex data visualization जुड़ने पर, htmx के server-centric approach में कई components के बीच state management धीरे-धीरे मुश्किल होता गया

Helper के features के हिसाब से दिखे फर्क

  • drag-and-drop: React ecosystem का react-beautiful-dnd कम setup में smooth और accessible drag-and-drop देता है
  • complex state management: हर workflow step की settings और conditional logic को real time में UI में reflect करने के लिए useState या Redux जैसे React state management तरीके ज्यादा direct थे
  • dynamic form generation: step type के हिसाब से अलग settings forms बनाना और user input के अनुसार उन्हें बदलना React component model में ज्यादा intuitive तरीके से handle हुआ
  • real-time collaboration: कई users के एक साथ workflow edit करने का feature WebSockets और React से अपेक्षाकृत direct तरीके से implement हुआ, जबकि htmx में ज्यादा complex server-side logic और custom JavaScript की जरूरत थी
  • performance optimization: workflow बड़ा और complex होने पर React के virtual DOM, useMemo, useCallback जैसे hooks से rendering को fine-grained तरीके से optimize किया जा सकता था

ecosystem और अंतिम फैसला

  • React/Next.js ecosystem बड़ा और mature है, और Gumroad के सामने आई लगभग हर समस्या का solution देता है
  • htmx में features पर compromise करने या उन्हें खुद फिर से बनाने की स्थितियां ज्यादा थीं, और third-party services व libraries के integration में भी कई बार React bindings तो थे लेकिन htmx equivalent नहीं था
  • React/Next.js पर जाने के बाद Gumroad ने माना कि complex UX बनाने के लिए यह ज्यादा fit choice थी
    • वे तेजी से आगे बढ़ सके, ज्यादा immersive user experience बना सके, और existing tools व libraries का लाभ उठा सके
    • Helper के core customers के लिए app user experience भी काफी सुधार सके
  • htmx की सीमाएं असंभव रूप से पार न होने वाली नहीं हैं, लेकिन उन्हें हल करने की प्रक्रिया htmx की strengths से दूर जाकर JavaScript-centric environment में ज्यादा natural solutions की ओर ले गई
  • htmx simple interaction models या existing server-rendered apps के ऊपर बने projects के लिए अच्छा choice हो सकता है
  • Helper जैसे complex और state-heavy interfaces में React और Next.js ज्यादा उपयुक्त थे, और Gumroad मानता है कि जरूरतों में बदलाव और नई technologies के अनुसार tech stack को लगातार फिर से evaluate किया जा सकता है

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

1 टिप्पणियां

 
GN⁺ 2024-10-04
Hacker News की राय

  • यह बात मैंने एक दूसरे थ्रेड में लिखी थी: Gumroad CEO ने Twitter पर कहा था कि उन्होंने किसी प्रोजेक्ट में htmx आज़माया, लेकिन आखिर में NextJS चुना
    मैं htmx वेबसाइट पर डालने लायक कोई सोच-समझकर लिखा गया नकारात्मक अनुभव ढूंढ रहा था, इसलिए उनसे पूछा कि क्या वे अपना अनुभव लिख सकते हैं, और शुक्रिया कि उन्होंने खुशी-खुशी मान लिया

    • htmx किन जगहों पर हमेशा सबसे अच्छा विकल्प नहीं हो सकता, इसे खुद सामने रखने के रवैये की वजह से इस प्रोजेक्ट के लिए मेरी इज़्ज़त और बढ़ गई
      हर चीज़ के लिए खुद को सबसे अच्छा समाधान बताने वाले दूसरे प्रोजेक्ट्स की तुलना में यह ताज़गी भरा है
      खासकर drag and drop से जुड़ी बात को लेकर उत्सुक हूं: क्या वे सच में मानते हैं कि htmx में यह मुश्किल है, और अगर हां, तो क्या इसे हल करने की कोई योजना है
    • Gumroad CEO ने यह भी कहा कि Rails खुद ही technical debt है, और वजह पूछने पर बस इतना जवाब दिया कि React कहीं बेहतर है
      जबकि ऐसा नहीं है कि Rails और React को साथ इस्तेमाल नहीं किया जा सकता
      यह लेख खुद htmx के नकारात्मक अनुभव से ज़्यादा ऐसा लगता है कि drag and drop और real-time collaboration आते ही शुरुआत में htmx को प्रयोग के तौर पर चुनना ही शायद गलत था
      screenshot क्या दिखाने की कोशिश कर रहा है, यह भी मुझे ठीक से समझ नहीं आया, लेकिन फिर भी मुझे लगता है कि htmx वेबसाइट पर डालने के लिए यह अच्छा लेख है
    • htmx किन जगहों पर दूसरे टूल्स से कम उपयुक्त हो सकता है, यह दिखाना सम्मान के लायक है
      मेरे लिए htmx, React का विकल्प कम और jQuery का विकल्प ज़्यादा है
      htmx और jQuery डॉक्यूमेंट में इंटरैक्शन जोड़ते हैं, जबकि React पूरा डॉक्यूमेंट ही बनना चाहता है
      काम के हिसाब से टूल बदलना चाहिए
    • लिंक किए गए लेख और https://htmx.org/essays/htmx-sucks/ को देखने के बाद मैंने तय कर लिया कि htmx न तो इस्तेमाल करूंगा और न ही दूसरों को सुझाऊंगा
    • दूसरा थ्रेड https://news.ycombinator.com/item?id=41727315 है

  • “AI और टूल सपोर्ट: यह भी worth noting है कि AI टूल्स Next.js से काफी परिचित हैं, लेकिन htmx से उतने परिचित नहीं” वाला हिस्सा कमी की तरह शांत ढंग से लिखा गया था, लेकिन development tools, libraries, frameworks और languages के भविष्य के लिए यह काफी डरावना संकेत है
    मेरा अनुमान है कि large language models मौजूदा winner-takes-all और first-mover effects को और बढ़ाएंगे, और ज़्यादा व बेहतर training data की वजह से open source tools के इस्तेमाल को भी और प्रोत्साहित करेंगे

    • AI और tool support का मुद्दा असल में community और ecosystem वाले मुद्दे का ही विस्तार है
      large language models से पहले भी React का फायदा यह था कि ज़्यादातर सवाल StackOverflow पर पहले से मौजूद थे, और लगभग हर काम के लिए mature libraries उपलब्ध थीं
      अब बस कुछ लोग वही सवाल, जो पहले StackOverflow पर पूछते, large language models से पूछ रहे हैं; नतीजा वही है
      जो चीज़ बाकी लोग ज़्यादा इस्तेमाल करते हैं, उसे इस्तेमाल करने से फायदे मिलते हैं
    • large language models development tools में winner-takes-all और first-mover effects बढ़ाएंगे—यह उन लोगों के लिए सही होगा जो coding के लिए large language models पर निर्भर हैं
      लेकिन software engineer career की लंबी अवधि की रणनीति के तौर पर मुझे यह बिल्कुल अच्छा दांव नहीं लगता
    • AI tools किसी एक समय बिंदु में अटके रहते हैं, और उन्हें नए material से train करने पर भी सीख सकने वाली जानकारी की मात्रा की सीमा होती है
      मैंने सोचा है कि शायद यह अच्छी बात भी हो सकती है
      software industry latest tools, language features और frameworks के पीछे भागने में बहुत ज़्यादा समय लगाती है
      थोड़ा ठहराव आना और हर 6 महीने में नया हथौड़ा बनाने के बजाय मौजूद tools से काम पूरा करना सकारात्मक भी हो सकता है
    • अगर कोई developer अपने लिए code लिखने वाली किसी चीज़ के बिना काम नहीं कर सकता, तो समझ नहीं आता कि उसे hire क्यों किया जाए
    • मैं इस बात को लेकर बहुत चिंतित नहीं हूं, और Gumroad की चिंता भी शायद बढ़ा-चढ़ाकर बताई गई है
      comments से यह पता नहीं चलता कि क्या सच में AI को HTMX संभालने में दिक्कत हुई, या बात बस दूसरे resources की कमी पर चली गई
      large language models अक्सर general-purpose translators की तरह बहुत अच्छी तरह काम करते हैं
      वे popular frameworks के common patterns और concepts सीख लेते हैं, और अगर उन्हें छोटे framework की syntax कुछ हद तक पता हो, तो अनुभव के हिसाब से वे काफी अच्छा niche framework code भी बना देते हैं
      यह वैसा ही है जैसे pirates training data में कभी न बताए गए विषयों पर भी pirate अंदाज़ में बात कर सकते हैं

  • “dynamic validation और conditional fields वाले complex forms बनाते समय, React में जो साधारण client-side काम होता, उसे संभालने के लिए हमें complex server-side logic लिखना पड़ा” वाला हिस्सा देखकर Anakin Padme meme याद आता है
    “फिर भी server-side validation भी implement कर रहे हो न… कर रहे हो न?”

    • अगर web form कागज़ के form से ज़्यादा complex है, तो शायद उस web form के बारे में ही फिर से सोचना चाहिए
      React में आसान लेकिन htmx में कठिन form की कल्पना मुझे मुश्किल लगती है, सिवाय उस स्थिति के जहां आप React-style global application state ठूंसकर library से 90% काम निपटा देना चाहते हों
    • server पर भी validation होता है
      बस यह हर page पर नहीं, बल्कि submit करते समय एक बार होता है

  • “मैंने सोचा था कि frontend को बहुत हल्का रखने के लिए htmx अच्छा समाधान हो सकता है” वाली बात के उलट, ऐसा लगता है कि lightweight frontend छोड़ते ही htmx फिट नहीं रहा
    complex UI/UX और state management render करने के लिए उन्होंने third-party libraries इस्तेमाल करनी शुरू कर दीं
    साथ ही “React में X करना ज़्यादा आसान था” कहना, अगर आपने वह third-party library से किया, तो fair comparison नहीं है
    बस इसलिए आपको खुद नहीं करना पड़ा क्योंकि किसी और ने कर दिया था
    लेख से काफी सहमति है, लेकिन अगर पहले से पता था कि complex state और rendering चाहिए, तो htmx शुरू से ही अच्छा समाधान नहीं था

    • बिल्कुल यही बात लगती है
      मुझे htmx पसंद है, लेकिन यह लेख दिखाता है कि लेखक की technical understanding काफी सीमित थी
      ये वे फायदे-नुकसान नहीं थे जो web platform और htmx.org docs को थोड़ा भी जानने पर दिख जाते; बल्कि यह ज़्यादा ऐसा लगता है कि माहौल देखकर HTMX आज़माना चाहते थे
    • यह उन लोगों के लेखों का अच्छा mirror image है जिन्हें शुरू से React इस्तेमाल ही नहीं करना चाहिए था और जो लिखते हैं कि “React app को htmx में बदलते ही सब कुछ बहुत बेहतर हो गया”
    • htmx बनाम JavaScript का मामला behave के behavior-driven development tests और pytest tests की याद दिलाता है
      Gherkin language सरल मामलों में अच्छी लगती है और सिद्धांततः complex मामलों तक भी extend की जा सकती है, लेकिन जैसे-जैसे abstraction levels की कई परतें संभालनी पड़ती हैं, pure Python वाला pytest ज़्यादा सुविधाजनक हो जाता है
    • मैंने भी बिल्कुल यही सोचा
      project scope बिल्कुल भी “simple” नहीं था, और मेरे मामले में मैं सीधे React चुनता
    • सिर्फ desired features का description देखकर ही लग रहा था कि heavy JavaScript की ज़रूरत पड़नी तय थी

  • “workflow builder के लिए drag-and-drop interface लागू करना htmx में बड़ी चुनौती था, और React libraries से मिलने वाले smooth experience की तुलना में भद्दे workarounds की ज़रूरत पड़ी” वाले हिस्से पर: HTMX तब बेहतर है जब frontend bundle बस उतना ही करे जितना ज़रूरी हो, उससे ज़्यादा नहीं
    htmx.onLoad event से connect करने के बाद loaded content के अंदर attributes लगे markup—जैसे columns, cards, tasks आदि—ढूंढकर attach कर दें
    उदाहरण के लिए rendered markup पर sortable.js bind कर सकते हैं, और sortable events को HTMX के ज़रिए state updates से जोड़ सकते हैं
    यह काफ़ी सरल है, और docs में ठीक ऐसा ही example भी है: https://htmx.org/docs/#3rd-party

    • HTMX को UIKit components के साथ इस्तेमाल कर रहा हूँ
      आधुनिक, stateful और dynamic websites HTMX के साथ बिल्कुल भी असंगत नहीं हैं

  • लेख पढ़कर लगता है कि team backend development की तुलना में frontend development से ज़्यादा परिचित है
    पुराने ढंग के developer के नज़रिए से देखें तो कभी-कभी frontend developers के सोचने के तरीके में थोड़ा डर और कुछ गलतफहमी दिखती है
    सच कहूँ तो मुझे लगता है कि यह तरीका कैसे काम करता है, समझने के लिए बस सोच में थोड़ा सा adjustment चाहिए, लेकिन यह भी समझता हूँ कि बहुत लोगों ने अपने पूरे career में सामान्य client/server approach देखी ही नहीं है
    फिर भी तैयार React components की value और docs/help आसानी से मिल जाने का फायदा नज़रअंदाज़ नहीं किया जा सकता

    • मुझे लगता है कि htmx adoption की सबसे बड़ी बाधाओं में से एक सिर्फ developers नहीं, बल्कि UX designers का भी React-style में सोचना है
      designers की एक generation ने mobile और web को बहुत मिलता-जुलता design किया है, और implementation complexity developers पर डाल दी है
      लेकिन web, जहाँ संभव हो, mobile से अलग होना चाहिए और अलग हो भी सकता है
      लेख में कहा गया है कि design CRUD app जैसा बहुत “generic” था, लेकिन क्या यह वाकई बुरा है?
      हमारे पास सार्वभौमिक रूप से अपनाया गया document model जैसी बड़ी उपलब्धि है, जिससे सभी sites पर predictable user experience बनाया जा सकता है, लेकिन हम उसे सिर्फ “boring” मानते हैं
      जैसे boring होना अपने-आप में कोई मूलभूत समस्या हो
      mobile app जैसा महसूस होने वाला unique और branded experience मांगने वाला market pressure समझ आता है, लेकिन सोचता हूँ कि अगर designers React-style thinking जितनी ही WWW-style thinking भी कर पाते तो कैसा होता

  • अच्छा लगता है कि HTMX ऐसे और मिलते-जुलते लेख अपनी site पर publish करता है
    लगता है कि सिर्फ HTMX इनके लिए ठीक से fit न होने के कई उचित कारण थे
    मैं frontend expert नहीं हूँ, लेकिन कुछ विचार हैं
    पहला, क्या backend पर भी form validation करनी ही नहीं पड़ती?
    मुझे जिज्ञासा है कि backend system से frontend को results pass करना इतना मुश्किल क्यों था
    कई मामलों में frontend और backend दोनों जगह form validation करने के अच्छे कारण होते हैं, तो ऐसे में सिर्फ HTMX पर्याप्त नहीं होगा, लेकिन इस समस्या का वर्णन थोड़ा confusing है
    दूसरा, सिर्फ HTMX इस्तेमाल करने पर app कुछ हद तक इसी दिशा में धकेली जा सकती है, और कुछ cases में यह अच्छी बात होती है, लेकिन लगता है इन्होंने customers के लिए अलग तरीका ज़रूरी माना
    तीसरा, मैं और जानना चाहूँगा कि यह team AI tools का इस्तेमाल कैसे कर रही थी कि उन पर निर्भरता main issue बन गई
    आगे चलकर AI development tools महत्वपूर्ण हुए तो यह भी दिलचस्प सवाल है कि किसी नए framework या programming language को adopt कराने लायक tools और integrations पाने की bar बहुत ऊँची हो जाएगी या नहीं
    चौथा, HTMX के बारे में आम शिकायत की तरह, कुछ projects को HTMX जो देता है उससे ज़्यादा चाहिए होता है
    पाँचवाँ, Django और Python पसंद होने की एक वजह उनकी गहरी community, integrations और add-on ecosystem भी है
    concept में मिलती-जुलती लेकिन HTMX से ज़्यादा features वाली https://unpoly.com/ जैसी चीज़ शायद इनके लिए बेहतर fit होती

  • “Next.js का development process natural लगा” वाली बात पर, मुझे समझ नहीं आता कि इस ReactJS syntax का कौन-सा हिस्सा natural है
    यह familiar हो सकता है, लेकिन natural नहीं है
    useEffect(() => { const timer = setInterval(() => { setCount((prevCount) => prevCount + 1); }, 1000); return () => clearInterval(timer); }, []);

    • जहाँ तक मुझे पता है, HTMX में timers और intervals के लिए कोई elegant solution नहीं है
      आखिरकार JavaScript से awkward तरीके से जोड़ना ही पड़ेगा
    • यह code example तो काफ़ी उदार है
      अगर variable timeout वाला custom hook चाहिए, तो यह कहीं ज़्यादा जटिल हो सकता है
      Dan को भी इस topic पर लंबा लेख लिखना पड़ा था: https://overreacted.io/making-setinterval-declarative-with-r...
    • इस use case में natural दिखने वाला code कैसा होगा, यह जानना चाहूँगा
      क्या code लिखकर दिखा सकते हैं?

  • htmx.org ने इस लेख को host किया, यह सराहनीय है

    • मुझे लगता है कि कोई service या tool अगर यह भी समझाए कि उसे क्यों नहीं इस्तेमाल करना चाहिए, सिर्फ यह नहीं कि क्यों इस्तेमाल करना चाहिए, तो वह वाकई valuable है
    • ऐसा लेख publish करना सच में humble और honest रवैया है
      आखिरकार अगर कोई htmx उठाकर इस्तेमाल करे और फिर अपनी ज़रूरतें पूरी न होने पर नाराज़ हो, तो अब दिखाने के लिए एक resource भी है
    • यह https://htmx.org/essays/ में “On The Other Hand…” के नीचे linked है
    • शुरू में मुझे थोड़ा rant या sarcastic लेख की उम्मीद थी, लेकिन असल में अच्छे points वाला अच्छा लेख निकला, यह देखकर खुशी हुई
      मैंने अपने कुछ projects में htmx इस्तेमाल किया है और अनुभव काफ़ी अच्छा रहा
      ऐसे लेख rare तरीके से दिखाते हैं कि htmx कहाँ अच्छा करता है और कहाँ कम पड़ता है, इसलिए उल्टा htmx इस्तेमाल करने को लेकर मेरा confidence बढ़ता है

  • तीसरा point डरावना लगता है
    मैं ऐसी दुनिया की कल्पना करता हूँ जहाँ companies पैसे देकर अपने framework को model training set में over-sampled करवाएँ, और फिर उसी के आधार पर contracts बेचें
    यह कुछ-कुछ search engine optimization के development tools के अंदर baked in होने जैसा है