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.
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.
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.
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.
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 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.
In my previous startup they 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.
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.
Like most problems in IT in general :-)
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?
Same for people that have never used Angular, or only used the old AngularJS 1.x
I have more experience with Angular, but I don't hate any of the other frameworks, I've built apps with React, Svelte and tried out Vue.
Drawing canvas: https://www.tldraw.com/
Code playground: https://replit.com/
Supabase dashboard: https://supabase.com/
Vercel dashboard: https://vercel.com/
Workout tracking: https://workout.lol/
Chatbot: https://chatgpt.com
Note-taking: https://www.usememos.com/
Tax filing: https://ustaxes.org/start
Python notebook: https://marimo.io/
LoL info: https://www.op.gg/
Sports matches: https://www.sofascore.com/
Trading news: https://seekingalpha.com/
Website builder: https://mmm.page/
Podcast maker: https://podcastle.ai/
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.
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.
That probably explains why the Amazon website just took 5 seconds to load on my phone while on a gigabit connection at home.
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]
[1] - https://htmx.org/essays/when-to-use-hypermedia/
[2] - https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it
[3] - https://htmx.org/essays/a-real-world-react-to-htmx-port/
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.
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
refine: https://github.com/refinedev/refine appsmith: https://github.com/appsmithorg/appsmith
there are heaps what are you talking about!
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.