क्या वाकई किसी को React पसंद है?

 (jsx.lol)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 3 टिप्पणियां | WhatsApp पर शेयर करें
  • React और React-आधारित टूल्स पर आलोचनात्मक लेखों को क्यूरेट करके तैयार किया गया संकलन, जिसमें अलग-अलग डेवलपर और ब्लॉगरों के लेख उद्धरण रूप में व्यवस्थित किए गए हैं
  • इसमें React की संरचनात्मक सीमाओं की ओर इशारा करने वाले कई लेख शामिल हैं, जैसे performance में गिरावट, complexity में बढ़ोतरी, और hydration समस्याएँ
  • React-केंद्रित तकनीकी चयन तकनीकी उपयुक्तता से अधिक जड़ता और network effect के कारण मानक बन गया है, और “सबको React आता है” जैसी धारणा architecture के फैसलों से पहले रखी जाती है—ऐसी आलोचना की गई है
  • React Server Components और Next.js को लेकर security और governance संबंधी चिंताएँ बढ़ी हैं, और CVE-2025-55182 को CVSS 10.0 रेटिंग वाली unauthenticated remote code execution vulnerability के रूप में सार्वजनिक किया गया
  • React ecosystem में API design की उलझन, quality crisis, और complexity लंबी अवधि के maintenance और learning को कठिन बनाती हैं, और Hooks, modern UI features, तथा release flow तक React की दिशा पर बहस को आगे बढ़ाती हैं

साइट का परिचय

  • "Does anybody actually like React?" जैसे उकसाने वाले सवाल के साथ बनाई गई एक क्यूरेशन साइट
  • React और React से प्रभावित टूल्स पर आलोचनात्मक लेखों का cherry-picked collection
  • RSS subscription सुविधा उपलब्ध

खुद React पर बुनियादी आलोचना

  • The End

    • React लगभग हमेशा गलत समाधान होता है, और हर चीज़ को कील की तरह दिखाने वाला हथौड़ा बन चुका है
    • React का सही इस्तेमाल संभव है, लेकिन व्यवहार में ऐसा बहुत कम होता है

  • JS-heavy approaches are not compatible with long-term performance goals

    • एक निश्चित पैमाने से बड़े JS-केंद्रित प्रोजेक्ट दावे से अधिक धीमे होते हैं, और समय के साथ और भी धीमे हो जाते हैं
    • development और maintenance में अधिक मेहनत लगती है, और दूसरे approaches जितने ही नहीं बल्कि उतने ही bugs भी होते हैं

  • React Still Feels Insane And No One Is Talking About It

    • React को “बस पागलपन” कह देना आसान है, लेकिन इसे तर्कसंगत रूप से समझने की कोशिश भी ज़रूरी है

  • Stop Using and Recommending React

    • लंबे समय तक React इस्तेमाल करने के अनुभव के आधार पर, इसे इस्तेमाल करने की वजह कोई नहीं और विरोध करने की वजहें बहुत हैं

  • Please don't use React

    • React का इस्तेमाल बंद कर देना चाहिए, और शुरुआत से ही इसका उपयोग नहीं करना चाहिए था—ऐसा तर्क

  • Tech Founder? Entrepreneur? This is why you should avoid React.js in your app

    • React सिर्फ धीमा नहीं है, बल्कि एक ऐसा फूला हुआ ecosystem है जिसके DNA में technical debt दर्ज है
    • इसके बावजूद इसे लगातार चुने जाने की वास्तविकता पर सवाल उठाया गया है

सुरक्षा और governance समस्याएँ

  • Critical Security Vulnerability in React Server Components

    • 29 नवंबर को Lachlan Davidson ने unauthenticated remote code execution (RCE) vulnerability की रिपोर्ट की
    • इसे CVE-2025-55182 के रूप में सार्वजनिक किया गया, CVSS 10.0 रेटिंग के साथ

  • You should know this before choosing Next.js

    • Vercel ने Next.js में एक गंभीर security vulnerability का खुलासा किया
    • मुद्दा अपने आप में सामान्य था, लेकिन Vercel की प्रतिक्रिया कमजोर और गैर-जिम्मेदाराना थी
    • इससे project governance को लेकर चिंताएँ और गहरी हुईं

  • Next.js 15.1+ is unusable outside of Vercel

    • Next.js अब open source framework के भेष में Vercel vendor lock-in का रूप ले चुका है

API design और learning curve की समस्याएँ

  • Is it Time to Regulate React?

    • React की मुख्य विफलता को भ्रमित करने वाली API design और बढ़ा देती है
    • documentation अनिर्णयपूर्ण है, और सही उपयोग को लेकर बहस कभी खत्म नहीं होती

  • I don't have time to learn React

    • React modern UI सिखाता है—इस दावे के उलट, व्यवहार में यह modern UI को लगभग छूता ही नहीं
    • autofocus टूटा हुआ है, और custom elements experimental version के बाहर काम नहीं करते
    • dialog, popover जैसी modern सुविधाओं का उपयोग करने के लिए useEffect की ज़रूरत पड़ती है
    • synthetic event system की वजह से असली DOM behavior लगभग सीखा ही नहीं जा सकता
    • यह modern UI नहीं, बल्कि 2013-स्तर का UI है

  • The React Blog Post: Reflections and Reactions

    • हर समस्या को “skill issue” कहकर टाल देना और कहना कि बाहरी libraries से सब हल हो जाएगा—यह रवैया अजीब है
    • तकनीक ऐसी होनी चाहिए कि 3 साल बाद लौटकर भी उस पर काम किया जा सके, लेकिन frontend, खासकर React, ऐसा नहीं है

  • React, where are you going?

    • आज React को कम आनंददायक बनाने वाली दो समस्याएँ: ownership और complexity
    • चिंता है कि नए डेवलपर React से घबरा सकते हैं

performance और user experience की समस्याएँ

  • Why use React?

    • मूल रूप से आप कुख्यात hydration pattern में फँस जाते हैं
    • संरचना यह है कि server पर JS से सारा computation किया जाता है, HTML तुरंत भेजा जाता है, और फिर वही JS दोबारा client को भेजा जाता है

  • How React 19 (Almost) Made the Internet Slower

    • सार्वजनिक विरोध और तीखी बहस के बाद React टीम ने बदलाव रोक दिया

  • An even faster Microsoft Edge

    • React से modern Web Components + HTML-first architecture की ओर बदलाव
    • खासकर कमज़ोर हार्डवेयर इस्तेमाल करने वाले users को बड़ा फायदा

  • Switching costs

    • client-side React द्वारा थोपी गई भयानक user experience को लेकर और शिकायतें सामने आनी चाहिए—ऐसी उम्मीद
    • लेकिन वास्तविक शिकायतें लगभग पूरी तरह developer experience पर केंद्रित हैं

  • Pivoting From React to Native DOM APIs: A Real World Example

    • एक development टीम ने React के “हावी VDOM” से modern DOM API की ओर रुख किया
    • गति और interaction में सुधार तुरंत महसूस हुआ

मोबाइल और प्लेटफ़ॉर्म समस्याएँ

ecosystem और community की समस्याएँ

  • React Won by Default – And It's Killing Frontend Innovation

    • जब नए frontend की ज़रूरत होती है, तो शुरुआत "constraints क्या हैं और कौन-सा tool सही है" से नहीं, बल्कि "React इस्तेमाल करें, सब जानते हैं" से होती है
    • technical fit नहीं, बल्कि network effects architecture तय करने वाला self-reinforcing cycle बन जाते हैं

  • Conferences, Clarity, and Smokescreens

    • consulting काम और industry data के अनुसार React community गंभीर और मापी जा सकने वाली quality crisis में फँसी हुई है
    • React Summit के attendees यह बात सुन ही नहीं पाते

  • Why Silicon Valley CTOs Are Secretly Moving Away from React

    • React developers बहुत हैं, लेकिन गहरे patterns को समझने वाले असली experts लगातार अधिक दुर्लभ और महंगे होते जा रहे हैं
    • सबसे अनुभवी engineers complexity से थककर दूसरे tech stacks में जा रहे हैं

  • Increasingly miffed about the state of React releases

    • पिछली React release के बाद डेढ़ साल बीत चुके हैं, जो किसी भी पहले के release cycle से लंबा है

React Server Components की आलोचना

  • React Server Components: the Good, the Bad, and the Ugly

    • React ने client-side improvements पर लगभग काम करना छोड़ दिया था (2019 में experiment बंद होने के बाद)
    • Facebook-scale problems को Facebook-scale resources से हल करने के लिए बनाया गया legacy framework, जो ज़्यादातर use cases के लिए उपयुक्त नहीं है

  • React Server Components are a bad choice (for shipping)

    • अगर जल्दी ship करना है, तो React Server Components का इस्तेमाल नहीं करना चाहिए
    • learning, experimentation और content creation के लिए इनका उपयोग किया जा सकता है

basics की ओर वापसी और alternatives पर ज़ोर

  • HTML is better than React!?

    • HTML-आधारित progressive enhancement के फायदे
      • users को जल्दी usable experience मिलता है
      • धीमे connection पर भी site खराब नहीं दिखती
      • दिक्कत आने पर भी users site का उपयोग जारी रख सकते हैं

  • How to build a counter component using the HTML Framework in just 1 line of code

    • node_modules folder ढूँढकर उसे trash में drag करने की व्यंग्यात्मक सलाह

  • Liskov's Gun: The parallel evolution of React and Web Components

    • React झूठे वादों, भ्रामक दावों और अंतहीन backward-compatibility layers से फूला हुआ मलबा बन चुका है
    • update के समय यह अक्सर code भी तोड़ देता है

  • Removing React is just weakness leaving your codebase

    • React जैसे भारी framework से बाहर निकलकर web fundamentals पर ध्यान देना career और codebase, दोनों को future-proof बनाता है

  • Concatenating text

    • जब screen update की ज़रूरत हो, तो सबके दिमाग में सबसे पहले React ही क्यों आता है
    • frontend और backend concerns को एक साथ बाँधने की प्रवृत्ति पर सवाल

migration और transition के उदाहरण

  • We Rewrote our React App in Svelte in Three Weeks

    • Svelte को "सबसे पसंदीदा" framework कहने वाली headlines को नज़रअंदाज़ किया था, लेकिन अब Svelte camp में शामिल हो गए हैं

  • Moving on from React

    • 2023 में React के साथ गलत शुरुआत के बाद, ऐसे tech stack पर गए जो customer domain के लिए बेहतर fit था

  • Moving on from React, a Year Later

    • "fat client" दौर के JS-heavy frontend अब धीरे-धीरे खत्म हो रहे हैं
    • edge application hype कई तरह के business बनाने के लिए ज़रूरी नहीं है

  • Replacing React: How Liveview solved our performance problems

    • React SPA की performance समस्याओं के कारण LiveView की खोज की गई
    • 2 दिनों की पड़ताल के बाद भरोसा हो गया, और कुछ ही हफ्तों में React SPA को LiveView से बदल दिया गया

समग्र रुझान और आगे की दिशा

  • The Neverending Story

    • Applets, ActiveX, Flash, Flex, Silverlight, Angular और React तक चलने वाली धारा
    • बड़ी तस्वीर न देख पाने वाली कंपनियों की बार-बार की विफलता

  • If Not React, Then What?

    • Frameworkism users के अनुभव को बेहतर बनाने के उपाय के रूप में और अधिक (या अलग) framework tools अपनाने का उपदेश देता है
    • यह लोगों को ऐसी गतिविधियों में डुबो देता है जो engineering जैसी दिखती हैं, लेकिन वास्तव में वैसी नहीं होतीं

  • Reckoning: Part 4 — The Way Out

    • YAJSD (Yet Another JavaScript Disaster) बनाने की योजना से सहमत नहीं होना चाहिए
    • जब React rewrite का प्रस्ताव आए, तो senior engineers को चुप नहीं रहना चाहिए

  • After a Decade of React, Is Frontend a Post-React World Now?

    • नए web developers के लिए React को पूरी तरह टालने का विकल्प भी गंभीरता से विचार करने योग्य है
    • short-term job prospects कम हो सकते हैं, लेकिन आगे की सोच रखने वाले employers के साथ match होने की संभावना रहती है

  • React, Electron, and LLMs have a common purpose: the labour arbitrage theory of dev tool popularity

    • वेब-उन्मुख सॉफ़्टवेयर बनाने वाले अधिकांश संगठनों में React वस्तुनिष्ठ रूप से कई विकल्पों से कमतर है

  • It feels like React is getting a bit of a kicking recently

    • React के प्रति कम्युनिटी के बदलते रवैये और प्रोजेक्ट निर्णयों के लिए सिफारिशें

  • Kind of annoyed at React

    • जटिल चीज़ें बनाते समय अब भी React को चुनता हूँ, लेकिन अफ़सोस है कि काश यह चुनाव ज़्यादा सुखद होता

  • Am I the only one that thinks that the direction of React is wrong?

    • ऐसा आभास कि React अपने ही नियमों के साथ अपना अलग खेल खेल रहा है

  • Client-side JavaScript and React criticism: What comes next?

    • JavaScript उपयोग में सुधार, progressive enhancement की शिक्षा, और कम्युनिटी मेल-मिलाप के तरीकों पर चर्चा

  • A Historical Reference of React Criticism

    • वर्षों से React प्रोजेक्ट पर उठी आलोचनाओं का ऐतिहासिक संकलन
    • कुछ का समाधान हो चुका है और कुछ अब भी अनसुलझे हैं

Hooks और वैकल्पिक paradigm

  • Why Signals Are Better Than React Hooks

    • React के Hooks को सही तरीके से इस्तेमाल करना ही कठिन है, और अच्छा performance पाना उससे भी कठिन
    • कई applications में code quality और performance गिरने का कारण

रूपकात्मक आलोचना

  • What Is React.js?

    • समर्थकों की विचित्रता, अतिरंजित गंभीरता, और अंतहीन documentation की ईसाई धर्म से तुलना करने वाला वीडियो

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

3 टिप्पणियां

 
bichi 10 분 전

React बस एक आस्था है (पाखंड).
 
bichi 8 분 전

Ant Mill जैसी चीज़ है //
 
GN⁺ 4 시간 전
Hacker News की राय

  • React में कुछ बातें पसंद नहीं हैं। React स्क्रीन पर interactive HTML रेंडर करने का framework है, बहुत जटिल programming करने के लिए नहीं
    पहली बात, यह बहुत ज़्यादा जटिल concepts और terminology पर निर्भर करता है। Vue से तुलना करें तो useEffect का मतलब watch है, और useMemo का computed
    दूसरी बात, यह बेवजह का “smart” तरीका terminology से आगे बढ़कर ecosystem में भी घुस गया। पहले Redux में सिर्फ एक संख्या बढ़ाने के लिए भी कई files में बहुत सारा code लिखना पड़ता था, और लगता था कि इसके लेखक को चालाक computer science concepts पसंद थे। उसी समय VueX में बस उस संख्या को बढ़ा देना काफी था। शुक्र है कि आजकल React ecosystem में कई समझदार state managers हैं
    तीसरी बात, React CSS tooling बिल्ट-इन नहीं देता
    चौथी बात, React optimization अपने आप नहीं करता। useEffect और useMemo को कब और कैसे इस्तेमाल करना है या नहीं करना है, यह जानना पड़ता है, और React optimization को लेकर बहुत-सी लोककथाएँ भी हैं। समस्या यह है कि re-rendering इसका मुख्य उद्देश्य होने के बावजूद ऐसा है। Vue में framework आपको अपने tools इस्तेमाल करने देता है और उसी दायरे में ज़्यादातर optimization कर देता है, इसलिए मुझे कभी नहीं लगा कि Vue app को manually optimize करना पड़ेगा
    पाँचवीं बात, वही लोककथाएँ खुद एक समस्या हैं। React API और “React सही तरीके से कैसे लिखें” यह बात बहुत बार बड़े स्तर पर बदली है, इसलिए आज भी यह समझना बहुत मुश्किल है कि कौन-सी बात सही है और कौन-सी नहीं
    आख़िर में React का सार यह है कि वह ideas, computer science, और high-level abstractions पर ज़रूरत से ज़्यादा केंद्रित है, और स्क्रीन पर interactive HTML आसानी से रेंडर कराने पर कम
    मैं React, Vue, और Svelte तीनों का खूब इस्तेमाल करता हूँ, लेकिन React के साथ मुझे लगातार उन चीज़ों की चिंता करनी पड़ती है जिन्हें Vue या Svelte पहले ही संभाल चुके होते। performance के मामले में तीनों लगभग समान हैं
    मैंने पहले इस बारे में एक लेख भी लिखा था: https://www.brachkow.com/notes/what-i-like-in-vue/

  • पिछले लगभग 16 सालों में JavaScript की लगभग हर मुख्य धारा देख चुकने के नज़रिए से, एक अर्थ में मुझे React पसंद है
    React उन सभी चीज़ों को छोड़ दें जिन्हें हमने आज़माया, तो सबसे खराब JavaScript framework है
    Angular 1 के दौर से तुलना करूँ तो मैं कभी भी React चुनूँगा। Backbone की तरह हर बार सब कुछ शुरू से जोड़ने की बजाय Angular 1 का भारी-भरकम MVC बेहतर था, और पुराने JQuery soup structure की तुलना में Backbone का न्यूनतम MVC ढाँचा बेहतर था। उस दौर में native API की बजाय मैं तुरंत JQuery का DOM manipulation और standard library enhancement चुनता
    React में भी trade-offs हैं, लेकिन हम यहाँ तक उन अनगिनत विकल्पों से गुज़रकर पहुँचे हैं जो काम नहीं करते थे

    • मुझे React इस्तेमाल करना पसंद है, और पहले आई चीज़ों की तुलना में मैं React चुनूँगा। लेकिन अगर ज़रूरत बस इतनी ही हो, तो मैं htmx/data-star और server rendering की बजाय React नहीं चुनूँगा, और कुछ थोड़े ज़्यादा जटिल pages होने पर भी नहीं
    • लेकिन Vue की बजाय React क्यों, यह समझ नहीं आता। सबसे बड़ी निराशा यह थी कि Vue आख़िरकार React की दिशा में बढ़ता दिखता है। Vue की मूल component structure, यानी HTML template, JavaScript state, और CSS styles का साथ होना, वाकई बहुत अच्छा था। Component के अंदर URL से data लाना भी बहुत सहज था
    • सहमत हूँ। हाथ से लिखे cgi-bin HTML से JQuery, Angular v1, और फिर React तक आया हूँ, और React ऐसा tool है जिसे मैं खुशी से उठाऊँगा। यह मेरा काम कर देता है
    • Angular से React बेहतर है, और React से Vue बेहतर है
    • जानना चाहूँगा कि क्या आपने Svelte इस्तेमाल किया है। समझ नहीं आता कि कोई React को ज़्यादा क्यों पसंद करेगा। मेरे हिसाब से React का एकमात्र फ़ायदा यह है कि frontend में यह IBM जैसा है। React चुनने पर किसी को नौकरी से नहीं निकाला जाता

  • बिल्कुल, React पसंद करने वाले लोग हैं। यह JavaScript की तरह कोई ऐसी चीज़ नहीं है जिसे लगभग मजबूरी में इस्तेमाल करना पड़े, और न ही React या किसी दूसरे web framework को सब पर थोपा जाता है, फिर भी React जीत गया। कम से कम इसे इस बात के सबूत के रूप में देखा जा सकता है कि लोग इसे ज़्यादातर दूसरे frameworks से काफ़ी बेहतर मानते हैं
    2010 के दशक के आख़िरी वर्षों तक web development को लेकर आम शिकायत यह थी कि चीज़ें बहुत तेज़ी से बदलती हैं और लगातार नया सीखना पड़ता है, और यह शिकायत जायज़ थी। लेकिन जैसे ही React monoculture शीर्ष पर पहुँचा, अब लोग उसी से नफ़रत की शिकायत कर रहे हैं। सच में, किसी को खुश नहीं किया जा सकता

    • नौकरी में मुझे frameworks और libraries चुनने का मौका लगभग कभी नहीं मिला। लगभग हमेशा या तो किसी और का कई साल पहले शुरू किया गया काम आगे बढ़ाना पड़ा, या ऐसी संस्था में रहा जहाँ विकल्प बहुत सीमित थे। निजी तौर पर मैं React नहीं चुनूँगा
      React इसलिए जीता क्योंकि वह default choice बन गया, और लोग वही पसंद करते हैं जिसके वे अभ्यस्त हो जाते हैं
    • React में फ़ायदे हैं, लेकिन इसे अक्सर inertia की वजह से चुना जाता है, न कि इसलिए कि वह उस काम के लिए सबसे अच्छा tool है। “सब React इस्तेमाल करते हैं, इसलिए hiring pool और contractor pool को अधिकतम किया जा सकता है”, “React project resume पर अच्छा दिखता है” जैसी वजहें काम करती हैं
    • उल्टा कई बार React और Next.js इस्तेमाल करने के लिए मजबूर होना पड़ता है। बहुत-से SaaS vendors ने Vercel के साथ साझेदारी की है और extension points सिर्फ उसी दिशा में खोल रखे हैं
      अगर कुछ और इस्तेमाल करना हो, तो integration खुद बनाना पड़ता है, या कोई पहले से बना open source project ढूँढना पड़ता है, या AI से पूछना पड़ता है
      hobby projects में यह संभव है, लेकिन कामकाजी माहौल में इसकी कल्पना करना कठिन है
    • मुझे समझ नहीं आता कि “किसी को React इस्तेमाल करने के लिए मजबूर नहीं किया जाता” का मतलब क्या है। वह कौन-सी शानदार नई दुनिया है जहाँ आप Lisp सीखकर उसे हर मनचाही चीज़ में इस्तेमाल कर सकते हैं, और corporate culture का technology choice पर कोई असर नहीं पड़ता?

  • मुझे React पसंद है। मैंने HTMX/Hotwire वाले तरीके भी गंभीरता से इस्तेमाल करके देखे हैं
    मैं एक ऐसा back button बनाना चाहता था जो, अगर यूज़र inbox से आया हो तो browser API से पीछे जाए, और नहीं तो scroll position बचाने के लिए inbox लिंक पर भेज दे। इसके लिए HTML में behavior वायर करके back function कॉल करना पड़ता, फिर controller में पिछला पेज क्या था यह तय करना पड़ता, और उसके बाद JavaScript-enabled back button या hard link देना पड़ता। लॉजिक 3 फ़ाइलों में बिखर गया था
    React में component के अंदर का JavaScript यह तय कर सकता है कि पिछला पेज inbox था या नहीं, और उसी के अनुसार back button JSX या link दिखा सकता है। सब कुछ एक ही फ़ाइल में खत्म हो जाता है। मेरे लिए बस एक conceptual entity को model करना होता है, लेकिन दूसरे तरीके में functionality को ज़बरदस्ती 3 अलग entities में ठूँसना पड़ता था
    क्या यह ज़्यादा धीमा है? हाँ, निश्चित रूप से। फिर भी यह मुझे खुश रखता है। अगर आप अपनी कंपनी के गंदे React codebase में परेशान हैं, तो दोष अपने सहकर्मियों को दीजिए। React न होता तो यह निश्चित ही और बुरा होता

    • इसी वजह से मुझे React single-page apps पसंद नहीं हैं। लगता है ये हमेशा browser के back button और navigation buttons तोड़ने का कोई न कोई बेवकूफ़ी भरा तरीका ढूँढ़ लेते हैं
      कभी-कभार form enhancement जैसी चीज़ों को छोड़ दें, तो मैं हमेशा htmx/server rendering और native behavior को ही पसंद करूँगा
    • मेरे हिसाब से HTMX को सिर्फ data state से जुड़े कामों के लिए इस्तेमाल करना बेहतर है। intelligent back button जैसी चीज़ें, जो resource state पर निर्भर नहीं हैं, उन्हें backend में calculate नहीं करना चाहिए
      recommended htmx तरीके में आप onclick button को inline JavaScript से जोड़ सकते हैं, या अगर वह पसंद न हो तो goBackOrInbox जैसा function कॉल कर सकते हैं
      function goBackOrInbox() { if (document.referrer) { const path = new URL(document.referrer).pathname; if (path.startsWith('/inbox')) { history.back(); return; } } window.location.href = '/inbox'; }
      अगर आप यह pattern बहुत इस्तेमाल करते हैं, तो जिस path पर जाना है उसे argument बनाकर parameterize कर सकते हैं
    • मुझे लगता है back button की समस्या सुलझाने का सबसे अच्छा तरीका यह है कि चीज़ों को ज़रूरत से ज़्यादा जटिल न बनाया जाए, और यह सुनिश्चित किया जाए कि केवल वही चीज़ें browser history में जाएँ जिन पर आप सच में वापस जाना चाहते हैं। पूरा problem statement जैसे चिल्लाकर कह रहा है, “अगर structure बेहतर हो तो यह ऐसी समस्या है जिसे सुलझाने की ज़रूरत ही नहीं पड़ेगी”
    • इधर-उधर कुछ जटिल हिस्से ज़रूर होंगे, लेकिन क्या यह Web Components से भी नहीं किया जा सकता?

  • मैं लंबे समय तक React code लिखता रहा हूँ, और अब कंपनी में एक बड़े Vue project पर काम कर रहा हूँ। पहले सब कहते थे कि Vue दोनों में ज़्यादा आसान और approachable विकल्प है, लेकिन अब मुझे बात अलग लगने लगी है
    React की खूबी यह है कि component मूल रूप से सिर्फ functions होते हैं, और उसके बाहर बहुत कुछ नहीं है। Next.js ecosystem को अभी अलग रख दें, तो यह frontend development में देखी गई सबसे elegant चीज़ों में से एक है
    दूसरी तरफ Vue थोड़ा मिला-जुला सा लगता है। ऐसा महसूस होता है जैसे backend developers, जो JavaScript ठीक से सीखना नहीं चाहते थे, उन्होंने इसे अपनाया और सराहा, और नतीजा एक ऐसा अजीब मिश्रण है जो साफ़-सुथरे ढंग से फिट नहीं बैठता

    • यह राय मुझे कभी समझ नहीं आई। React components सिर्फ functions नहीं हैं, बल्कि functions हैं जिनसे जादू की तरह inject किया गया context hooks के ज़रिए access होता है। ये hooks हर तरह की guarantees माँगते हैं, और अगर आप उनका ध्यान न रखें तो ऐसे नतीजे मिलते हैं जिन्हें debug करना मुश्किल हो जाता है। मुझे यह elegance से काफ़ी दूर लगता है
      मैंने सभी बड़े frameworks इस्तेमाल किए हैं, और इस समय एक बड़ा Angular web app बना रहा हूँ। Angular में components को class, template और styles के रूप में व्यक्त किया जाता है। Event listeners ज़्यादातर class के methods को कॉल करते हैं, और state class properties जितनी सीधी-सादी हो सकती है। यह कहीं ज़्यादा natural लगता है और इसमें traps भी काफ़ी कम हैं। हाँ, बिल्कुल शून्य नहीं
    • जानना चाहूँगा कि आपने Vue कितने समय तक इस्तेमाल किया है। कुछ साल पहले React background से Vue को देखते समय मेरे मन में भी ऐसी ही बातें आती थीं। लेकिन अब मैं React से ज़्यादा Vue को पसंद करता हूँ, और personal projects तथा work projects दोनों में Vue को पहले चुनता हूँ
      इसका feel थोड़ा अलग है। कुछ काम React में आसान हैं और कुछ Vue में, लेकिन Vue का signals इस्तेमाल करना मेरे लिए बहुत बड़ा plus point है

  • React से ज़्यादा, आम तौर पर कोड में UI लिखने का सबसे अच्छा तरीका क्या है, इसमें मेरी दिलचस्पी ज़्यादा है
    मैं React का फ़ैन हूँ और लगभग हर web application में React इस्तेमाल करता हूँ, लेकिन सबसे बड़ी और साफ़ समस्या यह है कि React में UI लिखना उतना स्वाभाविक नहीं लगता जितना Go में command-line tool लिखना या Elixir में real-time app बनाना लगता है
    कुछ भाषाएँ खास तरह के कामों के लिए हैरान करने वाली हद तक स्वाभाविक और frictionless होती हैं। लेकिन UI को अभी तक किसी ने सच में पूरी तरह नहीं साधा है। Swift, JSX/HTML, Svelte, या उस तरह के कोई भी लोकप्रिय framework, सभी किसी न किसी हद तक समस्या को बस sidestep करते हुए लगते हैं। ऐसा महसूस होता है कि language/framework designer ने किसी बिंदु पर requirements पूरी करने के लिए कोई गंदी, अजीब, या तकलीफ़देह syntax compromise के तौर पर जोड़ दी हो
    UI का स्वाभाविक interface visual होता है, इसलिए Figma जैसे tools समाधान का एक अहम हिस्सा हो सकते हैं। फिर भी लगता है कि कुछ न कुछ अभी भी गायब है। visual चीज़ों को code में व्यक्त करने का कोई और ज़्यादा सहज तरीका होना चाहिए। मौजूदा समाधान ठीक-ठीक क्यों कम पड़ते हैं, यह बताना मुश्किल है, लेकिन वे हमेशा कहीं न कहीं थोड़ा अधूरे लगते हैं

    • मेरा भी लगभग यही महसूस होता है। जब React आया था, तब उस समय के alternatives की तुलना में यह लगभग परफ़ेक्ट लगा था, इसलिए मुझे यह सच में बहुत पसंद आया
      आज भी Svelte, Vue, Solid समेत लगभग हर चीज़ से मैं React को ज़्यादा पसंद करता हूँ। लेकिन हाल में मैंने Crank(https://crank.js.org/) इस्तेमाल करना शुरू किया है, और यह उस दिशा के एक क़दम और करीब लगता है जहाँ मैं जाना चाहता हूँ। हालांकि अभी तक मैंने इसे सिर्फ toy projects में ही इस्तेमाल किया है, इसलिए performance और developer experience दोनों के लिहाज़ से यह कितना अच्छी तरह scale करेगा, कहना मुश्किल है
    • मैं इस बात से मज़बूती से सहमत हूँ कि “कुछ भाषाएँ खास कामों के लिए आश्चर्यजनक रूप से स्वाभाविक और frictionless होती हैं, लेकिन UI को अभी तक किसी ने पूरी तरह नहीं साधा है।” 90 के शुरुआती दशक में इस समस्या पर लिखी गई किताबें[1] आज भी उतनी ही लागू होती हैं
      अब तक जो सबसे अच्छा analysis मैंने देखा है, वह Chatty का “Programs = Data + Algorithms + Architecture: consequences for interactive software engineering”[2] है। पढ़ने में थोड़ा कठिन है, लेकिन पूरी तरह पढ़ने लायक है
      संक्षेप में कहूँ तो समस्या architecture की है, और ज़्यादा सटीक रूप से भाषा और architecture के mismatch की है। “general-purpose” programming language जिस call/return architecture style को बढ़ावा देती है, वह user interface के लिए ज़रूरी architecture से मेल नहीं खाती, बल्कि उससे टकराती है
      मैंने इसी विषय पर “Can Programmers Escape the Gentle Tyranny of call/return?” में भी लिखा है
      मौजूदा approach यह है कि पहले Objective-Smalltalk[4] जैसी programming language बनाई जाए, जिसमें alternative architecture styles को आसानी से व्यक्त किया जा सके
      उसी से मैं अभी interscript नाम का UI framework बना रहा हूँ, जिसमें HTMXNative और कई अतिरिक्त हिस्से भी शामिल हैं
      लगता है कि यह काफ़ी अच्छी तरह काम कर रहा है
      [1] उदाहरण: Myers आदि की “Languages for developing user interfaces” https://api.taylorfrancis.com/content/books/mono/download?id...
      [2] https://opendl.ifip-tc6.org/db/conf/ehci/ehci2007/Chatty07.p...
      [3] https://2020.programming-conference.org/details/salon-2020-p...
      [4] https://objective.st
    • एक engineer के तौर पर हर समस्या को देखकर यह सोचना आसान है कि “इसका कोई परफ़ेक्ट समाधान है, बस हमने अभी तक उसे खोजा नहीं है”
      लेकिन समय के साथ मैं कम idealistic जवाब स्वीकार करने लगा हूँ। शायद ऐसा समाधान है ही नहीं। समस्या का दायरा इतना जटिल हो सकता है कि उसके हर रूप को समेटने वाला कोई मानवीय रूप से संभव general solution अस्तित्व में ही न हो। अगर कोई एक क्षेत्र है जहाँ यह बात सही हो सकती है, तो वह शायद UI ही है

  • सही बात है। React declarative और imperative styles को सफलतापूर्वक मिलाने वाला, अब तक का सबसे सहज interface है। सभी भाषाओं के UI frameworks में JSX के क़रीब कुछ भी नहीं है, ऐसा मुझे लगता है

    • Flutter, SwiftUI, Jetpack Compose और कई दूसरे platforms ने React को अपने-अपने UI framework की तरह लागू किया है
    • अगर यह इतना सहज है, तो फिर समझ नहीं आता कि लगभग हर React app में performance bugs क्यों होते हैं

  • मुझे Svelte सच में बहुत पसंद है, और ज़्यादा जटिल apps के लिए मैं SvelteKit इस्तेमाल कर रहा हूँ
    जिन कई मामलों में पहले मैं React इस्तेमाल करता, वहाँ यह मुझे काफ़ी बेहतर सुधार लगा
    Svelte उन लोगों के लिए काफ़ी आसान लगता है जो web development, HTML, CSS, JavaScript की बुनियाद जानते हैं। लेकिन आजकल अक्सर ऐसे लोग दिखते हैं जो web development की शुरुआत ही React से करते हैं, और यह क्रम थोड़ा उल्टा लगता है
    निजी तौर पर मैं SvelteKit + Capacitor से mobile apps बना रहा हूँ, और setup मैंने यहाँ लिखा है: https://bryanhogan.com/blog/web-to-app-sveltekit-capacitor
    साधारण landing pages के लिए मैं Astro को पसंद करता हूँ

    • मैं भी हमेशा पहले Svelte + SvelteKit की ओर जाता हूँ। साधारण apps के लिए Kit ज़रूरत से ज़्यादा हो सकता है, लेकिन अगर चीज़ें अनपेक्षित रूप से जटिल हो जाएँ तो इसका होना अच्छा है
      मैं इस बात से सहमत हूँ कि आजकल लोगों का React से web development शुरू करना थोड़ा उल्टा लगता है। Svelte HTML को मातृभाषा की तरह बरतता है, इसलिए यह इस समस्या को काफ़ी अच्छी तरह रोकता है। अगर कोई Svelte(Kit) से web development शुरू करे, तो React से शुरू करने की तुलना में उसके fundamentals ज़्यादा सीखने की संभावना है
    • मेरे लिए Svelte + Astro का संयोजन सही बैठता है। यह documentation sites और उन pages के लिए बहुत अच्छा है जहाँ वैकल्पिक रूप से interactivity जोड़नी हो

  • मैं उन लोगों में से कुछ में था जिन्होंने React को संभव बनाया, इसलिए मेरा पक्षपात होना स्वाभाविक है, लेकिन मुझे React सच में बहुत पसंद है। उससे पहले frontend में आने वाली समस्याओं को ठीक करने के लिए मैं हर तरह की चीज़ें आज़मा रहा था। लेकिन React आने के बाद वह ज़रूरत ख़त्म हो गई, और मैं बस चीज़ें बनाने पर ध्यान दे सका

  • जिन प्रस्तुतियों को मैंने सच में बहुत अच्छा पाया, उनमें से एक यह है https://www.youtube.com/watch?v=h9SDuTSy7ps। मेरे अनुभव में React की architecture वाकई बहुत अच्छी है, और बड़े applications बनाने के लिए काफ़ी अच्छी तरह फिट बैठती है
    दुर्भाग्य से React की सबसे बड़ी समस्या यह है कि यह आपको JS/TS ecosystem में जाने के लिए मजबूर करता है। मेरे लिए JavaScript/TypeScript निःसंदेह ऐसा सिस्टम नहीं है जिसे मैं सीधे संभालना चाहूँ, बल्कि यह compile target के ज़्यादा क़रीब है
    मैं Elm से संतुष्ट हूँ। community बहुत छोटी है, और कभी-कभी libraries खुद बनानी पड़ती हैं। TEA, React से आने वाले व्यक्ति के लिए, कभी-कभी थोड़ा अस्वाभाविक लगता है, लेकिन useEffect जैसी implicit और अप्रत्याशित state की चिंता न करनी पड़े, इस वजह से Elm में काम करते समय मैं हमेशा उत्साहित रहता हूँ
    और Claude भी, कम-से-कम बड़े और डरावने codebase के भीतर, React की तुलना में Elm में ज़्यादा बेहतर टिकता हुआ लगता है

    • मेरे अनुभव में Elm लगभग मर चुका है। बेहतर होगा कि React और TypeScript इस्तेमाल करें, जिनके लिए libraries हैं जो लगातार काम करती रहती हैं। TypeScript को native रूप से compile करने योग्य बनाने की कोशिशें भी हुई थीं
    • मुझे TEA पसंद है, लेकिन reusable components या काफ़ी complex pages वाले apps में यह कैसे scale करता है, यह मैं पूरी तरह नहीं समझ पाया। यह संभालने का कोई सर्वमान्य तरीका है या नहीं, यह जानने की जिज्ञासा है
      state एक बड़े taboo जैसी लगती है, इसलिए थोड़ा टकराव भी महसूस होता है। यह भी जानना चाहता हूँ कि क्या आख़िरकार हर Elm app बिना effects वाला global Redux + React app बन जाता है। Elm में क्या मज़ेदार है और आप किस तरह काम करते हैं, इसके बारे में और विस्तार से जानना चाहूँगा। links भी ठीक रहेंगे