Frontend ट्रेडमिल
(polotek.net)- लंबे समय तक चलने वाले products में Frontend framework का चुनाव करने से ज्यादा बड़ा खर्च, rewrite पर होने वाली बहसों में लगने वाला समय और ऊर्जा बन जाती है
- अगर product 5 साल बाद भी ज़िंदा है, तो यह सफलता है, लेकिन इस बीच चुना गया framework पुराना हो चुका होगा या उसी नाम के नए version में काफी बदल चुका होगा
- बेहतर product teams नए tools पर switch करने के बजाय मौजूदा framework को गहराई से समझती हैं, ताकि tool काम की प्रगति में बाधा न बने—इतनी proficiency बढ़ाती हैं
- लंबी अवधि की लागत घटानी हो, तो जटिल abstractions के बजाय web platform और core web technologies के करीब रहने वाला चुनाव एक व्यावहारिक business trade-off हो सकता है
- Frontend ecosystem की जटिलता नए developers और hiring teams दोनों के लिए मुश्किल पैदा करती है, और जिन developers की web fundamentals कमजोर हैं वे अगले stack बदलाव के प्रति ज्यादा कमजोर हो जाते हैं
Rewrite करके treadmill से निकलना मुश्किल है
- कई frontend teams मानती हैं कि rewrite उन्हें बेहतर स्थिति में ले जाएगा, लेकिन लंबे समय तक चलने वाले products में framework का चुनाव अपने-आप में सबसे महत्वपूर्ण technical decision नहीं होता
- अगर product 5 साल से ज्यादा टिकता है तो उसे सफलता माना जा सकता है, लेकिन इस अवधि में चुना गया framework पुराना हो सकता है
- Frontend community लगातार बदलाव के इर्द-गिर्द चलती रही है, और निकट भविष्य में इसके बदलने की संभावना भी कम है
- बचे हुए popular frameworks भी अंदर से पूरी तरह बदल सकते हैं, और नए version number के नीचे व्यवहार में rewrite हो सकते हैं
- Team को जिस चीज़ पर ध्यान देना चाहिए, वह नए और चमकदार tools का पीछा करना नहीं, बल्कि अभी इस्तेमाल हो रहे framework को पर्याप्त रूप से सीखना है
- इतनी समझ और proficiency चाहिए कि tool काम की प्रगति में बाधा न बने
- यह उम्मीद कि किसी alternative tool पर switch करने से समस्या हल हो जाएगी, एक जाल के करीब है
Web platform के जितने करीब, लंबी अवधि की लागत उतनी कम
- अगर कोई company frontend technologies के बार-बार पुराने हो जाने की लागत घटाना चाहती है, तो वह web platform के ज्यादा करीब जाने की दिशा पर विचार कर सकती है
- जटिल abstractions कम करने होंगे और फिर से सीखना होगा कि web वास्तव में क्या कर सकता है
- इसका मतलब यह नहीं कि यह हर समस्या का जवाब है या हमेशा बेहतर ही है
- यह लंबी अवधि में ज्यादा value देने और लागत कम करने वाला business trade-off हो सकता है
- Core web technologies के करीब रहने पर, भविष्य में सक्षम engineers hire करते समय इस दावे से कम प्रभावित होना पड़ेगा कि काम करने के लिए करोड़ों lines of code दोबारा लिखनी ही होंगी
- व्यक्तिगत engineers के लिए भी किसी खास framework का लगातार पीछा करने की तुलना में core web technologies को गहराई से समझना लंबी अवधि की market value के लिए ज्यादा मददगार है
- इससे short-term hiring marketability का कुछ हिस्सा छोड़ना पड़ सकता है
- Popular technologies सब सीखने वाले तरीके की तुलना में यह career sustainability के लिए ज्यादा फायदेमंद है
- किसी खास technology को जान लेने से market downturn जैसी realities से सुरक्षा नहीं मिलती
Framework preference और team cost
- जिन engineers की framework preference मजबूत है, उन्हें उस मानदंड को job search की शर्तों में शामिल करना चाहिए
- अगर वे किसी ऐसी team में शामिल होकर, जो पहले से किसी खास framework का इस्तेमाल कर रही है, उसे अपने पसंदीदा framework पर ले जाने की कोशिश करते हैं, तो इससे team अस्थिर होती है और cost काफी बढ़ती है
- मौजूदा frontend ecosystem की जटिलता नए developers और companies दोनों पर बोझ डालती है
- नए developers को नौकरी पाने लायक skills सीखना कठिन लगता है, और वे complex tools से overwhelmed हो जाते हैं
- Companies को सामान्य developers hire करना भी ज्यादा मुश्किल लगता है, और regular developer roles में entry bar भी ऊंचा हो जाता है
- अगर मौजूदा technology ecosystem सीखने वाला व्यक्ति web fundamentals नहीं सीख पाता, तो stack फिर बदलने पर वह गंभीर नुकसान में पड़ सकता है
- Web software deliver करने का एक सक्षम और unique platform है; समय के साथ यह बेहतर हुआ है और इसने उच्च स्तर की backward compatibility बनाए रखी है
- आज के basic tools काफी अच्छे हो चुके हैं, लेकिन framework layer platform को अपनाने के बजाय उसके उलट काम कर रही है
1 टिप्पणियां
Hacker News की राय
हाल ही में फ्रंटएंड कोड के build system को yarn से pnpm में बदलने का काम किया। मैं आम तौर पर backend engineer हूं, लेकिन JS साइड का भी अच्छा-खासा अनुभव रहा है
फ्रंटएंड में जाते समय सबसे ज्यादा चिढ़ाने वाली बात यह है कि सच में सब कुछ deprecated जैसा लगता है। अगर आपने 2022 में apollo CLI इस्तेमाल किया था, तो वह तुरंत deprecated हो चुका होगा और आपको graphql-client जैसे बिल्कुल अलग configuration और options वाले tool सीखने पड़ेंगे। आखिर में हमने पुरानी चीज़ ही बनाए रखी और बस pnpm का Node engine check बंद कर दिया ताकि वह शिकायत न करे। किसी dependency को patch upgrade करने की कोशिश करें तो type signature टूट सकता है, इसलिए उसे भी pin कर देते हैं, और codebase में TODO छोड़ देते हैं कि कभी कोई इसे ठीक कर देगा
बड़ी मुश्किल से जब इसे run कराने लायक बनाते हैं, तो install के दौरान सैकड़ों deprecated warnings बहती रहती हैं, और build खत्म होते ही वहां से भाग जाने का मन करता है
पूरा frontend development जिस हद तक breaking changes और deprecation को स्वीकार करता है, वह सच में अजीब लगता है। मैंने करीब 4 साल बड़े Rust projects पर काम किया है; उस दौरान third-party libraries में कुछ छोटे breaking changes तो हुए, लेकिन application में बड़े बदलाव करवाने वाला major change सिर्फ एक बार आया। इसके उलट JS में लगता है कि 6 महीने भी नहीं गुजरते और कुछ न कुछ दोबारा लिखना पड़ता है
Frontend दुनिया ने social media, YouTube, यहां तक कि Twitch को भी दूसरे क्षेत्रों की तुलना में कहीं ज्यादा सक्रिय रूप से अपनाया है। इन influencers को relevance बनाए रखने के लिए लगातार नया material चाहिए, इसलिए वे लगातार ऐसी नई चीज़ें आगे बढ़ाते हैं जिन पर content बनाया जा सके
इसमें active conference culture भी जुड़ जाता है। Frontend और JS conferences अक्सर उभरते नए विषयों पर presentation देने की बड़ी होड़ जैसी लगती हैं
Frontend courses बेचने का market भी बड़ा है। Course creators को boss से $700 का limited-price video course approve करवाना होता है ताकि लोग नया trend सीखें; इसके लिए industry को उन पुरानी चीज़ों से दूर धकेलना पड़ता है जिन्हें सब पहले से जानते हैं। इसलिए वे नई चीज़ों को जोर से push करते हैं और पुरानी चीज़ों को deprecated बना देते हैं
15 साल पहले लिखा गया एक छोटा 5KLOC का pure JS webapp आज भी एक भी line बदले बिना करीब 10 लोग रोज इस्तेमाल कर रहे हैं। बल्कि यह Win32 application से भी बेहतर टिक रहा है
मुझे लगता है frontend का ज्यादातर churn बस राजनीतिक और संगठनात्मक विफलता जैसा है
जब pure JS/jQuery के दौर में शुरुआत की थी, dependency management मूल रूप से
.jsfiles कोvendor/directory में copy करने जैसा था। फिर nodejs/npm आया, frontend में npm से पहले bower भी इस्तेमाल होता था, और अचानक standard सलाह यह हो गई कि खुद मत बनाओ, module download करोलेकिन तब भी कई लोग सवाल उठा रहे थे कि क्या हजारों lines का hidden code खुद own न करके, मजे के लिए open source करने वाले volunteers के भरोसे छोड़ना सही है
आज भी अगर आप project को लंबे समय तक maintain करना चाहते हैं, तो invisible हिस्से को जरूरत से ज्यादा बड़ा होने से बचा सकते हैं। छोटी समस्याओं को ऐसे हल किया जा सकता है: “इस library से सिर्फ एक function चाहिए, तो पूरी library पर depend करने के बजाय वही function codebase में copy करें और tests जोड़ दें”
इसलिए मुझे लगता है यह JavaScript की अपनी समस्या नहीं, बल्कि लोगों और process की समस्या है। बहुत से JS developers इस तरह की दिक्कत नहीं झेलते, लेकिन ecosystem का बड़ा हिस्सा जरूर झेलता है
“MultiselectDropdown को MultiSelectButtonDropdown में बदल दें तो कैसा रहेगा? API भी पूरी तरह नई कर देते हैं!” जैसे ‘बहुत महत्वपूर्ण’™ breaking changes के नतीजे ठीक करने में रोज हजारों person-hours खर्च होते हैं
Breaking API की भारी cost को समझने वाली culture लगभग नहीं है। 10 साल Go करने के बाद यह खास तौर पर frustrating लगता है। Go में backward compatibility का promise है, और लगता है इसका असर Go library developers के compatibility और breaking changes के प्रति रवैये पर भी पड़ता है। 10 साल पहले लिखा code latest Go में जस का तस compile और work करे, यह सच में अच्छा अनुभव है
इस JS/web hell से बचने के लिए मैं एक बार Flutter पर भी गया था; वह काफी suit किया और web stack की accidental complexity का बड़ा हिस्सा भूल पाया। लेकिन “package तोड़ना ठीक है” वाली culture Dart ecosystem में भी घुसती दिख रही है, जो बहुत परेशान करने वाला है
ईमानदारी से कहूं तो मुझे यह frontend से कहीं ज्यादा खराब लगता है। Frontend में फिर भी TypeScript और language features की वजह से damage का दायरा तुलनात्मक रूप से sane स्तर तक सीमित रहता है। Python में सच में literally कुछ भी कर सकते हैं, और इसलिए library authors भी literally कुछ भी करते हैं। Module import करने का तरीका बदलना है तो बदल देते हैं, metaclass के जरिए class behavior के बारे में सभी assumptions तोड़ना है तो वह भी संभव है। आपको लगे कि static typing मदद करेगी, लेकिन
Partialजैसी छोटी चीज़ भी नहीं होती, और दो objects एक ही type के हैं यह statically assert करना भी संभव नहींLibraries बदलने पर लोगों को शिकायत करते देखकर हंसी आती है। Python 2 से 3 का transition इतना भयानक था कि मेरी पिछली job में 100 million lines वाला Python monolith था, जिसे Python 3 पर upgrade करने की कोई योजना ही नहीं थी। SqlAlchemy 1 से 2 पर जाना 8-step migration है और practically पूरी rewrite है; एक भी चीज़ टूटे तो site down हो जाती है। लेकिन लोग React ने optional रूप से hooks जोड़ दिए, इस पर शिकायत करते हैं
अजीब बात यह है कि internet पर “frontend treadmill” वाले articles भरे पड़े हैं, लेकिन दूसरी तरफ के बारे में शिकायत करने वाले articles बहुत कम दिखते हैं
“अगर आप engineer हैं, तो core web technologies को जितना गहराई से समझेंगे, समय बीतने पर भी आपकी market value उतनी ही ज़्यादा बनी रहेगी” — इस बात पर, मैं लगभग 20 साल से frontend कर रहा हूँ और कई बड़े paradigm shifts देख चुका हूँ, इसलिए लगता है कि राय देने का हक है
core web technologies सब जानने से आप निश्चित रूप से ज़्यादा संतुलित engineer बनते हैं। लेकिन क्या इससे hiring market में आप ज़्यादा आकर्षक दिखते हैं, इस पर मुझे संदेह है। इसलिए नहीं कि यह knowledge महत्वपूर्ण नहीं है, बल्कि इसलिए कि hiring decision लेने वाले आम तौर पर pattern matching करते हैं
अगर आप “market value” maximize करना चाहते हैं, तो अब भी आपको React बहुत अच्छी तरह आना चाहिए। यह लगभग basic entry ticket जैसा है, और बाकी चीज़ें शानदार हैं, लेकिन यह आधार न हो तो options कम हो जाते हैं। शायद लेखक का मतलब भी यही था और मैंने गलत पढ़ लिया हो
हालांकि consulting या contract roles जैसी भूमिकाओं में मैं original comment से सहमत हूँ। जब आप बड़ी consulting कंपनियों में hiring या interview के लिए shortlist करने वाले लोगों के साथ काम करते हैं, तो वे अपने पसंदीदा stack या current client द्वारा इस्तेमाल किए जा रहे stack को पहले से न जानने वालों को लगभग automatic reject कर देते हैं। technical architects भी ऐसा करते हैं, इसलिए यह सिर्फ non-technical recruiters की समस्या नहीं है। skill level से अलग, वे technology itself में adapt करने का समय नहीं चाहते
ऐसी roles में लगातार up-to-date रहना बहुत महत्वपूर्ण है। नहीं तो hiring manager engineer से skill evaluate करवाने से पहले ही buzzword न होने की वजह से resume फेंक देता है
यह unusual case हो सकता है, लेकिन React न जानना कभी issue नहीं बना। “basic entry ticket” कहना बहुत ज़्यादा strong है
frontend compensation पर काफी solid ceiling होती है। एक level से ऊपर जाने पर आपको फिर कभी UI बनाने की ज़रूरत नहीं पड़ती
ज़्यादातर कंपनियाँ, यहाँ तक कि बड़ी कंपनियाँ भी core fundamentals की बहुत परवाह नहीं करतीं, उन्हें verify नहीं करतीं, और न ही उसी आधार पर hire करती हैं। वे “React अच्छा आता है” या “Next.js का बहुत experience है” जैसे criteria पर hire करती हैं
fundamentals तब शानदार होते हैं जब आप शुरुआत से कुछ बना रहे हों, लेकिन असली companies ऐसा बहुत कम करती हैं। आम तौर पर वे बड़ा ecosystem और अच्छी documentation वाले ready-made tools उठा लेती हैं। उनमें अच्छे होंगे तो hiring कहीं आसान हो जाती है, और fundamentals आप उसी process में सीख सकते हैं
“आप कोई भी framework चुनें, 5 साल बाद वह obsolete हो जाएगा” — यह बात थोड़ी पुरानी logic जैसी लगती है
मैं मुख्य रूप से frontend developer नहीं हूँ, लेकिन frontend करने से बचता भी नहीं, और पिछले लगभग 10 साल से React इस्तेमाल कर रहा हूँ। Svelte की तरफ कुछ माहौल shift हो रहा है, लेकिन जब तक Svelte React को overtake करेगा, शायद Svelte भी उतने ही लंबे समय तक production में इस्तेमाल हो चुका होगा। Angular की momentum भी कभी कम हो सकती है, लेकिन Angular1 और Angular2+ के दौर को साथ देखें तो वह React से भी पुराना है
frontend development तेजी से चलता है, यह सही है, लेकिन इतना भी बुरा नहीं। boring choices चुनेंगे तो boring results मिलेंगे
Angular1 और 2 नाम छोड़ दें तो लगभग compare ही नहीं किए जा सकते थे, और कई developers इसी में जल गए। Angular खुद भी काफी बड़ा बदल रहा है। v1 से Angular2 पर जाने जितना extreme नहीं है, लेकिन फिर भी इतनी re-adaptation चाहिए कि असर बड़ा हो। सब कुछ standalone component, नई template syntax, signals आदि की तरफ जा रहा है
React भी ऐसा ही है। functional components और hooks के आने से बड़ा paradigm shift हुआ। compatible था, लेकिन दोनों बहुत अलग थे
अधिक general paradigms में भी यही है। शुरुआत में सब server-side rendering था, फिर single-page apps की तरफ full sprint किया, और अब फिर server-side rendering पर लौटे हैं, लेकिन इस बार hydration वाली partial server-side rendering के रूप में
इतना अलग कि इसे अलग framework कहा जा सकता है, इसलिए nuance है, लेकिन वह logic पूरी तरह खत्म नहीं हुई
इसके साथ काम करना सचमुच बहुत simple है। मैंने एक simple stock allocation app बनाया और सबसे ज़्यादा चौंकाने वाली चीज़ bundle size थी। gzip के हिसाब से 9KB था, और मेरे जानने वाले किसी भी framework से छोटा। कुछ हद तक “anti-JS” के करीब htmx से भी छोटा
पुराने frameworks भी बहुत लंबे समय तक चल सकते हैं। अगर उस stack को जानने वाले लोग मौजूद हैं और ज़रूरत पड़ने पर hire करके काम कराया जा सकता है, तो वह stack obsolete नहीं है। “पुराना” या “legacy” कहना सही हो सकता है। लेकिन जिस दिन उसे संभालने वाला कोई भी न बचे, उससे पहले तक वह obsolete नहीं है
इसे frontend समस्या कहना दिलचस्प है। यह frontend समस्या नहीं, बल्कि एक विशाल ecosystem में नए प्रतिभागियों के लगातार आते रहने की समस्या है
15 साल पहले जब Java innovation के सबसे आगे था, तब भी यही चीज़ देखी थी। कुछ ही वर्षों में दर्जनों frameworks और कई build systems आ गए थे। React 17 से 18 में बदलाव, Perl 5 से 6 या Python 2 से 3 पर जाने की तुलना में बहुत छोटा बदलाव है
backend में “नया framework इस्तेमाल करें” की जगह “नई language इस्तेमाल करें” आता है। आजकल का trend किसी चीज़ को Rust में फिर से लिखना है; उससे पहले Go, Haskell, Scala, F# भी थे
अगर आपको frontend code को React से Svelte जैसी किसी चीज़ में ले जाना झंझट लगता है, तो VB 6 app को फिर से लिखकर देखिए। code के अंदर data वाले RPC जैसी चीज़ों की तो बात ही छोड़िए
इसका मतलब यह नहीं कि engineering practices की अस्थिरता समस्या नहीं है। यह बड़ी समस्या है। बस यह केवल frontend की समस्या नहीं है
webpack भी 13 साल पुराना है, लेकिन पिछले कुछ वर्षों में भी इसकी configuration शैली नाटकीय रूप से बदली है
अगर Apache configuration इन systems जितनी बार बदलती, तो कोई भी Apache इस्तेमाल नहीं करता
पिछली नौकरी में 2 साल में दो database migrations हुईं, और कुल मिलाकर 1 साल का engineering time लगा। यह कुछ non-core tables तक सीमित नहीं था, बल्कि सभी tables इसका हिस्सा थे। कुछ टूटता या ऊपर से पूछा जाता कि इतना धीमा क्यों है, तो वे कम अनुभव का हवाला देकर frontend सीख रहे engineers को दोष देते थे
मैंने 25 साल से ज्यादा Java developer के रूप में काम किया है, और शुरुआती 10 साल से कुछ अधिक समय full-stack development किया, जो उस समय कंपनियों का सामान्य तरीका था। अब अलग frontend team होना आम है, और कई जगह web, iOS, Android के लिए तीन teams भी होती हैं। मेरे लिए यह बदलाव लगभग AngularJS से Angular में जाने के समय के आसपास हुआ
Java भी शुरुआती करीब 10 साल तेज़ी से बदला, खासकर पहले 3 साल बहुत तेज़ थे। लेकिन वह दौर खत्म हो गया। Java 5 बड़ा बदलाव था और Java 8 में भी महत्वपूर्ण features थे, लेकिन Java 8 2014 में आया था। हमारी team हाल ही में Java 11 पर गई, और अब Java 24 आ चुका है। मैंने Java 11 features कभी इस्तेमाल नहीं किए, और मुझे यह भी नहीं पता वे क्या हैं। 10 साल में मैंने कोई नया language feature नहीं सीखा
build tools पिछले 15 साल से वही हैं, और IDE पिछले 20 साल से वही है। मुख्य framework भी 10 साल से वही है। जब मैं पिछली नौकरी में गया, तो codebase structure पिछली team जैसा ही था
Java में web services बनाना सुलझी हुई समस्या है। अच्छे अर्थ में पूरी तरह उबाऊ, COBOL जैसी
frontend 90 के दशक के अंत और 2000 के शुरुआती वर्षों में भी तेज़ी से बदलता था, लेकिन उसके बाद भी लगातार तेज़ी से बदलता रहा है। कुछ साल पहले बनाया गया मेरा personal UI project पूरी तरह पुराना पड़ चुका है
EJB के बाद के दौर में जिन Java projects पर मैंने काम किया, उनमें आज किसी Java developer को ढूंढकर लगा दें तो वह तुरंत productive हो सकेगा। भले ही वह developer project बनने के बाद पैदा हुआ हो। बस कुछ पुरानी libraries सीखनी होंगी
treadmill से उतरने का तरीका frontend framework बिल्कुल न इस्तेमाल करना है। कोई random दूसरा framework चुनकर बाद में फिर से लिखना नहीं
server-side rendering, जरूरत पड़ने पर ही JavaScript, और company के अंदर backend और frontend लोगों को अलग-अलग न बांटने का तरीका चाहिए
अगर एक engineer SSR web view के लिए ठीक वही columns लाने वाला SQL लिख सके और उसी web view की जिम्मेदारी भी ले सके, तो API या ORM जैसी चीज़ों के बारे में एक सेकंड भी सोचने की जरूरत नहीं। बस SQL और modern pure HTML/CSS/JS जानना काफी है। ज्यादातर काम business के view (SQL) को DOM (HTML) में बदलना बन जाता है, और server-side programming ecosystem पीछे हट जाता है
मुझे लगता है अंतिम रूप RDBMS के अंदर web content को SSR करना है। Oracle APEX जैसा तरीका। लेकिन ज्यादातर engineers अभी उस बातचीत के लिए तैयार नहीं हैं। मैं भी असल field में पहली बार देखकर ऐसा ही था। हम अपने तकलीफ झेलने के तरीकों से बहुत लगाव रखते हैं
इसने frontend के जरूरत से ज्यादा जटिल होने की समस्या को और बढ़ाया। frontend team में लोग हैं, इसलिए वे लगातार काम पैदा करते हैं और complexity जोड़ते हैं। यह भी समस्या है कि बहुत से लोग सिर्फ web development जानते हैं और कुछ नहीं
side project में मैंने शुरुआती constraints में से एक यह रखा कि JavaScript बंद करने पर भी पूरी site gracefully degrade हो। इससे जब भी कोई ऐसा feature जोड़ना होता जो आम तौर पर JavaScript से किया जाता है, तो मैं पूछता, “क्या यह JavaScript के बिना हो सकता है?” और अब तक हैरानी की बात है कि जवाब हमेशा yes रहा है
basic HTML controls पर CSS selectors भर से आजकल सचमुच बहुत कुछ किया जा सकता है। उस codebase में अभी JS की एक भी line नहीं है
product/design teams usability, performance, accessibility, अच्छे engineering की कोई परवाह किए बिना जितनी हो सके उतनी JavaScript सजावट जोड़ने का दबाव डाल सकती हैं
मैं frontend में अच्छा नहीं हूं, और designer भी नहीं हूं। backend में मैं काफी बेहतर हूं, लेकिन team के दूसरे लोग frontend design में मुझसे ज्यादा talented हैं
पहली वेबसाइट बनाते समय “Svelte, React से बेहतर है”, “solid-js अगली बड़ी चीज़ बनने वाला है” जैसे लेख पढ़े और लगा कि यही वेब डेवलपमेंट का अहम हिस्सा है
शुरुआती लोगों के लिए बेहतर है कि वे MDN पढ़ें और बाकी चीज़ों को अनदेखा करें
लोगों को tutorials और walkthroughs की ज़रूरत होती है, और यह समझ बनाने की ज़रूरत होती है कि ये सब अंदर से कैसे काम करता है
frameworks ऐसी चीज़ों को abstract करने में मदद करते हैं
लेकिन हाल की Next.js और SSR की दीवानगी शायद वैसी न हो। निजी तौर पर मुझे लगता है कि यह React पक्ष के पतन का कारण भी बन सकती है
पिछले कुछ वर्षों में pure JS और CSS की प्रगति को देखते हुए, और
display: noneanimation जैसी दिलचस्प सुविधाओं के लगभग अपनाए जाने के चरण तक पहुँचने को देखते हुए, server पर template HTML बनाना और जहाँ ज़रूरत हो वहीं JS इस्तेमाल करना पहले से कहीं ज़्यादा उचित लगता हैयह बात मैं एक ऐसे व्यक्ति के तौर पर कह रहा हूँ जिसकी रोज़ी-रोटी मुख्य रूप से React से चलती है
लेखक की तरह मैंने भी अलग-अलग तरीकों से 20 साल तक frontend किया है। ecosystem, churn, और frontend व backend के बीच state sync करने की कलाबाज़ी सचमुच पागलपन के स्तर की है
हाल ही में Go templates और HTMX के साथ एक proof-of-concept project शुरू किया है, और React की तरह UI को “components” से बनाने का एहसास करीब लाने की कोशिश कर रहा हूँ। अभी बहुत rough edges हैं, लेकिन संभावना है। सच कहूँ तो अभी यह भी पक्का नहीं कि HTMX की ज़रूरत है या नहीं। मैंने event listeners को सीधे manage करना शुरू किया है, और लगता है वह तरीका मुझे ज़्यादा पसंद आ रहा है
दिलचस्प बात यह है कि user roles और permissions पर आधारित जटिल UI state management server पर कहीं आसान है। user जो HTML देख सकता है, बस वही भेज दो
हालांकि React, Vue वगैरह के पास बहुत ज़बरदस्त momentum है। सोच में सामूहिक बदलाव कैसे शुरू हो सकता है, समझ नहीं आता। खासकर यह देखते हुए कि बहुत से developers UI बनाने के तरीके के रूप में frontend frameworks के अलावा कुछ जानते ही नहीं
“जो भी framework चुनो, 5 साल बाद obsolete हो जाएगा” वाली बात पर मुझे यकीन नहीं
10 साल से ज़्यादा समय से पेशेवर तौर पर React इस्तेमाल कर रहा हूँ
package.jsonमें कितनी dependencies declare हैं? आपकी team कौन सा node/npm version इस्तेमाल करती है?अगर आप पर्याप्त नया version और popular libraries इस्तेमाल करते हैं, तो
npm installके दौरान sub-dependencies के लिए deprecated notifications का ढेर देखा होगान्याय की बात करें तो React code ने खुद backward compatibility काफी अच्छी तरह बनाए रखी है। यह React की गलती नहीं है। लेकिन 5 साल पहले इस्तेमाल होने वाले build systems सब बदल गए और backward compatibility तोड़ दी। component lifecycle methods भी याद ही नहीं रहे थे
React जैसा अच्छी तरह maintained project भी अपने ecosystem की गंदगी से बच नहीं सकता
हमेशा विकल्प नहीं होता, लेकिन आजकल मैं आम तौर पर pure JS को build system के बिना import करता हूँ, जितना संभव हो Python/Django backend में handle करता हूँ, और JavaScript ecosystem से पूरी तरह बाहर निकलने का तरीका चुनता हूँ। कभी पछतावा नहीं हुआ
क्या अब भी app को React 15 पर रखे हुए हैं?
React 16 पर चलने वाले सभी WYSIWYG editors अब support नहीं होते। अगर security issue मिल जाए तो “किस्मत के भरोसे” वाली स्थिति है। या फिर उन्हें इस्तेमाल ही नहीं करना चाहिए
React 16 अभी भी supported है, लेकिन निश्चित रूप से obsolete है
जवाबी तर्क यह है कि अगर framework नहीं अपनाते, तो आखिर में आप ऐसा अपना framework बना लेते हैं जिसे team के बाहर के लोग समझ नहीं पाते, जिसकी documentation आम तौर पर कमजोर होती है, और जिसमें उन features को जोड़ने पर लगातार काम करना पड़ता है जो मौजूदा frameworks में पहले से मौजूद हैं
frontend में आम तौर पर ज़रूरी features और हल करने लायक common problems होते हैं। बिल्कुल खाली से शुरू करने के बजाय कम से कम कुछ आधार लेकर शुरू करना बेहतर नहीं है?
जिसने internal framework कभी देखा ही नहीं, ऐसा व्यक्ति तुरंत productive हो सके—ऐसा ढूँढना असंभव है। documentation बहुत अच्छी भी हो, तो भी सीखने और आत्मसात करने में समय लगता है। लंबी अवधि की hiring हो तो सबसे बुरा नहीं, लेकिन अस्थायी रूप से और developers चाहिए हों तो कोई रास्ता नहीं बचता
जैसा मैंने कहीं और भी लिखा, लगभग हर कोई webapp चाहता है या सोचता है कि उनके पास webapp है, लेकिन असल में वह ज़्यादातर dynamic website ही होती है। dynamic website बनाने के लिए frameworks की परतें चढ़ाने की ज़रूरत नहीं है
यह frontend की समस्या नहीं, JS ecosystem की समस्या है। backend में भी ऐसा होता है
JS environment dependencies की ऐसी पूरी अफरा-तफरी है जहाँ दर्जनों, सैकड़ों दूसरी dependencies होती हैं। उदाहरण के लिए Fastify आधारित Node framework Platformatic का dependency graph यह है
https://npmgraph.js.org/?q=platformatic#zoom=h
ये dependencies किसी भी समय छोड़ी जा सकती हैं। Axios या Express जैसी बड़ी dependencies भी कभी उपेक्षित लगती थीं
और हर dependency maintainer को जो तरीका सही लगता है, उसी से नियंत्रित होती है। कुछ दिन पहले production में इस्तेमाल होने वाली एक dependency ने, जिसके लगभग 2.5 करोड़ downloads प्रति सप्ताह हैं, जबकि React लगभग 2.6 करोड़ पर है, और जो 1 करोड़ GitHub repositories में इस्तेमाल होती है, यह तय किया कि लगभग 3 साल पुराने Safari versions का support छोड़ देना ठीक है। यह देखते हुए कि Safari की अमेरिकी mobile market share 50% से ज़्यादा है, यह सचमुच पागलपन है