I also really don't get the apparent hate for react, usually from people who haven't used it all that much.
I've interacted with a not insignificant number of people who seem to hold this opinion. Usually their arguments boil down to one of:
* Frontend engineering is always chasing the next shiny thing, and react is one of them. There's probably some truth to this historically, but react has been a thing since 2013, and pretty 'mainstream' since 2015 or so.
* Frameworks and libraries add 'complexity'. I almost never hear anything specific when I ask about what complexity they're referring to. IMO if you work on a non trivial application without a framework, you'll just end up inventing your own poorly maintained, poorly tested and poorly documented framework. This might be fine for a weekend project, but rarely something you should do at a company.
* People also often complain about the compilation/bundling step. This might've been harder to manage historically, but now with battle tested frameworks like expo, nextjs, meteor etc, there are very few reasons to write a webpack configuration or build pipeline by hand.
I hesitate to admit this, but for me it's simply because I still don't know the right pattern to use. I'm a longtime backend developer that knows several useful and usable patterns on how to organize layers of code into files and functions and conventions, that work very well. I've spent quite an amount of time on the frontend, to the point where I feel like I should have been able to identify a decent pattern by now, and I just haven't. And it's to the point that I started doubting whether the problem was really me, or if it's a problem with the framework. I've read the revised React 18 docs backwards and forwards, and all the stuff about how you might not need useEffect, and I've read countless articles about outer components and inner components and view components and higher order components, and when to use context and when not to, and there's a point at which all the patterns start to collide and feel self-contradictory. Meanwhile my team has a massive snarl of very large react components with all kinds of awful practices like nested contexts and useEffect for state management, stuff I tried to counsel against for a while until I got promoted away from the team... I just couldn't find the best practice that the community actually agrees upon regarding how to refactor and design a complex website with many components with deep functionality.
I feel this. I think it's a consequence of react being a fairly unopinionated collection of tools.
Coming from a Rails background, it's pretty jarring. It's like the difference between being told, "Here's how you build a house" and "Here's how you use the tools in this toolkit".
React offers more freedom at the expense of guidance, and you get much less standardization as a result.
This is exactly why I love it because it's not opinionated. I've been doing frontend interfaces for 30 years and it's one of the few times I've felt that I can write things the way I want and not be forced down some preconstructed path.
I get why some wouldn't like this but for me it's a breath of fresh air and why I continue to love working with it.
Agreed. On re-read, my prior comment sounds almost negative towards React's lack of opinions.
That couldn't be further from the truth! While I appreciated having a path laid out for me when I stated out, 10 years end I much prefer forging a path myself.
Mastering these tools, and leveraging my own creativity in how I use them, is much more enjoyable.
I actually agree with this being / having been a problem.
I think the root cause of this is react not really being a framework, rather just a library that allows you to write declarative code involving state that in the end, outputs a DOM tree. IMO it does that quite well.
It doesn't have very many opinions on how you should structure your code, how you should organize your state, how your routing logic should work etc. I think that's where frameworks come in. React was quite popular long before frameworks like nextjs, meteor, remix, ... became 'mainstream', causing lots of developers to invent their own (poorly maintained) frameworks.
> I also really don't get the apparent hate for react, usually from people who haven't used it all that much
In defence of the haters, I think we’ve all seen our share of horrendously organized React SPAs. Dependency hell, (seemingly) infinite prop drilling, components thousands of lines long, the list goes on.
Some people think they hate React, when in reality they hate a specific implementation of it.
I contracted on a few different projects over a few years, with React involved in all of them. Each team had their way of doing something, and goodness me... each team I joined was way different than the previous one with respect to approach, style, testing, etc. And anything I did that was "wrong" (meaning, not to their particular approach), I was ... belittled or talked down to as if I was some imbecile. In a couple cases, I used an approach with company B that they'd discarded a year before, but 6 months earlier, my work with company A's team led us down adopting that same approach, with decent results. But company B knew better, saying that approach was 'crap' (but... looking at their own internal docs, 2 years earlier, it was the hottest approach).
I was shocked at how much time some teams spent on reinventing wheels rather than using some off the shelf components. "We need everything to be done in house so we can document it and have full control". But... designing all your own widgets is going to take months. "React makes it easy though, so don't worry - we know what we're doing' Yet... they didn't - untestable components that couldn't support what the original requirements called for months earlier, etc.
You know how people crap on PHP because there's so much 'bad' PHP out there? But others say "it's just how you use it - frameworks XYZ are great!". I feel the same way about React. There's probably some great examples out there, but I somehow tend to see a lot of lesser quality stuff.
Most of the use cases I've seen up close... there wasn't any real magic or benefit to React vs something else, but everyone was jacked to get more React experience on their resume for their next gig. It didn't really matter if the resulting output was good or not, just that they used React.
I don't hate React - it's a library. I'm tired of much of the B-team players requiring it to be considered "professional" (while simultaneously) eschewing testing and documentation).
For people who have chosen it, and get to stay on the same project for several years, honing their skills on one codebase and iteratively improving, great. Enjoy.
I feel like the frontend community is suffering from the "eternal september" problem. Like PHP, it is very easy to get started so you get a lot of inexperienced developers writing very opinionated blogs that are shared with other inexperienced people who can't see the flaws. Interestingly it seems that the PHP community has matured and now consist of very reasonable and experienced "leaders", while the JS/TS community as a whole is still a long way from maturity. Don't get me wrong, there are many excellent JS/TS developers, but they face an endless stream of adversity.
In my previous startup the frontend developers decided to develop their own design library from scratch. My suggestion was to start with an established library and just adjust the style to match our look, but they wanted full control and ownership of the code. 3 years later, most of them left for new jobs and the library only contains a very basic set of components. Apparently accessibility and the rest of the "remaining 80%" part of the "80% completed" components were more difficult than they assumed. At least they had fun and could pad their resumes when they applied for new jobs, leaving others to maintain their m
This mindset was so different from the backend teams in the same startup. They preferred stable and known frameworks and libraries, and focused on the business logic. I had a feeling that the backend teams just got stuff down with little drama, while the frontend team was engaged in endless debates and rewrites. They had their own issues of course, but once they had fought the battle of choosing which language and stack to use, they stuck with it.
I worked with both and tried to stay away from most of the discussions, but it is clear to me that autonomy only works when you have a good balance of senior and junior developers that can have a discussion with the others without needing to "win" every time. As a senior developer myself, I have often learned new approaches from junior developers who have found a problem and dug in deep. Unfortunately I have seen too many senior developers and junior developers not listening to good advice from each other. The juniors think the seniors are outdated, while the seniors think the juniors are not capable.
> Most of these sound like team/people problems, not technology problems.
I wonder what are the frameworks or libraries that have exactly one widely accepted, idiomatic and correct way of doing most things, where the technology itself discourages anything else? Angular, maybe, at least with how batteries included it is?
It was pushed upon me by management. I would have opted for Svelte or Lit. So I hate it, I hate writing code in it, I hate that it wants to control all your DOM, I hate how they "re-invented" HTML with JSX components and how the code now looks like PHP, as JS wasn't annoying enough by itself. I hate how it makes accompishing even simple things a PITA. At least I can use Vite and not bother with their opinionated tooling. There you have it, these are some reasons for all the hate if you had to ask.
Dang you’re not wrong. I didn’t check all of them but in my phone those drawing ones are super responsive. If only most PWAs worked like that there’d be more goodwill for them. I personally feel most React apps and their abysmal performance (starting with facebook’s attempt) really hurt the PWA movement on mobile.
I dont think people are actually against PWA or React per se. In those examples above yes 80% of them should be using React. What most people have problems with are things like SeekingAlpha which doesn't need to be with React at all but is using it anyway. While I dont visit "SeekingAlpha" but most of the time these site will have one or two problems that makes it feel not a web page but a web apps.
Every single React app has to ability to be nice and performant.
The issue (and this isn’t React’s fault) is that every single web app is so obsessed with measuring analytics and engagement metrics and loading multiple ad containers and and and…
Whether Vite, or Svelte, or Vanilla JS, when you start stuffing a site with all these tracking pixels and other junk, they are all horrible.
There is likely a bit of observer bias going on with your comment, as many popular sites these days run React and they happen to run like crap due to the reasons I listed above.
Whether Vite, or Svelte, or Vanilla JS, when you start stuffing a site with all these tracking pixels and other junk, they are all horrible.
They're definitely horrible from a moral standpoint, but if you look at the flamechart of JS activity in your browser you can easily see that they sit idle 99% of the time and only send events to an API as low priority background work when the browser does things. They aren't what makes websites slow.
I don’t know how accurate this is. I just loaded up Walmart and Targets sites and they load very quickly and navigating between pages is snappy as well. What’s your metric for performance?
React is also incredibly behind the rest of the industry in terms of performance and has been for a long time. What you’re saying isn’t wrong but it’s a different problem on top of React.
Yes but in 6 months react will release a compiler to catch it up by a lot. Performance has diminishing returns and at some point, things just need to be fast enough (see vscode) and the industry will continue on as the switching cost is way too high.
True. But if the sites performed well (big if) and feel responsive, look nice, don’t break middle click and other browser functions - well I don’t see the problem, then. I don’t think the “hate” is irrational.
Which is why I think react (and other SPA frameworks) are now pointing beginners to full stack frameworks like nextjs, remix etc where those best practices are baked in. It took the JS frameworks a bit to find their path there but I think they are there now.
What are your thoughts on things like HTMX though, which with a small payload allow lots of SPA-like features and part of the content language itself. The other hatred I have is the need for all of this crap on top of a crappy language.
HTMX has a ceiling on how interactive/complex you can make your site [1]. If you know you will never need to exceed those sure. However I like to use nextjs as it gives me the peace of mind I will always be able to pivot or implement whatever the customer wants.
that's true[1] but there is also the programmer dictum "You Aren't Gonna Need It" (YAGNI)[2]
it very much depends on the type of app you are building, but I think many web applications could at least start with htmx and then, when more complex user interactions present themselves, use an island of interactivity approach that localizes the complexity.
this keeps overall system complexity as low as possible for as long as possible, and you may never need to go beyond htmx, which can lead to a much less complicated codebase [3]
I think nextjs does lead to a very simple codebase at every step of the interactivity gradient. You can have pure server side rendered HTML all the way up to full blown SPA and everything inbetween with just one tool rather than having...
1. HTMX itself
2. Your backend language Go/Java/whatever
3. Whatever JS framework for your interactivity islands
But yes we are all on the same team here of reducing complexity in the codebase and if HTMX works for you go for it.
How are you measuring 'nice'? How are you measuring 'performant'?
My assumption would be that if you haven't seen anything, even from the creator, then you just have different expectations to the people who do get value from React
It’s interesting I’ve asked this question several times and no one can point me to one. Performant meaning when react is used it’s not at the bottom in speed and latency[1].
I've interacted with a not insignificant number of people who seem to hold this opinion. Usually their arguments boil down to one of:
* Frontend engineering is always chasing the next shiny thing, and react is one of them. There's probably some truth to this historically, but react has been a thing since 2013, and pretty 'mainstream' since 2015 or so.
* Frameworks and libraries add 'complexity'. I almost never hear anything specific when I ask about what complexity they're referring to. IMO if you work on a non trivial application without a framework, you'll just end up inventing your own poorly maintained, poorly tested and poorly documented framework. This might be fine for a weekend project, but rarely something you should do at a company.
* People also often complain about the compilation/bundling step. This might've been harder to manage historically, but now with battle tested frameworks like expo, nextjs, meteor etc, there are very few reasons to write a webpack configuration or build pipeline by hand.