React is fundamentally bad technology. I know there are historical reasons for the virtual dom but the reasons that justified it don't exist anymore. If you want to do anything interesting with react that involves interacting directly with browser APIs you need to deal with these absurd use effect hoops to initiate state with references to dom nodes.<p>I've worked on 4 large react code bases and they always devolve into these blobs of non-deterministic async state with unpredictable performance.<p>I actually like JSX and the component model so I just use solid-js which is everything I like about react but with effortless performance and you can actually get away with never using effects so your code can actually be deterministic.
Alongside the work on server components, they also deprecated Create React App, which was previously the official way to create new apps for development, and which had pretty good ergonomics. However, you won't find that documented on the actual CRA site - when you go looking for why your dependencies are out of date, you'll find references in obscure GitHub issues: <a href="https://github.com/reactjs/react.dev/pull/5487#issuecomment-1409720741">https://github.com/reactjs/react.dev/pull/5487#issuecomment-...</a><p>As much as I like the React team and appreciate their willingness to try things (and hooks have grown on me a little), they are human, and I think some of the decisions and direction they've taken things is a mistake.<p>I was part of the team who deliberated on the decision to use React over Vue in WordPress, and one of the reasons for my personal preference towards React was that it embraced JS rather than inventing a whole bunch of new things - yes, there was the funky syntax of JSX, but aside from that all the statements were regular JS, and it was much easier to conceptually understand than learning a new language. Hooks started taking us away from that, with weird functions that magically encapsulate state, and things like suspense and server components have strayed further from the light.<p>Making things like Next the official pathway to getting started with React is great and all for people building Node SPAs, but there's a whole wide world of software outside of that bubble, and I hope the React team peers out a little more often.
> <i>it’s not clear/an easily understandable mental model for most people</i><p>That's already the case, thanks to hooks. Hooks are weird, and should not be taught to junior programmers because it will confuse them for the rest of their careers. Hooks are weird because it doesn't align with functional programming paradigm or with OOP paradigm... it is a new paradigm and it is like nothing else.<p>More on that: <a href="https://medium.com/codex/can-we-all-just-admit-react-hooks-were-a-bad-idea-c48120c5188d" rel="nofollow">https://medium.com/codex/can-we-all-just-admit-react-hooks-w...</a>
Maybe, it's just me - I miss the good old days when sites didn't have anything to do with react or similar. Everything was just plain old hyperlinks and some basic JS. I am not even talking about the 90s, just look at what Facebook used to be in its early days - such a simple UI, just based off of hyperlinks, very basic JS. That simplicity alone made it such a joy to use.<p>Today, I don't even feel like logging into Facebook, because a fucking dropdown menu for a post (which barely has 4-5 options) is a <i>Component</i> that is loaded via AJAX. This is not even an overstatement.<p>I miss the simplicity of the web.
Good point on the two Reacts. Call me old-fashioned, but I still prefer being able to serve a React app over a CDN instead of needing a Node.js server. Might be in the minority these days though.
The React ecosystem has been trying very hard for a long time to enable developers to write code that is objectively bad, vis-a-vis colocation of concerns all in a single bigass, hard-to-understand function. Hooks were last straw for me, but the trend began before that.<p>React components should be simple stream transformers, nothing more. Accept props as input, produce deterministic HTML as output. All that other crap? Calling the API, massaging the data, business logic? That belongs somewhere else, outside of your component.
I sorta feel the same way. I used to be excited to spin up a react project, and loved working with it daily for 8+ years. It really was wonderful. Junior devs used to be able to write clear, performant, bug free code in react without a ton of hand holding. One of its greatest testaments. Now you need to spend 20 minutes figuring out what someone is trying to accomplish with a useEffect hook with 10 dependencies and if it’s running as expected or if that dependency should be wrapped in a useCallback. :) And that’s without even getting into the deep end of server components and bifurcating your frontend into static server and client components and hydrating the dom and using next router and blah blah blah. And we are told to use a framework by a VC backed company because create react app isn’t maintained anymore? Ok. Gonna go write some erb in rails or something.
> It’s frustrating that diversity efforts visibly took a backseat with React leadership<p>Who cares?!? Imagine trying to justify your decision to choose a framework to a manager by talking about their diverse leadership.
Share the same sentiment. React has gotten weird. It feels like they took a perfectly done design and awkwardly pushed it over its boundaries. (They got away with hooks, but this time it’s different)<p>Funny thing is they say it’s for the DX to become more like PHP. But the PHP I remember was practical.
I've been enjoying the simplicity vanilla light-dom custom elements and minimalist express server for the API.<p>Lit-html for near zero-cost dom updates.<p>Been doing it for years, and struggle to understand why anyone would want to put up with the complexity of react.
Nextjs is pushing for the server components and I don't really blame them for doing so. Netlify is trying to back anything that's not nextjs. If anything I'm kind of surprised that big cloud players are completely ignoring this market right now.
Comments here show me that useEffect() is apparently incredibly hammer-shaped. And all things related to state and network look like nails in the eyes of frustrated React users.<p>I think those people would be better served by frameworks that hold fine grained reactivity as a virtue. If you have appetite for spaghetti at least use real pasta instead of trying to roll steak into thin stripes to tangle it.
Many people tend to gain a good understanding of React by building on top of it. Unfortunately, majority of the tutorials, lessons, recommendations, and paid courses usually start off using a framework where a lot of stuff have already been added. The effort to simply understand a complex setup as compared to starting React with the bare minimum and slowly adding whatever packages / libraries are needed.<p>React should start by a simple initialization:
-> Setup React
-> CSS library
-> State management<p>And then, other packages or libraries can be considered to be added whenever the current needs of the application exceeds what the bare minimum setup has provided.<p>While in the end the set of packages and configurations performed may tantamount to what a framework already provides easily, the cognitive load starts on a piece that is well understood and grows alongside the evolution of the software product being delivered.
A couple of things make React extremely valuable to me:<p>- The functional programming model (State => UI) allows building very complicated interfaces in a very simple way, by defining dependencies with useEffect() and other hooks. It can take years to master it, but when you develop complex apps where all kinds of state needs to update when some other state changes, you really appreciate how simple it is to do with React.<p>- React is very backward compatible and allows you to migrate codebases to newer React features slowly over the years, while already using those new features in other parts of the code. (I still have some class-based components here and there.)<p>- There is a huge ecosystem of existing React components and tools you can use in your applications. They make it a very productive environment to get stuff done quickly. Frameworks like Next.js make it a breeze to develop and deploy static apps e.g. to S3.<p>- You can apply your existing React skills to React Native when you need native apps.
> I feel like the lack of understanding comes from not communicating properly with the community<p>"Don't load data in useEffect!"<p>Okay, but [this and that and this] so how should you actually do this?<p>"Oh, use useEffect duh! We meant.. Don't, like, use it too much."<p>"And React function components should always be pure!"<p>Wait, aren't the hooks storing and mixing states into the function in a way that's almost creating a sorta sudo object? How is that pure?<p>"No, we mean 'they are pure!' when we want to be dismissive. Of course they are not really "pure".."<p>Edit: The one weird trick they don't want you to know and will have all the React CRUD kiddies screeching; Use useMemo to kick off work early ;)
Everyone fucking off & writing frameworks that oh just so <i>happen</i> to be server side is incredibly bold self dealing. Now front and back end are deeply conflated, and instead of finding consistent controlled paradigms to tackle async on the front end we've just made an even bigger soup of what-renders-where-when.<p>We have been deeply mislead these past couple years. React ecosystem should have been working on better faster front end systems that integrate data better. Redux should just have been a start. Instead, managing data has gotten more complex and worse.
Has anything really changed since around 2021? That's when I started using it. And I never looked back, except for very simple projects where I use vanilla HTML/CSS/JS.
It is ridiculous to suggest that React is worse today than ten years ago. Remember all that time people spent battling their build scripts? Or what about the obtuse 3rd-party state management libraries everyone used to augment class components? It was torturous from the start.
We use Preact nowadays. It feels so much better and intuitive having first class support for ESM and use the browser's technologies for events, for instance. The TSX to JS transpilation is a bonus.<p>In general, for us: the Vite + Preact team feels just right.
React is overengineered. I guess it may have been worth it at some point in the past but the reality of browser tech has changed significantly and now there exist simpler ways to get superior results.
I’ve never gotten into web development but enjoyed developing iOS apps in Obj-C or Android in Java.<p>Anyone recommend a website framework that might allow me to completely avoid html/css/javascript?
No new releases since June 2022 is a good thing. At some point you declare React complete and you put it in maintenance/optimization mode. No new api surface. Full backwards compatibility.<p>React is darn good. Don’t mess with it and go into enshittificaion.