3 ms·

React made front end suck. Sorry.

onion2k 4mo ago
React definitely didn't make frontend _great_ in a lot of cases, but jQuery, mootools, prototype, knockout, ember, angular, and a whole lot more JS frameworks that have come and gone predate React. If React hadn't been invented there'd be just as many poorly developed browser apps as there are today. You can't really pin that on React.
- archerx 4mo ago
  What I can pin on react is that it is very inefficient with resources using much more cpu power than needed to render some text and images on a webpage. Imagine all the electricity that was wasted because of react and the negative impact on the environment it has had because of that.
  - onion2k 4mo ago
    React doesn't do anything unless the DOM needs to to be updated. Arguably React does have a 'disadvantage' in the sense that it doesn't do two-way data binding, and chooses to update as little of the DOM as necessary to render a change (which it's good at, and gets right), but that's sometimes more than just changing a text node or a value. I suspect that if React hadn't come along there'd be lots of homegrown frameworks doing something similar in a worse way. React is well thought-out and well designed. Also, every reactive framework can have the same problem. It's not a React thing; it's a library-that-tracks-changes-and-updates-the-DOM thing. Used poorly you'll end up in a re-render loop. We could just have static HTML pages and that would eliminate the whole problem, but then we'd be complaining about the electricity used on network roundtrips and people using badly coded desktop apps instead. Ultimately, libraries can be as bulletproof and fool-proof as you like, and developers will find new and novel ways to use them to build crap software. The responsibility (mostly) lies with the developers much more than the library.
    - archerx 4mo ago
      Yea, no, not at all. A lot of websites that use “modern” front end frame works cause high CPU usage. Getting data as need using an event based system is magnitudes faster and more efficient.
- digitaltrees 4mo ago
  Actually I can pin it on react directly. React was built by facebook to solve a single problem that most developers don’t have: their message count badge would be stale and out of date, their solution was to add global state, eliminate most of the browsers built in features, move away from multi page apps with http calls etc. so all kinds of things got harder like url routing, SEO, server side state management, etc. But most apps don’t need a persistent counter that updates without browser refresh. Further, there were other easy solutions like http request polling, or even websockets. They weren’t solutions for Facebook because they had to support lots of devices that couldn’t handle something like websockets. But instead of the industry realizing this was a specific tool for a specific niche case we just piled on to the design pattern and built a massive lock in ecosystem that may the web worse.
Vinnl 4mo ago
I think you might be forgetting how much it sucked before React.
- InsideOutSanta 4mo ago
  I vastly prefer plain JS over React, but I will admit that React probably was instrumental in helping create frontend frameworks that are actually good, like Svelte. So I will give Facebook credit for that.
  - DonHopkins 4mo ago
    Svelte is awesome. Svelte 5's runes are especially powerful because they let reactivity escape the component boundary. The same reactive model works everywhere, whether you're updating the DOM or building plain application logic. Rich Harris makes the point that React isn't actually reactive: "React doesn’t have any understanding of the values running through your app. It is not Reactive." Rich Harris - Rethinking reactivity: https://www.youtube.com/watch?v=AdNJ3fydeao https://www.youtube.com/watch?v=AdNJ3fydeao >Modern JavaScript frameworks are all about reactivity. Change your application's state, and the view updates automatically. But there's a catch — tracking state changes at runtime adds overhead that eats into your bundle size and performance budgets. In this talk, we'll discover an alternative approach: moving reactivity into the language itself. Your apps have never been smaller or faster than they're about to become. He starts with spreadsheets as the archetypal reactive system. Defines reactivity as values automatically updating according to dependency relationships. Contrasts that with React's model of rerunning component functions and diffing virtual DOM trees. Argues that React "doesn't understand the values flowing through your application" and therefore isn't reactive in the traditional sense. Virtual DOM is pure overhead: https://svelte.dev/blog/virtual-dom-is-pure-overhead https://svelte.dev/blog/virtual-dom-is-pure-overhead >But it turns out that we can achieve a similar programming model without using virtual DOM — and that's where Svelte comes in. React tracks component renders; reactive systems track data dependencies. React doesn't react, it repeats. I think React should have been called "Repeat", "Re-Run", "Regurgitate", or "Retch".
- digitaltrees 4mo ago
pseudocomposer 4mo ago
Part of me hopes that without React (poorly) filling the void, something like Elm could have gained traction. But ultimately I think it’s unlikely.
- lupire 4mo ago
  Avoiding traction was a major goal of Elm. The creator was committed to Elm being his personal jewel, not useful for others.

React definitely didn't make frontend _great_ in a lot of cases, but jQuery, mootools, prototype, knockout, ember, angular, and a whole lot more JS frameworks that have come and gone predate React. If React hadn't been invented there'd be just as many poorly developed browser apps as there are today. You can't really pin that on React.

archerx 4mo ago
What I can pin on react is that it is very inefficient with resources using much more cpu power than needed to render some text and images on a webpage. Imagine all the electricity that was wasted because of react and the negative impact on the environment it has had because of that.
- onion2k 4mo ago
  React doesn't do anything unless the DOM needs to to be updated. Arguably React does have a 'disadvantage' in the sense that it doesn't do two-way data binding, and chooses to update as little of the DOM as necessary to render a change (which it's good at, and gets right), but that's sometimes more than just changing a text node or a value. I suspect that if React hadn't come along there'd be lots of homegrown frameworks doing something similar in a worse way. React is well thought-out and well designed. Also, every reactive framework can have the same problem. It's not a React thing; it's a library-that-tracks-changes-and-updates-the-DOM thing. Used poorly you'll end up in a re-render loop. We could just have static HTML pages and that would eliminate the whole problem, but then we'd be complaining about the electricity used on network roundtrips and people using badly coded desktop apps instead. Ultimately, libraries can be as bulletproof and fool-proof as you like, and developers will find new and novel ways to use them to build crap software. The responsibility (mostly) lies with the developers much more than the library.
  - archerx 4mo ago
    Yea, no, not at all. A lot of websites that use “modern” front end frame works cause high CPU usage. Getting data as need using an event based system is magnitudes faster and more efficient.
digitaltrees 4mo ago
Actually I can pin it on react directly. React was built by facebook to solve a single problem that most developers don’t have: their message count badge would be stale and out of date, their solution was to add global state, eliminate most of the browsers built in features, move away from multi page apps with http calls etc. so all kinds of things got harder like url routing, SEO, server side state management, etc. But most apps don’t need a persistent counter that updates without browser refresh. Further, there were other easy solutions like http request polling, or even websockets. They weren’t solutions for Facebook because they had to support lots of devices that couldn’t handle something like websockets. But instead of the industry realizing this was a specific tool for a specific niche case we just piled on to the design pattern and built a massive lock in ecosystem that may the web worse.

Vinnl 4mo ago

I think you might be forgetting how much it sucked before React.

InsideOutSanta 4mo ago
I vastly prefer plain JS over React, but I will admit that React probably was instrumental in helping create frontend frameworks that are actually good, like Svelte. So I will give Facebook credit for that.
- DonHopkins 4mo ago
  Svelte is awesome. Svelte 5's runes are especially powerful because they let reactivity escape the component boundary. The same reactive model works everywhere, whether you're updating the DOM or building plain application logic. Rich Harris makes the point that React isn't actually reactive: "React doesn’t have any understanding of the values running through your app. It is not Reactive." Rich Harris - Rethinking reactivity: https://www.youtube.com/watch?v=AdNJ3fydeao https://www.youtube.com/watch?v=AdNJ3fydeao >Modern JavaScript frameworks are all about reactivity. Change your application's state, and the view updates automatically. But there's a catch — tracking state changes at runtime adds overhead that eats into your bundle size and performance budgets. In this talk, we'll discover an alternative approach: moving reactivity into the language itself. Your apps have never been smaller or faster than they're about to become. He starts with spreadsheets as the archetypal reactive system. Defines reactivity as values automatically updating according to dependency relationships. Contrasts that with React's model of rerunning component functions and diffing virtual DOM trees. Argues that React "doesn't understand the values flowing through your application" and therefore isn't reactive in the traditional sense. Virtual DOM is pure overhead: https://svelte.dev/blog/virtual-dom-is-pure-overhead https://svelte.dev/blog/virtual-dom-is-pure-overhead >But it turns out that we can achieve a similar programming model without using virtual DOM — and that's where Svelte comes in. React tracks component renders; reactive systems track data dependencies. React doesn't react, it repeats. I think React should have been called "Repeat", "Re-Run", "Regurgitate", or "Retch".
digitaltrees 4mo ago

pseudocomposer 4mo ago

Part of me hopes that without React (poorly) filling the void, something like Elm could have gained traction. But ultimately I think it’s unlikely.

lupire 4mo ago
Avoiding traction was a major goal of Elm. The creator was committed to Elm being his personal jewel, not useful for others.