5 ms·

What's wrong with React? It made it so much better to build apps vs. spaghetti jQuery. I still have nightmares about jeeping track of jQuery callbacks

by altern8 9mo ago

lopatin 9mo ago
The problem with React is that it solved frontend. So the options are to 1. Code React all day and be happy with it. 2. Come up with reasons why it's bad. There are many talented and intellectually curious people in the field which lean towards 2.
- gmac 9mo ago
  The problem with React IMHO is it’s so dominant and so annoyingly over-engineered for many problems. I use Mithril and find it much less fuss.
  - docmars 9mo ago
    When they started adding new hooks just to work around their own broken component/rendering lifecycle, I knew React was doomed to become a bloated mess. Nobody in their right mind is remembering to use `useDeferredValue` or `useEffectEvent` for their very niche uses. These are a direct result of React's poor component lifecycle design. Compare to Vue's granular lifecycle hooks which give you all the control you need without workarounds, and they're named in a way that make sense. [1] And don't get me started on React's sad excuse for global state management with Contexts. A performance nightmare full of entire tree rerenders on every state change, even if components aren't subscribing to that state. Want subscriptions? Gotta hand-roll everything or use a 3rd party state library which don't support initialization before your components render if your global state depends on other state/data in React-land. 1. https://vuejs.org/api/composition-api-lifecycle.html https://vuejs.org/api/composition-api-lifecycle.html
    - leptons 9mo ago
      I use Preact, in the old-school way, without any "use-whatever" that React introduced. I like it that way. It's simple, it's very easy, and I get things done quickly without over-thinking it.
    - Capricorn2481 9mo ago
      I'm all for people avoiding React if they want, but I do want to respond to some of this, as someone who has made a few React apps for work. > When they started adding new hooks just to work around their own broken component/rendering lifecycle, I knew React was doomed to become a bloated mess. Hooks didn't fundamentally change anything. They are ways to escape the render loop, which class components already had. > Nobody in their right mind is remembering to use `useDeferredValue` or `useEffectEvent` for their very niche uses. Maybe because you don't necessarily need to. But for what it's worth, I'm on old versions of React when these weren't things, and I've built entire SPAs out without them at work. But reading their docs, they seem fine? > And don't get me started on React's sad excuse for global state management with Contexts. A performance nightmare full of entire tree rerenders on every state change I think it's good to give context on what a rerender is. It's not the same as repainting the DOM, or even in the same order of magnitude of CPU cycles. Your entire site could rerender from a text input, but you're unlikely to notice it even with 10x CPU slowdown in Devtools, unless you put something expensive in the render cycle for no reason. Indeed, I've seen people do a fetch request every time a text input changes. Meanwhile, if I do the same slowdown on Apple Music which is made in Svelte, it practically crashes. But pretty much any other state management library will work the way you've described you want.
      - docmars 9mo ago
        My issue with React Context is you can only assign initial state through the `value` prop on the provider if you need that initial state to be derived from other hook state/data, which requires yet another wrapper component to pull those in. Even if you make a `createProvider` factory to initialize a `useMyContext` hook, it still requires what I mentioned above. Compare this to Vue's Pinia library where you can simply create a global (setup) hook that allows you to bring in other hooks and dependencies, and return the final, global state. Then when you use it, it points to a global instance instead of creating unique instances for each hook used. Example (React cannot do this, not without enormous boilerplate and TypeScript spaghetti -- good luck!): export const useMyStore = defineStore("myStore", () => { const numericState = ref(0); const computedState = computed(() => reactiveState.value * 2); const numberFromAnotherHook = useAnotherHook(); const { data, error, loading } = useFetch(...); const derivedAsyncState = computed(() => { return data.value + numericState.value + numberFromAnotherHook.value; }); return { numericState, computedState, numberFromAnotherHook, derivedAsyncState, } }); This is remarkably easy, and the best part is: I don't have to wrap my components with another <Context.Provider> component. I can... just use the hook! I sorely wish React offered a better way to wire up global or shared state like this. React doesn't even have a plugin system that would allow someone to port Pinia over to React. It's baffling. Every other 3rd party state management library has to use React Context to initialize store data based on other React-based state/data. Without Context, you must wait for a full render cycle and assign the state using `useEffect`, causing your components to flash or delay rendering before the store's ready.
- spartanatreyu 9mo ago
  It didn't solve frontend, it sold developers one lie (i.e. ui = f(state) ) and managers another (developers are interchangeable gears). Problems are only truly solved by the folks who dedicate themselves to understanding the problem, that is: the folks working on web standards and the other folks implementing them.
  - kulahan 9mo ago
    Too bad the problems getting solved aren't the problems that need solving. Maybe this is one of the reasons software development is such a joke of a profession.
  - insin 9mo ago
    > Problems are only truly solved by the folks who dedicate themselves to understanding the problem, that is: the folks working on web standards and the other folks implementing them. It kills me to think of how amazing Web Components could be if those folks had started standardising them _now_ instead of in "competition" with userland component libraries of the time (while punting on many of the essential challenges of developing UI in the DOM those libraries were still evolving solutions for), and introduced more problems entirely of their own making.
bossyTeacher 9mo ago
It's overly verbose, unintuitive and in 2025, having a virtual dom is no longer compulsory to write interactive web apps. If you want to write modern web apps, you can use Svelte. If you want to write web apps truly functionally, you can use Elm. React is the jQuery of our times. It was really helpful in the Angular era but we are living at the dawn of a new era now.
- mehagar 9mo ago
  How is it overly verbose? I find it very intuitive, with the exception of useEffect.
  - spartanatreyu 9mo ago
    React's hello world: ```js <div id="root"></div> <script> import React from 'https://esm.sh/react@19 https://esm.sh/react@19'; import ReactDOM from 'https://esm.sh/react-dom@19/client https://esm.sh/react-dom@19/client'; const root = ReactDOM.createRoot(document.getElementById('root')); root.render(<h1>Hello, world!</h1>); </script> ``` --- HTML's hello world: ```html <h1>Hello, world!</h1> ``` --- JS's hello world: Nothing, it was already done in HTML
  - bossyTeacher 9mo ago
    React: import { useState } from "react"; function Counter() { const [count, setCount] = useState(0); return ( <button onClick={() => setCount(count + 1)}> Count: {count} </button> ); } ---------- Svelte: <script> let count = 0; </script> <button on:click={() => count += 1}> Count: {count} </button> --------------- React: function Editor({ initialText }) { const [text, setText] = useState(initialText); useEffect(() => { setText(initialText); }, [initialText]); return ( <textarea value={text} onChange={e => setText(e.target.value)} /> ); } --------------------- Svelte: <script> export let initialText; let text = initialText; $: text = initialText; </script> <textarea bind:value={text} />
    - DaanDL 9mo ago
      No one's going to mention VueJS?
epolanski 9mo ago
Complex APIs that require intimacy with internals with their gotchas. Complex rendering model and hard to tame lifecycle since they ditched the class component. Very hard to get performant websites (but you're free to link me what you've produced with React and prove me wrong). Also, biggest issue: severely misused for websites that are mostly static content and are nowhere near "app-like" nor have any particular reactivity need. 95%+ of react "applications" would've benefited from being written with a templating language instead. E.g. Github was miles better under all aspects when it used ruby but of course somebody had to sell to upper management their promotion case.
- tentacleuno 9mo ago
  In 2021, they published a post[0] about how they used web components, alongside a library called Calalyst. It seemed like quite a nice system. I've still seen include-fragment elements in the HTML, so I assume they still use it. [0]: https://github.blog/engineering/architecture-optimization/how-we-use-web-components-at-github/ https://github.blog/engineering/architecture-optimization/ho...

What's wrong with React? It made it so much better to build apps vs. spaghetti jQuery. I still have nightmares about jeeping track of jQuery callbacks

by altern8 9mo ago

What's wrong with React? It made it so much better to build apps vs. spaghetti jQuery. I still have nightmares about jeeping track of jQuery callbacks

lopatin 9mo ago

The problem with React is that it solved frontend. So the options are to 1. Code React all day and be happy with it. 2. Come up with reasons why it's bad. There are many talented and intellectually curious people in the field which lean towards 2.

gmac 9mo ago
The problem with React IMHO is it’s so dominant and so annoyingly over-engineered for many problems. I use Mithril and find it much less fuss.
- docmars 9mo ago
  When they started adding new hooks just to work around their own broken component/rendering lifecycle, I knew React was doomed to become a bloated mess. Nobody in their right mind is remembering to use `useDeferredValue` or `useEffectEvent` for their very niche uses. These are a direct result of React's poor component lifecycle design. Compare to Vue's granular lifecycle hooks which give you all the control you need without workarounds, and they're named in a way that make sense. [1] And don't get me started on React's sad excuse for global state management with Contexts. A performance nightmare full of entire tree rerenders on every state change, even if components aren't subscribing to that state. Want subscriptions? Gotta hand-roll everything or use a 3rd party state library which don't support initialization before your components render if your global state depends on other state/data in React-land. 1. https://vuejs.org/api/composition-api-lifecycle.html https://vuejs.org/api/composition-api-lifecycle.html
  - leptons 9mo ago
    I use Preact, in the old-school way, without any "use-whatever" that React introduced. I like it that way. It's simple, it's very easy, and I get things done quickly without over-thinking it.
  - Capricorn2481 9mo ago
    I'm all for people avoiding React if they want, but I do want to respond to some of this, as someone who has made a few React apps for work. > When they started adding new hooks just to work around their own broken component/rendering lifecycle, I knew React was doomed to become a bloated mess. Hooks didn't fundamentally change anything. They are ways to escape the render loop, which class components already had. > Nobody in their right mind is remembering to use `useDeferredValue` or `useEffectEvent` for their very niche uses. Maybe because you don't necessarily need to. But for what it's worth, I'm on old versions of React when these weren't things, and I've built entire SPAs out without them at work. But reading their docs, they seem fine? > And don't get me started on React's sad excuse for global state management with Contexts. A performance nightmare full of entire tree rerenders on every state change I think it's good to give context on what a rerender is. It's not the same as repainting the DOM, or even in the same order of magnitude of CPU cycles. Your entire site could rerender from a text input, but you're unlikely to notice it even with 10x CPU slowdown in Devtools, unless you put something expensive in the render cycle for no reason. Indeed, I've seen people do a fetch request every time a text input changes. Meanwhile, if I do the same slowdown on Apple Music which is made in Svelte, it practically crashes. But pretty much any other state management library will work the way you've described you want.
    - docmars 9mo ago
      My issue with React Context is you can only assign initial state through the `value` prop on the provider if you need that initial state to be derived from other hook state/data, which requires yet another wrapper component to pull those in. Even if you make a `createProvider` factory to initialize a `useMyContext` hook, it still requires what I mentioned above. Compare this to Vue's Pinia library where you can simply create a global (setup) hook that allows you to bring in other hooks and dependencies, and return the final, global state. Then when you use it, it points to a global instance instead of creating unique instances for each hook used. Example (React cannot do this, not without enormous boilerplate and TypeScript spaghetti -- good luck!): export const useMyStore = defineStore("myStore", () => { const numericState = ref(0); const computedState = computed(() => reactiveState.value * 2); const numberFromAnotherHook = useAnotherHook(); const { data, error, loading } = useFetch(...); const derivedAsyncState = computed(() => { return data.value + numericState.value + numberFromAnotherHook.value; }); return { numericState, computedState, numberFromAnotherHook, derivedAsyncState, } }); This is remarkably easy, and the best part is: I don't have to wrap my components with another <Context.Provider> component. I can... just use the hook! I sorely wish React offered a better way to wire up global or shared state like this. React doesn't even have a plugin system that would allow someone to port Pinia over to React. It's baffling. Every other 3rd party state management library has to use React Context to initialize store data based on other React-based state/data. Without Context, you must wait for a full render cycle and assign the state using `useEffect`, causing your components to flash or delay rendering before the store's ready.
spartanatreyu 9mo ago
It didn't solve frontend, it sold developers one lie (i.e. ui = f(state) ) and managers another (developers are interchangeable gears). Problems are only truly solved by the folks who dedicate themselves to understanding the problem, that is: the folks working on web standards and the other folks implementing them.
- kulahan 9mo ago
  Too bad the problems getting solved aren't the problems that need solving. Maybe this is one of the reasons software development is such a joke of a profession.
- insin 9mo ago
  > Problems are only truly solved by the folks who dedicate themselves to understanding the problem, that is: the folks working on web standards and the other folks implementing them. It kills me to think of how amazing Web Components could be if those folks had started standardising them _now_ instead of in "competition" with userland component libraries of the time (while punting on many of the essential challenges of developing UI in the DOM those libraries were still evolving solutions for), and introduced more problems entirely of their own making.

bossyTeacher 9mo ago

It's overly verbose, unintuitive and in 2025, having a virtual dom is no longer compulsory to write interactive web apps. If you want to write modern web apps, you can use Svelte. If you want to write web apps truly functionally, you can use Elm. React is the jQuery of our times. It was really helpful in the Angular era but we are living at the dawn of a new era now.

mehagar 9mo ago
How is it overly verbose? I find it very intuitive, with the exception of useEffect.
- spartanatreyu 9mo ago
  React's hello world: ```js <div id="root"></div> <script> import React from 'https://esm.sh/react@19 https://esm.sh/react@19'; import ReactDOM from 'https://esm.sh/react-dom@19/client https://esm.sh/react-dom@19/client'; const root = ReactDOM.createRoot(document.getElementById('root')); root.render(<h1>Hello, world!</h1>); </script> ``` --- HTML's hello world: ```html <h1>Hello, world!</h1> ``` --- JS's hello world: Nothing, it was already done in HTML
- bossyTeacher 9mo ago
  React: import { useState } from "react"; function Counter() { const [count, setCount] = useState(0); return ( <button onClick={() => setCount(count + 1)}> Count: {count} </button> ); } ---------- Svelte: <script> let count = 0; </script> <button on:click={() => count += 1}> Count: {count} </button> --------------- React: function Editor({ initialText }) { const [text, setText] = useState(initialText); useEffect(() => { setText(initialText); }, [initialText]); return ( <textarea value={text} onChange={e => setText(e.target.value)} /> ); } --------------------- Svelte: <script> export let initialText; let text = initialText; $: text = initialText; </script> <textarea bind:value={text} />
  - DaanDL 9mo ago
    No one's going to mention VueJS?

epolanski 9mo ago

Complex APIs that require intimacy with internals with their gotchas. Complex rendering model and hard to tame lifecycle since they ditched the class component. Very hard to get performant websites (but you're free to link me what you've produced with React and prove me wrong). Also, biggest issue: severely misused for websites that are mostly static content and are nowhere near "app-like" nor have any particular reactivity need. 95%+ of react "applications" would've benefited from being written with a templating language instead. E.g. Github was miles better under all aspects when it used ruby but of course somebody had to sell to upper management their promotion case.

tentacleuno 9mo ago
In 2021, they published a post[0] about how they used web components, alongside a library called Calalyst. It seemed like quite a nice system. I've still seen include-fragment elements in the HTML, so I assume they still use it. [0]: https://github.blog/engineering/architecture-optimization/how-we-use-web-components-at-github/ https://github.blog/engineering/architecture-optimization/ho...