Live data from Hacker News

Why I don't use React

areknawo.com

21–30 of 40 posts

Re: Why I don't use React

#21
post #15

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. 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.

Re: Why I don't use React

#23
""" Yeah, React is popular - almost every web developer knows that. And it's this fact that makes new project use it. Popularity in the OSS world can be considered as a guarantee of the stability of the project. But, what if someone doesn't really want to follow the "hype"? What if they want to be unique, to stand out? I know it might sound like a joke to some web developers, but this post as a whole is, as previously said, more psychological more than rational. """

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.

Re: Why I don't use React

#24
post #14

> 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. Howe…

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-...

Re: Why I don't use React

#25
post #15

Earlier quoted context omitted.

> 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'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 rem…

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.

Re: Why I don't use React

#26
post #14

> 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. Howe…

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.

Re: Why I don't use React

#28
post #14

> 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. Howe…

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 altern…

I don't use immutable.js or any other framework. Just regular, functional JS.

Re: Why I don't use React

#29

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. 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…

Well I used plain JS and precompiled Handlebars templates for one project that I really wanted to keep lightweight.

Re: Why I don't use React

#30
post #14

> 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. Howe…

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 h…

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.

Post reply on HN