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