Dependency management की थकान: React को छोड़कर Go+HTMX+Templ चुनने की वजह

• इस साल Go, HTMX और Templ का उपयोग करके एक personal project करने के बाद React का उपयोग छोड़ने का फैसला किया
  • HTMX की official website पर React छोड़कर HTMX चुनने के कई ठोस तर्क मिलते हैं, लेकिन dependency management की थकान के बारे में बात करने वाले बहुत कम दिखे
• "Dependency management की थकान" क्या है?
  • React का उपयोग करने वाले आखिरी personal project (interactive Catalan dictionary) में यह महसूस हुआ कि React packages की dependency updates पर बहुत ज़्यादा समय खर्च हो रहा था
  • packages को latest release पर update करने से API में major changes आ जाते थे, जिनके कारण code refactoring पर समय लगाना पड़ता था
  • क्योंकि web app को EC2 instance पर public service के रूप में deploy किया गया था, इसलिए dependencies को updated रखना चाहता था
• क्या नई major version release सच में ज़रूरी है?
  • wouter (React router package) और TanStackQuery (backend से data fetch करने, cache करने और state manage करने के लिए इस्तेमाल) जैसे packages की major version updates ने web app को गंभीर रूप से तोड़ दिया
  • पहली बार जब major version update की वजह से application टूटा, तब बिना सवाल किए code refactor किया, लेकिन दूसरी बार ऐसा होने पर सवाल उठे
  • security patches को छोड़कर, major version releases से web app को वास्तव में क्या फ़ायदा मिल रहा है, इस पर संदेह हुआ
  • यह भी सवाल उठा कि क्या किसी मुख्य component की API को 5 बार तोड़ना सच में ज़रूरी है
  • यह सोचने लगा कि इस वजह से कितना समय खो रहा है, जिसमें नए features या दूसरे products release किए जा सकते थे
• समय की कमी की समस्या
  • personal coding projects के लिए ज़्यादा समय नहीं होने के कारण dependency की major version updates के बाद code refactor करने में समय बर्बाद नहीं करना चाहता
  • अगर clients के लिए product बना रहे हों और future maintenance work के लिए charge करने की योजना हो, तो बहुत सी unstable dependencies का उपयोग करना ठीक हो सकता है
  • लेकिन अगर ऐसा product बनाना हो जिसे न्यूनतम maintenance की ज़रूरत पड़े, तो JS ecosystem से दूर रहना बेहतर होगा
• Go+HTMX+Templ का उपयोग
  • personal projects में Go+HTMX+Templ उपयोग करने की मुख्य वजह यह है कि Go projects features release करने पर ध्यान केंद्रित करने देते हैं, जबकि सामान्य dependency/security updates की अनदेखी भी नहीं करनी पड़ती
  • Go भाषा खुद एक stable standard library और language specification बनाए रखती है.

[bbulbum]

लगता है HTMX को काफ़ी सकारात्मक प्रतिक्रिया मिल रही है.
मेरा ख़याल है कि SSR-आधारित applications के पूरक के तौर पर लोग HTMX को काफ़ी खोज रहे हैं.
लगता है मुझे भी side project में एक बार इसे आज़माना चाहिए.

[savvykang]

TanStack लाइब्रेरी मेरी ज़रूरत से ज़्यादा जटिल लगी, और पिछले कुछ सालों में documentation की quality भी कमज़ोर हुई है, इसलिए मैंने उसे नहीं चुना। और npm packages का replacement cycle भी इतना छोटा है कि हमेशा latest version पर अड़े रहने की सच में ज़रूरत है या नहीं, यह भी सवाल लगता है

हालाँकि कंपनी के काम में React को छोड़ना शायद संभव नहीं होगा। व्यक्तिगत प्रोजेक्ट हो तो जो चाहें इस्तेमाल कर सकते हैं।

[dohyun682]

अगर major version update न करें तो dependency problems बहुत ज़्यादा नहीं होतीं, है न...?

[aer0700]

कुछ समय पहले मैंने कंपनी के अंदर चल रहे एक scheduled job में Python 2 पर चलने वाला एक सिस्टम देखा, तो सचमुच साँस अटक गई।
काफ़ी सोचने के बाद हमने तय किया कि अभी यह ठीक चल रहा है, इसलिए फिलहाल इसे ऐसे ही रहने देते हैं। लेकिन बिना अपडेट किए कब तक टिके रह सकते हैं, यह भी स्पष्ट है।

[aer0700]

dependency management की थकान VS पहिया फिर से बनाने की ऊब
यह एक पुरानी बहस है। जिन पहियों की ज़रूरत नहीं है, उन्हें इस्तेमाल न करना सही है, लेकिन जो आज ज़रूरी नहीं है, क्या वह कल भी ज़रूरी नहीं होगा...
मैंने कभी Go इस्तेमाल नहीं किया है, लेकिन आजकल Go से बने सर्वर काफ़ी दिख रहे हैं। अभी तुरंत इस्तेमाल न भी करूँ, फिर भी एक बार इसे हाथ लगाकर देखना चाहिए।

[clickin]

HTMX शायद trendy तकनीकों में सबसे आगे है, इसलिए इसे लागू करके देखने वाले लोग काफी हैं, लेकिन मुझे लगता है कि इसकी बजाय go + vecty + gox जैसी दिशा कैसी रहेगी।

[GN⁺]

Hacker News टिप्पणियाँ

• React जैसी लाइब्रेरी छोड़कर Actix, Tera, HTMX के साथ web app विकसित करने का अनुभव साझा किया गया। यह stack बेहतर maintainability देता है और users के बीच लोकप्रिय हो रहा है

  • बताया गया कि एक नया web app तेज़ी से बनाकर test users को deploy किया गया
  • "dependency management fatigue" न होने की वजह से tools की गहरी समझ हासिल हो सकी

• Tanner की लाइब्रेरी में features बहुत हैं, लेकिन API design कमज़ोर बताया गया

  • React Table और React Query शक्तिशाली हैं, लेकिन उनकी boundaries ठीक से तय नहीं हैं, जिससे समस्याएँ पैदा होती हैं
  • React की ताकत यह है कि वह framework नहीं है, और अच्छी तरह डिज़ाइन की गई boundaries पर रुक जाता है
  • केवल उन्हीं libraries को अपनाने की कोशिश की जाती है जो इस मानक पर खरी उतरती हैं

• HTMX के examples complexity को बस किसी और हिस्से में ले जाते हैं, और JSX को templates से बचने का एक elegant तरीका बताया गया

  • routing, state management, authentication जैसी कई समस्याएँ अब भी हल करनी पड़ती हैं

• React को छोड़ने की बात करना अजीब लगता है, और दावा किया गया कि समस्या React नहीं बल्कि दूसरी dependencies में है

  • backend को Go में लिखने का विकल्प हमेशा से मौजूद था

• इस बात पर ज़ोर दिया गया कि package के अगले major version में update करते समय बदलाव अपेक्षित होने चाहिए

  • Remix का उदाहरण देकर समझाया गया कि changes को क्रमिक रूप से कैसे अपनाया जा सकता है
  • कहा गया कि अच्छे packages भी काफ़ी मेहनत माँगते हैं

• Django और HTMX के साथ SPA project migrate करने का अनुभव साझा किया गया, और बताया गया कि JavaScript dependencies बहुत कम हो गईं

  • कहा गया कि SPA किसी time bomb जैसा लगने लगा था

• कहा गया कि खराब तरह से maintain किए गए third-party packages के लिए React ज़िम्मेदार नहीं है

  • समझाया गया कि router या Redux जैसे state management tools ज़रूरी नहीं हैं

• माना गया कि react-query का v5, v3 API के साथ compatible होना चाहिए था, लेकिन migration आसान है और अनिवार्य नहीं है

  • महसूस किया गया कि "dependency management fatigue" को बढ़ा-चढ़ाकर पेश किया जाता है, और सलाह दी गई कि dependencies की संख्या समझदारी भरी रखी जाए

• यह सवाल उठाया गया कि जब web app को कोई अतिरिक्त लाभ नहीं मिल रहा था, तो upgrade क्यों किया गया

  • समझाया गया कि latest version में upgrade करना हमेशा फ़ायदेमंद नहीं होता

• React और nextjs छोड़कर दूसरे stack पर जाने के बाद stress कम हो गया, और updates अब depression जैसी भावना नहीं पैदा करते