Why I don't use React(areknawo.com)
areknawo.com
Why I don't use React
https://areknawo.com/why-i-dont-use-react/
39 comments
Did I miss his reasoning for not using React?
It’s popular (apparently too popular) and Facebook is bad.
[deleted]
That article is just a wordy sort of high level view of React with almost nothing about why someone might not use React.
The incessant >bolding< of every other >word< is really annoying to >read<. Please consider using italics, the form of highlighting that doesn't jump out of the page at you.
[deleted]
I thought immutable data structures and their identity checks actually are helpful re performance in react.
So you don't like Facebook but you use it, interesting...
(https://www.facebook.com/areknawoblog)
"Why I don't use a hammer (when I need a screwdriver)"
It seems that when uMatrix blocks some of the resources the website expects, it pegs one of my CPU cores and uses a gradually increasing amount of RAM.
I clicked on it b/c it made to the front page and I read the entire article but I can't understand why he doesn't like to use react.
> I personally struggle with embracing immutability. Maybe that's because I'm more of a performance guy. Even though I really want to make my code more maintainable, and thus I started reading a lot more about FP in recent times.
Honestly performance is a non-concern for me. I worked on a React app that ran on IE9 without any major performance issues and almost no code tuning. It's not even worth thinking about. However, avoiding immutability for the sake of maintainability and developer experience is something I would never give up.
Honestly performance is a non-concern for me. I worked on a React app that ran on IE9 without any major performance issues and almost no code tuning. It's not even worth thinking about. However, avoiding immutability for the sake of maintainability and developer experience is something I would never give up.
To properly embrace immutable.js and not have performance issues, you need to fully embrace it and it's API and use it as the basis for all of the models in your app. We did a half-baked approach which uses immutables in the data store (so we can leverage quick prop checks) but also convert those into normal JS objects in the business domain. This makes our use of it noticeably slow.
Immer [0] is a much better alternative IMO.. you get all the benefits of immutability without having to use a radically different API than normal. And the performance is roughly the same as immutable. And using it with Redux is natural [1], removing the need to do a bunch of nested object copies
[0] https://github.com/immerjs/immer
[1] https://daveceddia.com/react-redux-immutability-guide/#easy-...
Immer [0] is a much better alternative IMO.. you get all the benefits of immutability without having to use a radically different API than normal. And the performance is roughly the same as immutable. And using it with Redux is natural [1], removing the need to do a bunch of nested object copies
[0] https://github.com/immerjs/immer
[1] https://daveceddia.com/react-redux-immutability-guide/#easy-...
I don't use immutable.js or any other framework. Just regular, functional JS.
That seems to be a common attitude with front-end devs these days, to the detriment of web users. The performance impact of React, Angular, any other heavy frontend SPA framework is immense. Plus the extra weight required to get back to feature-parity with frameworkless (url rewriting, scroll reworking, etc). There are some complicated web apps like GMail where an SPA makes sense (although it's still super slow and heavy), but I've been on so many corporate teams where there's a big push to move a traditional site to React/Angualar/etc and it's never worth it. Development productivity is not worth sacrificing usability, and often developer productivity doesn't actually improve anyway. But I always seem to be fighting an uphill battle in this regard. I'm in the process of realigning my career away from full-stack dev nowadays because the state of frontend dev is so horrendous, I want no part of it anymore.
I honestly don't know what you're talking about. What performance impact? As I mentioned above I've never encountered a major performance problem in a React application, even on very old browsers.
Regarding your other concerns I suspect you and I work on very different types of projects.
Regarding your other concerns I suspect you and I work on very different types of projects.
Can you share some React-based webapps that have poor performance?
React makes sharing and maintenaning code easier IMO unless it has been over-engineered in the name of DRY.
I think I'll write my own version of the article. I'll keep it more succinct though.
I like vue better.
I like vue better.
I don't know about you, but I don't use react because I don't know how to use it.
I think it would be more interesting to read about people who know how to use it, have used it, but now choose not to.
I think it would be more interesting to read about people who know how to use it, have used it, but now choose not to.
The first step to knowing how to use something is using it.
I was mostly trying to make a civil snark. That the author of the artile seems to be making these comments as an "outsider" and has not actually used it in real life projects. Therefore I am a bit confused as to where they are coming from.
As for me I 'll probably give react a try when it aligns with the tasks and scope of my work, nothing against it.
> I think it would be more interesting to read about people who know how to use it, have used it, but now choose not to.
I use react all the time, particularly at my job, and it's not that I choose not to use it now, I just choose not to use react for some projects. For simple UI I reach for server side html templating, with a sprinkle of CSS and Vanilla JS. For UI library code that could be shared with React and non react projects, again I use vanilla js. For big complex UI like a dashboard with graphs and charts, and bunch of options and nobs, etc. I will use something like React. There's a time and place where each tool shines or is the better choice.
I use react all the time, particularly at my job, and it's not that I choose not to use it now, I just choose not to use react for some projects. For simple UI I reach for server side html templating, with a sprinkle of CSS and Vanilla JS. For UI library code that could be shared with React and non react projects, again I use vanilla js. For big complex UI like a dashboard with graphs and charts, and bunch of options and nobs, etc. I will use something like React. There's a time and place where each tool shines or is the better choice.
Well I used plain JS and precompiled Handlebars templates for one project that I really wanted to keep lightweight.
> I think it would be more interesting to read about people who know how to use it, have used it, but now choose not to.
I suspect you won't find many people in this camp. I know a great many Angular->React converts, but very, very few lapsed React devs.
I suspect you won't find many people in this camp. I know a great many Angular->React converts, but very, very few lapsed React devs.
I'm one of the people in that camp. I loved React, and still think it's a fantastic tool. A few things that have made me move on:
- Svelte (https://svelte.dev)
- People thinking Redux is brilliant. It's good, but it's a far too complex system to simply manage state. I'm aware this isn't React, but I have worked on very few React projects that don't have Redux
- Run-time load. Back to Svelte. It's inspired me to remove as much run-time work as possible.
- API complexity. The React API has exploded over the last year or two. Hooks, memo, portals, error boundaries. Most of them are clever solutions, but are only required due to the limitations of React.
- Svelte (https://svelte.dev)
- People thinking Redux is brilliant. It's good, but it's a far too complex system to simply manage state. I'm aware this isn't React, but I have worked on very few React projects that don't have Redux
- Run-time load. Back to Svelte. It's inspired me to remove as much run-time work as possible.
- API complexity. The React API has exploded over the last year or two. Hooks, memo, portals, error boundaries. Most of them are clever solutions, but are only required due to the limitations of React.
I though svelte was interesting until I read a recent article where they introduced that `$:` label. It seemed like a very poorly thought out approach to me.
That said, I honestly don't think I'll ever go back to using a framework with templates. My distaste for them has only gotten stronger the more I use React.
> People thinking Redux is brilliant
Redux is good as long as you understand what it's good for and only use it when it buys you something. My default recommendation is to not use a state library until you find you need one.
That said, I honestly don't think I'll ever go back to using a framework with templates. My distaste for them has only gotten stronger the more I use React.
> People thinking Redux is brilliant
Redux is good as long as you understand what it's good for and only use it when it buys you something. My default recommendation is to not use a state library until you find you need one.
Having used a bit of Svelte 3, the label is quite easy to understand. On top of that, it's valid JS.
> Redux is good as long as you understand what it's good for and only use it when it buys you something. My default recommendation is to not use a state library until you find you need one.
Agree 100%
> Redux is good as long as you understand what it's good for and only use it when it buys you something. My default recommendation is to not use a state library until you find you need one.
Agree 100%
As an Angular developer I would be interested in reading some Angular->React conversion stories. I've dabbled in React a few times but it never felt compelling enough to switch, but maybe I missed the good stuff.
You should try Vue. I tried to use React a couple of times and never got the hang of it. With Vue however, you could say it was love at first sight (and I've heard some other people say the same)
Why is this here? the article has no substance and it is poorly reasoned subjective preference.
I expected an article about how the JS environment is out of control and you should just use HTML. Instead it looks like another call to action to migrate the JS herd to something more shiny.
I'm hoping we have an anti-JS revolution and go back to HTML-only unless JS is absolutely-without-a-doubt necessary.
I'm hoping we have an anti-JS revolution and go back to HTML-only unless JS is absolutely-without-a-doubt necessary.
Waste of time to read.
TL;DR: I do not use React because I choose not to
TL;DR: I do not use React because I choose not to
tl;dr I don’t use React because I don’t like immutability, it gives you bad performance (spoiler: it doesn’t). Also it’s from Facebook, everybody knows that Facebook is evil, hence React is evil.
Really?
Really?
Also because I believed the FUD about its patent license. The patent license only ever granted rights compared to a BSD-licensed project without an explicit patent license.
Wasn't event baited
Bwahahha, ' What if they want to be unique, to stand out?' I am liking this more as absurdist fiction than an actual analysis of the js landscape.