Why do a lot of people here hate react so much? I started my eng career with Laravel and plain JS. After working with React, I've never seen anything like it. I feel like building scalable apps is achievable and front end is fun with it. Even when moving between different tech companies, working with React again is such a breeze and easy to pick up. On top of that, with the TS support, huge community libraries, I feel like I can build and scale anything quite easily.
why are these new features "scaring" people away? we can still build with SPA or the old ways. I don't think anyone complaints when NoSQL DB was released or when spring boot was released in 2014? what about when Kotlin was released? we don't have to use them if you don't want it.<p>Weren't jetpack compose and swift UI inspired by React? I saw it somewhere in the android docs and now its probably deleted, I can't find it anymore.<p>But then again, I don't have "decade" of experience in tech, yet. I have no idea if building huge web apps (i.e airbnb) using jquery or plain js with large teams is as enjoyable back then? My thought process is changed, I can't even think on how to solve the state management, dom manipulation, side effects etc with plain js anymore.<p>Nowadays I just built on what I'm familiar with and focus on what I want to build. who knows, maybe in the future I will also complaint about new frameworks and mention how good React was :)
Awesome release.<p>I feel sorry though for someone getting into frontend dev now.<p>> is a new hook to order Actions inside of a Transition with access to the state of the action, and the pending state. It accepts a reducer that can call Actions, and the initial state used for first render. It also accepts an optional string that is used if the action is passed to a form action prop to support progressive enhancement in forms.<p>I’m pretty sure it’s a cool feature but, what a mouthful. Imagine you decided to start developing websites today, how do you even start?<p>EDIT: React is still an exceptional framework and this release is certainly an improvement.<p>My criticism is more FE development in general not just React.
Nothing new to what I am going to say and not strictly related to React 19.<p>I once loved client-side frameworks like React.<p>Then I realized: Great, we managed to add complexity wherever possible. In the backend, in the front-end, in the DevOps stack, EVERYWHERE.
And more layers will be introduced to keep all that distributed complexity in sync.<p><i>sigh</i>
The blog post is an easier read: <a href="https://react.dev/blog/2024/12/05/react-19" rel="nofollow">https://react.dev/blog/2024/12/05/react-19</a>
There are 45 comments so far and 7 references to "redux". I'm just gonna rep for the Recoil clones here and mention Jotai, which likely already works with React 19 without any necessary changes.<p>With enough front-end complexity, other state managers get in the way more than should. So, to anyone who might be tempted to hate on React, but really has just grown weary of endless walls of action constants, or plumbing props, or fighting nested providers/contexts, or resorting to pub-sub; give something like Jotai a shot.
I don't like most of the new features introduced. Actions, and the useActionState/useOptimistic hooks seem like massive complexity pitfalls. The 'use' hook has a very uninformative name. It doesn't handle promises created inside the component. While I assume there are very good reasons for that, my impression is that passing promises as props and handling them with the use hook will create more complexity - more than current workarounds.<p>Server Components also look fairly complex, and I'm glad I haven't had to deal with them so far.<p>The improved error messages on hydration errors are welcomed. The <Context> as a provider and ref as a prop changes are nice QoL changes.<p>Overall, I like React/Preact as far as building SPAs go. Using it with a feature-rich component library (say, MUI) and a simple state management solution (like Preact Signals) makes it very straightforward to build SPAs, as far as I'm concerned. But I worry about the complexity creep. The descriptions for the new hooks in those release notes put a massive cognitive load on me just by reading them.<p>The React Compiler, on the other hand, is a much needed tool. It should result in components that are less complex, as the programmer won't have to write typical optimizations by hand, as part of the component itself. I'm looking forward to its release and eventual integrations with Vite and etc. From what I heard, Preact will support it too.
I wish they rename "use" API to something else other than the common prefix for hooks. I imagine someone new to React hooks might be confused when they see that `use` can be called conditionally, while hooks can't.
Does react use semantic versioning?<p>I’d hate to have to deal with incompatible versions at the rate they release major versions.<p>If you try to stick with one version do you soon get stuck because you need to take a bug fix or security fix that’s only available in a later major release (but updating breaks other things)?<p>I want to build software on a stable platform so I can spend time on improving the software or writing something new, not keeping up with updates.
I see people complaining a lot about React, why is it? What are the alternatives?<p>PS: I'm not a frontend engineer but I find this topic interesting.<p>Thanks!
Great to see this--there are some nice features that encourage using standard web technologies like forms, and some solid quality of life improvements.<p>However, I'm disappointed (but not surprised, this was listed as out of scope for 19) that triggering Suspense is still basically "use a framework that supports it." I have not been able to find any documentation or blog posts about the mechanism. I've tried to figure out how it works by looking at TanStack Query, but I've had limited success so far. I've found they're copying React's twist on Promises [1], but I haven't gotten this to work yet.<p>I know the general idea is you throw Promises, but Suspense explicitly forbids using promises created during rendering. This means you can't just interrupt the component's initial render to load some data, and then restart it when its data is available. This means the component needs to deal with null data somehow, instead of, e.g., being able to call a custom `useSomeData` hook and rely on it to first suspend and then return the loaded data. Not having to deal directly with loading states in individual components could simplify things quite a bit.<p>Has anyone explored this side of Suspense?<p>[1]: <a href="https://github.com/TanStack/query/blob/main/packages/query-core/src/thenable.ts">https://github.com/TanStack/query/blob/main/packages/query-c...</a>
Updates like this are exactly why React sucks.<p>If you're going to add something to the main project, it should be well-designed, clear, and in good taste. React won over things like Angular because the latter had poorly designed abstractions. It was supposed to be "just javascript" (which was always more of a vibe being actually true).<p>Just look at wtf actions are. In their blogpost[0], the old way of doing things is only a few lines more, but is much clearer. The 'useTransition' still has to update the error state - but at least it saves you from typing the pending state!<p>But of course, you're not supposed to use this directly, you're supposed to use useActionState. And this blog post makes it's usage very clear by just returning null to show something that's supposed to update state. So very clear, and intuitive /s<p>Stuff like this really should've been in a separate library. It baffles my mind that core behavior like state management is left to external solutions, but then random crap like this makes it into the main project.<p>[0]<a href="https://react.dev/blog/2024/12/05/react-19#actions" rel="nofollow">https://react.dev/blog/2024/12/05/react-19#actions</a>