7 ms·

I humbly disagree. I've never built a highly interactive application with React, only simple sites where the guys before me chose React, so I can't speak to its

I humbly disagree. I've never built a highly interactive application with React, only simple sites where the guys before me chose React, so I can't speak to its relative strengths or weaknesses there, but I've found that it doesn't scale down very well to simple sites. For a simple sign-in page, it's easy to just store state in the DOM and use a <form> element to send the credentials, and maybe a little JS for the password show/hide button. But to implement it in React you have to go on a steep learning curve to learn about JSX, hooks, the component lifecycle, building the app for dev, packaging it for prod, and more. Other frameworks, like Vue and Alpine, let you use them "progressively" and you can even do so with a CDN to avoid having to set up npm/vite from the get go. Their intro docs have instructions for how to do so, along with the relevant caveats React claims to be progressive, but since it's JSX it requires a compile step. Its intro docs do not have instructions for using it via CDN. You can make it work if you really want to, but it basically requires shipping the compiler to the client along with the JSX and doing the compilation client-side, which obviously scales so poorly that their docs don't cover it. To recap, my whole point is that React scales very poorly down to simple sites. And since most site are not Facebook or the Spotify web player or Netflix (and even Netflix is moving away from React: https://x.com/NetflixUIE/status/923374215041912833 https://x.com/NetflixUIE/status/923374215041912833), I think it's very hard to argue that React is effective or well designed.

auggierose 1y ago
Innovation is not really measured in terms of how well something "scales down".
- balamatom 1y ago
  Yes. Innovation used to measured in gigaquacks. A decade ago. With the process improvements of 2025, if it doesn't take you an innovation pool of at least 16 petaquacks to display a webpage, are you even trying? Anyone else up downscaling their innovation?
  - sixtyj 1y ago
    I love boring stack. No nodejs and its dependence hell, no compilation, no frameworks that need reading encyclopedia to make a simple form :) PHP or blazing fast PHP-fpm, MySQL/MariaDB or Postgres, json for config, jQuery… it is good enough for most cases. For Netflix, Spotify, Facebook, Waze, and other heavily used sites with millions users… it is a different game.
    - balamatom 1y ago
      Node.js is boring stack for me. But instead I am asked to work with tools from the wet nightmares of React developers. Stuff that runs in Node - yet is designed as if Node, the DOM, or the OS, didn't exist. Now that's never boring. They can't even consider that everything might work better without their favorite tool, than with it. It's surreal. And awful.
      - sixtyj 1y ago
        Some people seek innovation. :) Everytime I see some new editor, I know that people are really innovative because THIS will be THE ONE. /s
- KronisLV 1y ago
  See: multi MB downloads to display a few forms in a browser. Software that can’t work well with literal GBs of memory (some of it being a full browser runtime for some desktop forms). Games that run bad thanks to UE5 coming preloaded with footguns that ensure almost every developer will ship games that run poorly. Operating systems that run worse than a decade ago for even the parts that are functionally the same (e.g. a file explorer or start menu). I sure love the smell of Wirth’s law in the morning - smells like my PC melting.
  - Banou 1y ago
    React in itself isn't that heavy, and things like preact exists if you want an even lighter library, it's mostly other dependencies that are heavy, so the blame is mostly on the side of the devs, not react, for having heavy and clunky software.
    - tcfhgj 1y ago
      https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht... Select all angular, leptos, vue, solid and react variants -> react literally is consistently the slowest
      - Banou 1y ago
        Good thing that 99% websites don't need to modify 1k dom elements every seconds then, if you do using a DOM library isn't the right choice. My comment was about size library, in response to the parent comment about MBs of js. I'd gladly take a 10ms slower update on 1k rows(that practically never happens, ever heard of virtual lists?) for a maintainable codebase any day.
- actinium226 1y ago
  As a counter example, consider the jerry can from WWII. It was easy to handle a single unit to refill a vehicle, and it was also easy to stack millions of them for shipping. Another example is the internet itself. You can have a local LAN of a few computers or a global network of billions. So I'd say that to some degree innovation is measured by how well something can scale both up and down, but of course that's not always the case.
  - auggierose 1y ago
    Both of your examples show that scaling down is pointless if it doesn't scale up.
cpckx 1y ago
Netflix didn't move away from react. They render landing pages with static react components through server-side rendering and only add the minimal interactivity on top through client side js to avoid shipping all of react's state management etc. to the client.
- mike_hearn 1y ago
  That way of using it is so different to how you're supposed to use that it might as well not be React at all. It was designed as an in-browser framework and is poorly designed for server-side template rendering.
  - whoknowsidont 1y ago
    React has always done SSR first and then hydrated state on the client. What leads you to believe that this is not how you're supposed to use it? Doing pure SSR with React is simply... do not hyrdrate state on the client. Really really straightforward. This is such a vanilla setup and was kind of the big selling point to start with from the get-go? Why do you claim otherwise?
    - sbergot 1y ago
      This is factully wrong. You are confusing react with nextjs. React produce html documents, and the first usecase was reactdom, a pure client rendering library.
      - whoknowsidont 1y ago
        No. I'm speaking from experience having used React from its very first release. You're not only factually wrong about me being wrong, your knowledge is obviously quite limited. React has always initially rendering components on the server, then hydrated on the client. You don't have to take my word for it, download the initial release and try it out yourself: https://github.com/facebook/react/releases/tag/v0.4.0 https://github.com/facebook/react/releases/tag/v0.4.0 Go ahead, run that and write a simple app. Even better, want to do full SSR with no client lifecycle? Write an app that uses "React.renderComponentToString" and then describe what's happening for me. Even .NET had solutions around using React just for SSR: https://reactjs.net/features/server-side-rendering.html https://reactjs.net/features/server-side-rendering.html Claiming that react itself could not just render out a component server-side and spit out the HTML to the client requires several critical misconceptions about how software in general works lol.
beezlewax 1y ago
You can use React without jsx by the way. The syntax isn't great but it is doable.
- deleted 1y ago
  [deleted]
- actinium226 1y ago
  This seems like something that's technically true but not very practical: https://react.dev/reference/react/createElement#creating-an-element-without-jsx https://react.dev/reference/react/createElement#creating-an-... It still doesn't solve the problem of scaling down to simple things. I think this is better illustrated with this codepen I made a while ago to implement a reactive button in React, Vue, Alpine, and vanilla JS: https://codepen.io/nbelakovski/pen/jEOVbyP https://codepen.io/nbelakovski/pen/jEOVbyP I tried to implement the React part without JSX, but I couldn't figure out how to render the function component, and while I was able to render a class component based on the old docs, I couldn't figure out how to use useState with it. But going back to the codepen, the React and the vanillaJS both look messy, but I would take the vanillaJS over React if it means that I can sprinkle a little JS in my code without having to buy the whole farm that is create-react-app + npm + eslint + vite + all the React stuff I've mentioned.
cranberryturkey 1y ago
Look, just because you're the most popular doesn't mean you're the best, did you fools not learn anything from high school? Look at Microsoft in the 90s-2000s -- terrible fucking software, but it was by far the most widely used.
- LandR 1y ago
  Front end developers and not learning from mistakes of the past... I sense a theme here.
  - cranberryturkey 1y ago
    I don't know why I'm in the minority on hating on react any other big-tech "open" source frameworks.
kqr 1y ago
You certainly don't need JSX for React, nor a build chain. My ship investor Kelly trainer game[1] is a simple React application in a single HTML file. The initial page load is slow because I experimented with using built-in browser module support to pull in React, but if you change it to serve a pre-built library from a CDN instead then also the initial page load is fast. You can view the source on that page to see how simple it can be, but here is the essence: 1. Import React. This is the step you can do from a CDN instead of you want a faster initial page load. (Okay apparently I'm using Preact here, but it's effectively the same thing.) import { h, render, createContext } from 'https://unpkg.com/preact@latest?module'; import { useState, useMemo } from 'https://unpkg.com/preact@latest/hooks/dist/hooks.module.js?module'; 2. Render React components in HTML elements. This is where the progressiveness comes in. You don't have to render the entire web page as one React component; you can choose to only render some components in some locations of the page. const appDiv = document.getElementById('app'); render(h(App, null), appDiv); 3. The React components are plain ES functions that can use hooks etc. from React, as usual. function App() { let [state, setState] = useState(initial_state); // --------------->8------ return h('main', null, [ h(Description, { turn: state.turn, strait: state.straits[state.shipment.strait] }), h(Bankroll, { wealth: state.wealth.first() }), h(Investment, { invest, state }), h(WealthHistory, { wealth: state.wealth }), ]); } Instead of JSX we use the h function, which takes either tag name in a string, or another React component, takes an attribute dictionary as the second argument, and a list of children as the third. That's it. Super easy. [1]: https://xkqr.org/ship-investor/ship-investor.html https://xkqr.org/ship-investor/ship-investor.html (There is at least one bug in the game logic that prevents this game from being any fun at the moment. I have not taken the time to investigate why that happens, because I have not offered the training that used this tool to anyone in a few years.) ((If you enjoyed the game anyway and want more of a challenge, you might want to try the continuous version: https://xkqr.org/ship-investor/ship-investor-2.html https://xkqr.org/ship-investor/ship-investor-2.html. There is also a secret third version simulating futures which I have never shared with anyone before. It is playable, but not finished: https://xkqr.org/ship-investor/ship-investor-3.html https://xkqr.org/ship-investor/ship-investor-3.html))
- 1y ago
nrawe 1y ago
I think you hit the nail on the head: React is a good fit for certain solutions (like interactivity rich web applications), while not a good fit for others (like adding minor interactivity into a form). There are trade offs to React vs Vue vs Angular vs Vanilla and which is best is contextual to the problem you are solving, rather than a more moralistic "X is THE winner" stance.
whatevaa 1y ago
You shouldn't use any js framework for simple sites.
komali2 1y ago
> only simple sites where the guys before me chose React, so I can't speak to its relative strengths or weaknesses there, but I've found that it doesn't scale down very well to simple sites. I agree completely, my whole career I've been building webapps, as in like software that really couldn't be server side rendered, such as very interactive charting and table applications or games (that didn't require Canvas and could work in DOM but needed lots of reactivity, such as a SQL query builder game or a terminal emulator game), where react works decently. Vue worked fine and so did backbone/marionette, whatever, a framework is a framework is a framework, React has a lot of libraries I can just chuck in to get a date picker or whatever so I use it. Anyway, I would never build anything that can be server-rendered in react. Simple forms, e-commerce, blogs, portfolios, anything like that I'm just writing in HTML or Django or Hugo or hell, Wordpress. I tried out Astro for a blog just to pick up the framework and didn't understand why on earth I needed all this insane boilerplate to render Markdown files. Hugo solved that problem. If I need more complex than that, Vite + react, done. I feel like there's a lot of devs out there that are using react cause they like the devx "nice to haves" that they're used to e.g. hooks or whatever, when they really don't need them for their page.
- deleted 1y ago
  [deleted]
whoknowsidont 1y ago
>I think it's very hard to argue that React is effective or well designed. This is a foolish take. React is the reason the modern web is as usable as it is. Anyone who contests otherwise is simply ignorant of web development history. >(and even Netflix is moving away from React They're not moving away from React, they're doing pure SSR with it. https://react.dev/reference/react-dom/server/renderToPipeableStream https://react.dev/reference/react-dom/server/renderToPipeabl... You don't need the compiler client side. What level of confusion leads you to believe that? That's not even a detail about React, that's simply a mistake in how software works. React has ALWAYS, by default, done SSR first and then hydrates state on the client. It's trivial, and always has been, to simply do SSR only if you so wish. >But to implement it in React you have to go on a steep learning curve to learn about JSX, hooks, the component lifecycle, building the app for dev, packaging it for prod, and more. I find it hard to take this characterization in good faith. If you have trouble learning about the component life cycle in React, I don't see how you have any hope of successfully building a production level application without any guard rails. You will, without a singular doubt, simply get "it" wrong. Even with modern JS.
- burnerzzzzz 1y ago
  > This is a foolish take. React is the reason the modern web is as usable as it is Theres at least one foolish take here Come on think of the 100s of comparable FE frameworks…
  - whoknowsidont 1y ago
    All the other frameworks that take different solutions to achieve what react has done well and consistently since 2013? What are we comparing? What is there to compare?
- monooso 1y ago
  > Anyone who contests otherwise is simply ignorant of web development history. Or is perfectly aware of web development history and doesn't share your opinion.
  - 1y ago
hajile 1y ago
You are complaining about the libraries around it rather than react itself. function MyForm() { const [isHidden, setIsHidden] = useState(false) return ( <> <button onClick={()=>setIsHidden(!isHidden)}>{isHidden ? ‘Show’ : ‘Hide’}</button> {!isHidden &&<form>your same stuff</form>} </> ) } As you can see, you’ll be writing less code than you’d write if you were using something like jQuery. At the same time, if you’re needs grow due to something like client-side validation, you at least have an easy path forward. At it’s core, React isn’t very complex and you can build a lot of stuff without much complexity. The problem I often see is developers overengineering stuff. It’s not react specific and you’ll find this issue everywhere, but the form it takes in react land is adding massive solutions to little problems. I’ve worked on apps with giant routing solutions for a handful of routes or complicated stores with almost nothing in them. I suspect tech influencers and those of us writing actually large apps have an outsized voice if only because those devs keeping simple react projects simple just don’t have that much to write about.

auggierose 1y ago

Innovation is not really measured in terms of how well something "scales down".

balamatom 1y ago
Yes. Innovation used to measured in gigaquacks. A decade ago. With the process improvements of 2025, if it doesn't take you an innovation pool of at least 16 petaquacks to display a webpage, are you even trying? Anyone else up downscaling their innovation?
- sixtyj 1y ago
  I love boring stack. No nodejs and its dependence hell, no compilation, no frameworks that need reading encyclopedia to make a simple form :) PHP or blazing fast PHP-fpm, MySQL/MariaDB or Postgres, json for config, jQuery… it is good enough for most cases. For Netflix, Spotify, Facebook, Waze, and other heavily used sites with millions users… it is a different game.
  - balamatom 1y ago
    Node.js is boring stack for me. But instead I am asked to work with tools from the wet nightmares of React developers. Stuff that runs in Node - yet is designed as if Node, the DOM, or the OS, didn't exist. Now that's never boring. They can't even consider that everything might work better without their favorite tool, than with it. It's surreal. And awful.
    - sixtyj 1y ago
      Some people seek innovation. :) Everytime I see some new editor, I know that people are really innovative because THIS will be THE ONE. /s
KronisLV 1y ago
See: multi MB downloads to display a few forms in a browser. Software that can’t work well with literal GBs of memory (some of it being a full browser runtime for some desktop forms). Games that run bad thanks to UE5 coming preloaded with footguns that ensure almost every developer will ship games that run poorly. Operating systems that run worse than a decade ago for even the parts that are functionally the same (e.g. a file explorer or start menu). I sure love the smell of Wirth’s law in the morning - smells like my PC melting.
- Banou 1y ago
  React in itself isn't that heavy, and things like preact exists if you want an even lighter library, it's mostly other dependencies that are heavy, so the blame is mostly on the side of the devs, not react, for having heavy and clunky software.
  - tcfhgj 1y ago
    https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht... Select all angular, leptos, vue, solid and react variants -> react literally is consistently the slowest
    - Banou 1y ago
      Good thing that 99% websites don't need to modify 1k dom elements every seconds then, if you do using a DOM library isn't the right choice. My comment was about size library, in response to the parent comment about MBs of js. I'd gladly take a 10ms slower update on 1k rows(that practically never happens, ever heard of virtual lists?) for a maintainable codebase any day.
actinium226 1y ago
As a counter example, consider the jerry can from WWII. It was easy to handle a single unit to refill a vehicle, and it was also easy to stack millions of them for shipping. Another example is the internet itself. You can have a local LAN of a few computers or a global network of billions. So I'd say that to some degree innovation is measured by how well something can scale both up and down, but of course that's not always the case.
- auggierose 1y ago
  Both of your examples show that scaling down is pointless if it doesn't scale up.

cpckx 1y ago

Netflix didn't move away from react. They render landing pages with static react components through server-side rendering and only add the minimal interactivity on top through client side js to avoid shipping all of react's state management etc. to the client.

mike_hearn 1y ago
That way of using it is so different to how you're supposed to use that it might as well not be React at all. It was designed as an in-browser framework and is poorly designed for server-side template rendering.
- whoknowsidont 1y ago
  React has always done SSR first and then hydrated state on the client. What leads you to believe that this is not how you're supposed to use it? Doing pure SSR with React is simply... do not hyrdrate state on the client. Really really straightforward. This is such a vanilla setup and was kind of the big selling point to start with from the get-go? Why do you claim otherwise?
  - sbergot 1y ago
    This is factully wrong. You are confusing react with nextjs. React produce html documents, and the first usecase was reactdom, a pure client rendering library.
    - whoknowsidont 1y ago
      No. I'm speaking from experience having used React from its very first release. You're not only factually wrong about me being wrong, your knowledge is obviously quite limited. React has always initially rendering components on the server, then hydrated on the client. You don't have to take my word for it, download the initial release and try it out yourself: https://github.com/facebook/react/releases/tag/v0.4.0 https://github.com/facebook/react/releases/tag/v0.4.0 Go ahead, run that and write a simple app. Even better, want to do full SSR with no client lifecycle? Write an app that uses "React.renderComponentToString" and then describe what's happening for me. Even .NET had solutions around using React just for SSR: https://reactjs.net/features/server-side-rendering.html https://reactjs.net/features/server-side-rendering.html Claiming that react itself could not just render out a component server-side and spit out the HTML to the client requires several critical misconceptions about how software in general works lol.

beezlewax 1y ago

You can use React without jsx by the way. The syntax isn't great but it is doable.

deleted 1y ago
[deleted]
actinium226 1y ago
This seems like something that's technically true but not very practical: https://react.dev/reference/react/createElement#creating-an-element-without-jsx https://react.dev/reference/react/createElement#creating-an-... It still doesn't solve the problem of scaling down to simple things. I think this is better illustrated with this codepen I made a while ago to implement a reactive button in React, Vue, Alpine, and vanilla JS: https://codepen.io/nbelakovski/pen/jEOVbyP https://codepen.io/nbelakovski/pen/jEOVbyP I tried to implement the React part without JSX, but I couldn't figure out how to render the function component, and while I was able to render a class component based on the old docs, I couldn't figure out how to use useState with it. But going back to the codepen, the React and the vanillaJS both look messy, but I would take the vanillaJS over React if it means that I can sprinkle a little JS in my code without having to buy the whole farm that is create-react-app + npm + eslint + vite + all the React stuff I've mentioned.

cranberryturkey 1y ago

Look, just because you're the most popular doesn't mean you're the best, did you fools not learn anything from high school? Look at Microsoft in the 90s-2000s -- terrible fucking software, but it was by far the most widely used.

LandR 1y ago
Front end developers and not learning from mistakes of the past... I sense a theme here.
- cranberryturkey 1y ago
  I don't know why I'm in the minority on hating on react any other big-tech "open" source frameworks.

kqr 1y ago

You certainly don't need JSX for React, nor a build chain. My ship investor Kelly trainer game[1] is a simple React application in a single HTML file. The initial page load is slow because I experimented with using built-in browser module support to pull in React, but if you change it to serve a pre-built library from a CDN instead then also the initial page load is fast. You can view the source on that page to see how simple it can be, but here is the essence: 1. Import React. This is the step you can do from a CDN instead of you want a faster initial page load. (Okay apparently I'm using Preact here, but it's effectively the same thing.) import { h, render, createContext } from 'https://unpkg.com/preact@latest?module'; import { useState, useMemo } from 'https://unpkg.com/preact@latest/hooks/dist/hooks.module.js?module'; 2. Render React components in HTML elements. This is where the progressiveness comes in. You don't have to render the entire web page as one React component; you can choose to only render some components in some locations of the page. const appDiv = document.getElementById('app'); render(h(App, null), appDiv); 3. The React components are plain ES functions that can use hooks etc. from React, as usual. function App() { let [state, setState] = useState(initial_state); // --------------->8------ return h('main', null, [ h(Description, { turn: state.turn, strait: state.straits[state.shipment.strait] }), h(Bankroll, { wealth: state.wealth.first() }), h(Investment, { invest, state }), h(WealthHistory, { wealth: state.wealth }), ]); } Instead of JSX we use the h function, which takes either tag name in a string, or another React component, takes an attribute dictionary as the second argument, and a list of children as the third. That's it. Super easy. [1]: https://xkqr.org/ship-investor/ship-investor.html https://xkqr.org/ship-investor/ship-investor.html (There is at least one bug in the game logic that prevents this game from being any fun at the moment. I have not taken the time to investigate why that happens, because I have not offered the training that used this tool to anyone in a few years.) ((If you enjoyed the game anyway and want more of a challenge, you might want to try the continuous version: https://xkqr.org/ship-investor/ship-investor-2.html https://xkqr.org/ship-investor/ship-investor-2.html. There is also a secret third version simulating futures which I have never shared with anyone before. It is playable, but not finished: https://xkqr.org/ship-investor/ship-investor-3.html https://xkqr.org/ship-investor/ship-investor-3.html))

1y ago

nrawe 1y ago

I think you hit the nail on the head: React is a good fit for certain solutions (like interactivity rich web applications), while not a good fit for others (like adding minor interactivity into a form). There are trade offs to React vs Vue vs Angular vs Vanilla and which is best is contextual to the problem you are solving, rather than a more moralistic "X is THE winner" stance.

whatevaa 1y ago

You shouldn't use any js framework for simple sites.

komali2 1y ago

> only simple sites where the guys before me chose React, so I can't speak to its relative strengths or weaknesses there, but I've found that it doesn't scale down very well to simple sites. I agree completely, my whole career I've been building webapps, as in like software that really couldn't be server side rendered, such as very interactive charting and table applications or games (that didn't require Canvas and could work in DOM but needed lots of reactivity, such as a SQL query builder game or a terminal emulator game), where react works decently. Vue worked fine and so did backbone/marionette, whatever, a framework is a framework is a framework, React has a lot of libraries I can just chuck in to get a date picker or whatever so I use it. Anyway, I would never build anything that can be server-rendered in react. Simple forms, e-commerce, blogs, portfolios, anything like that I'm just writing in HTML or Django or Hugo or hell, Wordpress. I tried out Astro for a blog just to pick up the framework and didn't understand why on earth I needed all this insane boilerplate to render Markdown files. Hugo solved that problem. If I need more complex than that, Vite + react, done. I feel like there's a lot of devs out there that are using react cause they like the devx "nice to haves" that they're used to e.g. hooks or whatever, when they really don't need them for their page.

deleted 1y ago
[deleted]

whoknowsidont 1y ago

>I think it's very hard to argue that React is effective or well designed. This is a foolish take. React is the reason the modern web is as usable as it is. Anyone who contests otherwise is simply ignorant of web development history. >(and even Netflix is moving away from React They're not moving away from React, they're doing pure SSR with it. https://react.dev/reference/react-dom/server/renderToPipeableStream https://react.dev/reference/react-dom/server/renderToPipeabl... You don't need the compiler client side. What level of confusion leads you to believe that? That's not even a detail about React, that's simply a mistake in how software works. React has ALWAYS, by default, done SSR first and then hydrates state on the client. It's trivial, and always has been, to simply do SSR only if you so wish. >But to implement it in React you have to go on a steep learning curve to learn about JSX, hooks, the component lifecycle, building the app for dev, packaging it for prod, and more. I find it hard to take this characterization in good faith. If you have trouble learning about the component life cycle in React, I don't see how you have any hope of successfully building a production level application without any guard rails. You will, without a singular doubt, simply get "it" wrong. Even with modern JS.

burnerzzzzz 1y ago
> This is a foolish take. React is the reason the modern web is as usable as it is Theres at least one foolish take here Come on think of the 100s of comparable FE frameworks…
- whoknowsidont 1y ago
  All the other frameworks that take different solutions to achieve what react has done well and consistently since 2013? What are we comparing? What is there to compare?
monooso 1y ago
> Anyone who contests otherwise is simply ignorant of web development history. Or is perfectly aware of web development history and doesn't share your opinion.
- 1y ago

hajile 1y ago

You are complaining about the libraries around it rather than react itself. function MyForm() { const [isHidden, setIsHidden] = useState(false) return ( <> <button onClick={()=>setIsHidden(!isHidden)}>{isHidden ? ‘Show’ : ‘Hide’}</button> {!isHidden &&<form>your same stuff</form>} </> ) } As you can see, you’ll be writing less code than you’d write if you were using something like jQuery. At the same time, if you’re needs grow due to something like client-side validation, you at least have an easy path forward. At it’s core, React isn’t very complex and you can build a lot of stuff without much complexity. The problem I often see is developers overengineering stuff. It’s not react specific and you’ll find this issue everywhere, but the form it takes in react land is adding massive solutions to little problems. I’ve worked on apps with giant routing solutions for a handful of routes or complicated stores with almost nothing in them. I suspect tech influencers and those of us writing actually large apps have an outsized voice if only because those devs keeping simple react projects simple just don’t have that much to write about.