4 ms·

Glad to see these ideas being shared more broadly. I've had enough of React. I lost my last job because of it and all associated technical debt. The company I w

Glad to see these ideas being shared more broadly. I've had enough of React. I lost my last job because of it and all associated technical debt. The company I worked for (a startup) turned into a kind of Darwinian Squid Game where those employees who were able to keep adding on top of the mess of tech debt at a fast rate were promoted and those who did not were let go. It became an absolute brainf**. Also, I had lost all motivation because there was no real engineering left to do; all the work was related to debugging React-specific gotchas/issues which I hate doing. React creates layer upon layer of unnecessary, opaque abstractions which make it harder to debug complex front ends and it encourages poor engineering practices. For example, I've seen a lot of cases of junior developers dump setInterval() calls all over the place into the code inside useEffect and not cleaning up afterwards... Causing memory leaks. But these devs can work so fast using React (to get features out in production quickly) that managers just love them and it's difficult to convey to them that this is in fact a short-term approach and it will come back to bite them in the long term. The app at that startup had such awful memory leaks that my new computer would freeze a few times a day. I feel like the new generation of devs got used to working with these abstractions and by some measures they seem highly competent, yet it feels like they're missing some critical knowledge; like they don't understand what's happening under the hood. Sad because there's actually a lot less happening under the hood than there is happening above it! You can solve many problems while staying closer to native browser features without all this complexity.

magic_hamster 3y ago
What will you recommend as an alternative?
hasanhaja 3y ago
+1 Have you been exploring any other technologies since React?
- deleted 3y ago
  [deleted]
- jongjong 3y ago
  For my newest project, I'm going for plain HTMLElement (Web Components) but if I find that I can't live without reactive data binding/rendering, I will probably use Lit https://lit.dev/ https://lit.dev/ So far it looks like I won't even need to go there... It turns out it's pretty easy to manage a web-component's dynamic state without reactivity (at least based on how I architect my apps). I find the HTMLElement lifecycle hooks (and attributeChangedCallback) to be sufficient.
DigitalSea 3y ago
A lot of the React fanatics are in denial about this. But, I've seen some absolute messes. Does anyone remember InVision? You probably have forgotten about them because Figma and other design tools ate their lunch, but part of their failure and delay in InVision Studio being released was in part because of React. I know other companies have encountered limitations with React and had to hack around them, most notably Atlassian who had to break their app up into apps (essentially parts of the app were smaller apps) because they wanted to use state management for everything and the memory problems were astronomical. React got popular because at the time, Angular.js was the framework of choice and we can all agree Angular had some serious problems like the digest cycle and performance issues working with large collections. React in comparison to Angular was a breath of fresh air, but in 2023 there are far better choices now than React. The thing is, React started out as just a view library and the community are mostly to blame for how terrible it has become. How many state management libraries have there been? How many router packages? Devs think they want a library, they actually want a framework. It's why the most popular uses of React are not vanilla React, they're frameworks like Next.js. Also, when you compare the performance of React to other libraries and frameworks, you realise it's one of the worse performing options. It's slow. The whole entire notion of Virtual DOM was groundbreaking in 2013, but in 2023, reactive binding approaches like those taken in Aurelia and Svelte are far superior and better performing. Virtual DOM is overhead. Has anyone ever seen a large-scale React project that is just using vanilla React? I've seen a few large-scale React codebases and many of them were a tangled spaghetti mess. It gets to a point where React's lack of opinions and standards for even the most basic of things mean you can see the same thing implemented 100 times in the React community. If you're building something beyond a landing page or basic CRUD app, you need some conventions. There is a reason despite the hate it gets, Angular is still used in enterprise and government settings. It's verbose, but you write components and other facets of your apps a specific way and know that Developer A implementing a feature is going to be understood by Developer B because it's not going to be so self-opinionated. This is something that backend frameworks learned years ago. Don't get me started on the terrible communication from the React team. A good example is how they have handled React Server Components. They changed the docs to recommend RSC's by default, despite the fact many community packages don't work with them or require additional packages. The way they approached RSC's and rushed them out was terrible. This isn't the first time either. I have been working with Aurelia 2 (https://docs.aurelia.io https://docs.aurelia.io) and I love it. It's intuitive, it's fast, the developer experience is great, it comes with all of the needed dependendencies you need like a router, validation, localisation and whatnot. No need to go building a faux-framework of Node packages bloating your app. I've also been working with Web Components, which are in a really good place now too and getting better with each proposal (there are a few good WC proposals in the works right now). Developers need to start using the platform more. Web Components have been supported by all browsers since 2020 (Chrome has supported them since 2013), so it's a good time to dive in. Using something like Lit gives you a nice development experience. Part of the problem is React developers have been brainwashed into thinking classes are bad because of some terrible design decisions in React (which led to Hooks) and writing Web Components relies on using class syntax (although, you can write them as functions if you really want to). React is anti-standards, it's anti-developer and it's bad for the platform. The fact that React is ten years old and doesn't support Web Components still, goes to show just how little the React team cares about Web Standards . I know jQuery is a bit of a meme now, but at least jQuery helped shape modern standards. Has anything good come from React for the platform?
5Qn8mNbc2FNCiVV 3y ago
I'm certain that this would have happened with any other framework mentioned as well and pointing towards React being the issue is just searching for a scapegoat where there is none
- Ambolia 3y ago
  The problem starts in html, css, javascript and the browser as a development platform. React tries to patch over those issues, and creates some new issues. People claim other frameworks solve the same issues without introducing any significant new problems. I'll remain skeptic until I see a couple of huge full-functionality apps in those frameworks that manage to keep a clean codebase and good performance. I've seen too many times people "solving" frontend development, most of the time that solution just amounts to documents linked to each other, and avoiding complex forms and interactivity, but if you just do linked documents, frontend development was solved in the 90s, and you don't need javascript at all.
threeseed 3y ago
You can say this about any technology though. Whenever you prioritise delivering features and are ambivalent about tech debt then of course the quality of the code base will suffer. There is nothing inherent to React that makes it significantly worse than the many other Javascript frameworks out there. At least it has the benefit of having ongoing support by a major vendor with a record of long term support for open source projects. That's not something that is all that common in the Javascript ecosystem.
- jokethrowaway 3y ago
  > There is nothing inherent to React that makes it significantly worse than the many other Javascript frameworks out there. There definitely are plenty of things which are an order of magnitude harder in react than any other framework. One flow data is an example, having to install deps for everything from state management to css is another. All the choices compounds and make complicated projects even more complicated, increasing tech debt. Don't get me wrong: Angular (and for sure other frameworks I can't think of) had the same problem; many other frameworks do not. These days I'm very happily developing against Solid Start with not a single issue I can't think of and a syntax which is very close to React.
- mrd3v0 3y ago
  "There is nothing inherent to React that makes it significantly worse than the many other Javascript frameworks out there." That is exactly the kind of conclusions that come from not understanding what runs under the hood.
locallost 3y ago
I agree with most of it, but I still had to chuckle at the "don't understand what's happening under the hood" part. The browser and JavaScript are themselves very high level, so it's funny how e.g. not using React would make you understand more what's going on under the hood. It's a pretty deep hood.
deleted 3y ago
[deleted]
5350-uiop-1130 3y ago
i think the popularity of react (and node) comes down greed. do more with less. a tumorous outgrowth of the "move fast and break things" attitude of early FB development and cargo culture of the tech boom eras. you can have one dev write the front end and most of the server side code too. not only that but they have to handle much of the tooling, testing and debugging. and the learn2code push also was designed to saturate the market with lots of these devs. many of whom lack the background knowledge to understand what they're doing. i seen this job expand through the years from a smaller set of responsibilities to a much larger one where most of your work is only indirectly (and irritatingly) related to what you're actually trying to do.
deleted 3y ago
[deleted]
rewmie 3y ago
> I feel like the new generation of devs got used to working with these abstractions and by some measures they seem highly competent, yet it feels like they're missing some critical knowledge; like they don't understand what's happening under the hood. Is this remotely relevant, though? I don't think it is. The whole point of working with higher level abstractions is to not have to care about the lower level bits. We all know that things are not as optimized as they could theoretically be, and that's ok. People are paid to deliver value, and microoptimizing stuff just wastes everyone's time.
- jongjong 3y ago
  It's fine to work with higher layers of abstraction, but you should get some value out of it. What I think happened is that React just removed some work from lower layers and created even more work at a higher abstraction layer. I would say that React gives you more work in terms of cognitive load and also in terms of development time if you look at it on a medium to long time-frame.
samsquire 3y ago
I think large systems get so large and complicated that they become very hard to reason about simply and think about. They become difficult to change their architecture or tweak them. So developer velocity takes a hit and the system is so complicated that it's hard to change anything. LibreOffice, Mozilla Thunderbird are of such scale that it's difficult to change these applications how they work today.

magic_hamster 3y ago

What will you recommend as an alternative?

hasanhaja 3y ago

+1 Have you been exploring any other technologies since React?

deleted 3y ago
[deleted]
jongjong 3y ago
For my newest project, I'm going for plain HTMLElement (Web Components) but if I find that I can't live without reactive data binding/rendering, I will probably use Lit https://lit.dev/ https://lit.dev/ So far it looks like I won't even need to go there... It turns out it's pretty easy to manage a web-component's dynamic state without reactivity (at least based on how I architect my apps). I find the HTMLElement lifecycle hooks (and attributeChangedCallback) to be sufficient.

DigitalSea 3y ago

A lot of the React fanatics are in denial about this. But, I've seen some absolute messes. Does anyone remember InVision? You probably have forgotten about them because Figma and other design tools ate their lunch, but part of their failure and delay in InVision Studio being released was in part because of React. I know other companies have encountered limitations with React and had to hack around them, most notably Atlassian who had to break their app up into apps (essentially parts of the app were smaller apps) because they wanted to use state management for everything and the memory problems were astronomical. React got popular because at the time, Angular.js was the framework of choice and we can all agree Angular had some serious problems like the digest cycle and performance issues working with large collections. React in comparison to Angular was a breath of fresh air, but in 2023 there are far better choices now than React. The thing is, React started out as just a view library and the community are mostly to blame for how terrible it has become. How many state management libraries have there been? How many router packages? Devs think they want a library, they actually want a framework. It's why the most popular uses of React are not vanilla React, they're frameworks like Next.js. Also, when you compare the performance of React to other libraries and frameworks, you realise it's one of the worse performing options. It's slow. The whole entire notion of Virtual DOM was groundbreaking in 2013, but in 2023, reactive binding approaches like those taken in Aurelia and Svelte are far superior and better performing. Virtual DOM is overhead. Has anyone ever seen a large-scale React project that is just using vanilla React? I've seen a few large-scale React codebases and many of them were a tangled spaghetti mess. It gets to a point where React's lack of opinions and standards for even the most basic of things mean you can see the same thing implemented 100 times in the React community. If you're building something beyond a landing page or basic CRUD app, you need some conventions. There is a reason despite the hate it gets, Angular is still used in enterprise and government settings. It's verbose, but you write components and other facets of your apps a specific way and know that Developer A implementing a feature is going to be understood by Developer B because it's not going to be so self-opinionated. This is something that backend frameworks learned years ago. Don't get me started on the terrible communication from the React team. A good example is how they have handled React Server Components. They changed the docs to recommend RSC's by default, despite the fact many community packages don't work with them or require additional packages. The way they approached RSC's and rushed them out was terrible. This isn't the first time either. I have been working with Aurelia 2 (https://docs.aurelia.io https://docs.aurelia.io) and I love it. It's intuitive, it's fast, the developer experience is great, it comes with all of the needed dependendencies you need like a router, validation, localisation and whatnot. No need to go building a faux-framework of Node packages bloating your app. I've also been working with Web Components, which are in a really good place now too and getting better with each proposal (there are a few good WC proposals in the works right now). Developers need to start using the platform more. Web Components have been supported by all browsers since 2020 (Chrome has supported them since 2013), so it's a good time to dive in. Using something like Lit gives you a nice development experience. Part of the problem is React developers have been brainwashed into thinking classes are bad because of some terrible design decisions in React (which led to Hooks) and writing Web Components relies on using class syntax (although, you can write them as functions if you really want to). React is anti-standards, it's anti-developer and it's bad for the platform. The fact that React is ten years old and doesn't support Web Components still, goes to show just how little the React team cares about Web Standards . I know jQuery is a bit of a meme now, but at least jQuery helped shape modern standards. Has anything good come from React for the platform?

5Qn8mNbc2FNCiVV 3y ago

I'm certain that this would have happened with any other framework mentioned as well and pointing towards React being the issue is just searching for a scapegoat where there is none

Ambolia 3y ago
The problem starts in html, css, javascript and the browser as a development platform. React tries to patch over those issues, and creates some new issues. People claim other frameworks solve the same issues without introducing any significant new problems. I'll remain skeptic until I see a couple of huge full-functionality apps in those frameworks that manage to keep a clean codebase and good performance. I've seen too many times people "solving" frontend development, most of the time that solution just amounts to documents linked to each other, and avoiding complex forms and interactivity, but if you just do linked documents, frontend development was solved in the 90s, and you don't need javascript at all.

threeseed 3y ago

You can say this about any technology though. Whenever you prioritise delivering features and are ambivalent about tech debt then of course the quality of the code base will suffer. There is nothing inherent to React that makes it significantly worse than the many other Javascript frameworks out there. At least it has the benefit of having ongoing support by a major vendor with a record of long term support for open source projects. That's not something that is all that common in the Javascript ecosystem.

jokethrowaway 3y ago
> There is nothing inherent to React that makes it significantly worse than the many other Javascript frameworks out there. There definitely are plenty of things which are an order of magnitude harder in react than any other framework. One flow data is an example, having to install deps for everything from state management to css is another. All the choices compounds and make complicated projects even more complicated, increasing tech debt. Don't get me wrong: Angular (and for sure other frameworks I can't think of) had the same problem; many other frameworks do not. These days I'm very happily developing against Solid Start with not a single issue I can't think of and a syntax which is very close to React.
mrd3v0 3y ago
"There is nothing inherent to React that makes it significantly worse than the many other Javascript frameworks out there." That is exactly the kind of conclusions that come from not understanding what runs under the hood.

locallost 3y ago

I agree with most of it, but I still had to chuckle at the "don't understand what's happening under the hood" part. The browser and JavaScript are themselves very high level, so it's funny how e.g. not using React would make you understand more what's going on under the hood. It's a pretty deep hood.

deleted 3y ago

[deleted]

5350-uiop-1130 3y ago

i think the popularity of react (and node) comes down greed. do more with less. a tumorous outgrowth of the "move fast and break things" attitude of early FB development and cargo culture of the tech boom eras. you can have one dev write the front end and most of the server side code too. not only that but they have to handle much of the tooling, testing and debugging. and the learn2code push also was designed to saturate the market with lots of these devs. many of whom lack the background knowledge to understand what they're doing. i seen this job expand through the years from a smaller set of responsibilities to a much larger one where most of your work is only indirectly (and irritatingly) related to what you're actually trying to do.

deleted 3y ago

[deleted]

rewmie 3y ago

> I feel like the new generation of devs got used to working with these abstractions and by some measures they seem highly competent, yet it feels like they're missing some critical knowledge; like they don't understand what's happening under the hood. Is this remotely relevant, though? I don't think it is. The whole point of working with higher level abstractions is to not have to care about the lower level bits. We all know that things are not as optimized as they could theoretically be, and that's ok. People are paid to deliver value, and microoptimizing stuff just wastes everyone's time.

jongjong 3y ago
It's fine to work with higher layers of abstraction, but you should get some value out of it. What I think happened is that React just removed some work from lower layers and created even more work at a higher abstraction layer. I would say that React gives you more work in terms of cognitive load and also in terms of development time if you look at it on a medium to long time-frame.

samsquire 3y ago

I think large systems get so large and complicated that they become very hard to reason about simply and think about. They become difficult to change their architecture or tweak them. So developer velocity takes a hit and the system is so complicated that it's hard to change anything. LibreOffice, Mozilla Thunderbird are of such scale that it's difficult to change these applications how they work today.