25 ms·

React 19

307 points by gajus 2y ago

deleted 2y ago
[deleted]
deleted 2y ago
[deleted]
deleted 2y ago
[deleted]
gr4vityWall 2y ago
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. Server Components also look fairly complex, and I'm glad I haven't had to deal with them so far. The improved error messages on hydration errors are welcomed. The <Context> as a provider and ref as a prop changes are nice QoL changes. 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. 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.
deleted 2y ago
[deleted]
riffic 2y ago
here's what really matters: https://endoflife.date/react https://endoflife.date/react
- captn3m0 2y ago
  PRs are welcome to add the new release (and merge all the 18 minor releases).
- efields 2y ago
  Imagine if HTML5 had an EoL.
  - nicce 2y ago
    Some day
- mardifoufs 2y ago
  React is very backwards compatible, so the eol is much less impactful than for say, vuejs
demarq 2y ago
Awesome release. I feel sorry though for someone getting into frontend dev now. > 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. 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? EDIT: React is still an exceptional framework and this release is certainly an improvement. My criticism is more FE development in general not just React.
- ChrisRR 2y ago
  > Imagine you decided to start developing websites today, how do you even start I'm an embedded dev so I've so far removed from web dev, but recently started looking into learning web dev for some personal projects. My god what a mess. Any learning resource for a single topic , like javascript, Flask, CSS can't seem to stick to what it's trying to teach and insist that you start importing other libraries and frameworks. Most of the time they're not needed and the author just assumes that you understand this other library in order to continue following their examples So you google how to use that library, but the learning resources assume knowledge of a different library... When all the resources of just plain javascript and plain HTML/CSS. I don't want bootstrap or react, I just want to learn the fundamentals to build upon
- azangru 2y ago
  > Imagine you decided to start developing websites today, how do you even start? Not with React? Seriously, if you are starting developing websites today, the first thing you need to do is learn the web platform: html, css, javascript (probably typescript as well while you are at it), svg; and some basic server-side stuff. React is for when you get pretty comfy with those.
- notapenny 2y ago
  > Imagine you decided to start developing websites today, how do you even start? With HTML and CSS. And you don't touch JS until you understand the fundamentals of those. And only after those three do you touch a FE framework. I'm not even kidding either. Whether its React, Angular or any back-end driven templating, those things are all abstractions over fundamentals.
cyral 2y ago
The blog post is an easier read: https://react.dev/blog/2024/12/05/react-19 https://react.dev/blog/2024/12/05/react-19
- nailer 2y ago
  const error = await updateName(newName); Why would updateName return an error? Why not just throw an Error like JS/TS?
  - Mogzol 2y ago
    It's just an example async call, it could be anything. It's not the important part of that code example, it's only purpose is to show that an async call is happening. It could be written as a try/catch, or it could be written how they wrote it. I guess they chose that way because it's short and to the point.
    - nailer 2y ago
      Good example code is otherwise uninteresting apart from the concept that is meant to be shown.
  - BillSaysThis 2y ago
    updateName is a call to the backend/server to update the database...
  - rtpg 2y ago
    Some guesses: - People really like Result structures - People who wrote the API believe in the "operational issues and business issues should not be comingled" philosophy (so this function might raise on a connection error, but it _won't_ raise when there's simply an error like a name conflict) - People who wrote the example write Too Much(TM) Go
htunnicliff 2y ago
One of the best parts of this release: ref as a prop: Refs can now be used as props, removing the need for forwardRef.
- terandle 2y ago
  Being able to <Context value={1}> instead of <Context.Provider value={1}> is also a nice, albeit small, QOL change. Feels like they are really honing down the API. Esp once they kill off useMemo and related hooks with the compiler.
- quasarj 2y ago
  Very nice, something I actually care about!
blastonico 2y ago
I see people complaining a lot about React, why is it? What are the alternatives? PS: I'm not a frontend engineer but I find this topic interesting. Thanks!
- bandrami 2y ago
  Using a scripting or templating language on the server to form and send HTML and CSS to the client as $DEITY intended
  - Muromec 2y ago
    Django is still there and is still better than Phoenix by the way. I didn't really touch it in about 10 years, but ... nothing changed. It's amazing!
    - doodlesdev 2y ago
      > and is still better than Phoenix by the way. What aspects of Django do you think still stand out compared to Phoenix? It seems like a very solid framework, specially with the recent release of Phoenix LiveView 1.0, which seems like a pretty solid approach to frontend. For context, I’ve worked with Django before but didn’t particularly enjoy the experience—not because of the framework itself (its documentation, ORM, and admin tooling are excellent) but because I’m not a fan of Python, particularly its packaging ecosystem and approach to async, which I find lacking. I haven’t used Phoenix or Elixir before, so I’m curious to hear from someone who has experience with both.
      - Muromec 2y ago
        Django is really thought out and polished in terms of devx. Take ORM for example. You write a model and you get out of the box: - migrations to create the model and to apply schema changes; - form validation for crud; - admin with permissions to edit it; - helpers to get model by id or throw 404. Phoenix kinda is in the same market, but you write your migrations yourself, admin panel is a package somebody slapped on top, etc. It’s not that Phoenix isn’t usable, but getting on that level takes time and effort
pixelsort 2y ago
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. 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.
- 0xblinq 2y ago
  +1 I’ve used it in a largeish project and I liked it a lot. I rally hope I never have to deal again with redux or sagas
- babyshake 2y ago
  When I go to Jotai npm docs page (https://www.npmjs.com/package/jotai https://www.npmjs.com/package/jotai) I don't really get the impression of how this helps get away from using a lot of different context providers or Redux. The nice thing about context hooks is they are composable, combined with cached queries you can have a decently maintainable pattern. How does Jotai provide a tangible improvement on this?
  - pixelsort 2y ago
    The benefits would depends on how your code is structured, which dependencies you use, and overall complexity. Contexts provide and elegant developer experience, up until they don't. Have you ever implemented nested SplitView components under Dockview? It can be brutal on contexts. As a developer, I value solutions that never fail me. I wasn't driven to Jotai out of good taste. Simplicity and reliability are the benefits I find the most tangible. But Jotai's atomicity brings renderer optimizations as code splitting advantages that I haven't seen from the flux/redux clones before either.
  - kn8 2y ago
    https://github.com/KidkArolis/kinfolk https://github.com/KidkArolis/kinfolk - recoil/jotai, but simpler
wg0 2y ago
Breaking news - full support for custom elements. Web components that is.
EternalFury 2y ago
Nothing new to what I am going to say and not strictly related to React 19. I once loved client-side frameworks like React. 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. sigh
- norswap 2y ago
  Frontend frameworks really do make things simpler once you go beyond small applications though. Automatically re-rendering when the data/model changes is the right thing to do. We can argue over the specifics for sure, but simply imperatively changing your UI whenever your data changes doesn't scale very far, neither in term of codebase nor in terms of team.
  - taeric 2y ago
    I think there are assumptions here that are not shared? First, there is an implication that the HTTP model is benign in the complications that we see in web applications. I don't think it would take a lot of arguments to bust this? Trying to hide it, also leads to several problems of its own. Second, that the rest of the abstractions in a browser are benign in the complications most people complain about. The DOM, CORS, general document structure, CSS(!), and all of the extra APIs that browsers have added through the years are building on some rather awkward layers. I don't think it is hard to argue that the biggest reason that browsers have had the success and development that they have had, is the privilege that we have given port 80 in the world. Now. I think an area we would have solid agreement on, is that I don't necessarily think we had better options along the way? Bringing this back to frameworks, though, tooling is tough to ignore. The tooling that people used to have in easy application creation is tough to scoff at. I think it is safe to say that Dreamweaver was also not that bad, looking back. We had some odd purity tests on whether or not it should use tables for layout. Hard to really keep that complaint top of mind when I look at the absurd amount of markup that is in so many sites, nowadays.
    - 2y ago
jmull 2y ago
Does react use semantic versioning? I’d hate to have to deal with incompatible versions at the rate they release major versions. 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)? 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.
- acemarke 2y ago
  Yes, React uses semver. React 19 has been in development for over 2+ years - React 18.2 (the last meaningful minor release) came out in June 2022, so the release pace has been slow enough people have complained that it's _too_ slow: - https://macwright.com/2024/01/03/miffed-about-react https://macwright.com/2024/01/03/miffed-about-react (looks like the author may have an HN-specific redirect, so you might need to copy-paste that URL)
- alexanderchr 2y ago
  The numbers are high because they jumped directly from 0.14 to 15.0, but the cadence is not particularly high: 18.0 was released early 2022, 17.0 late 2020 and 16.0 late 2017. That’s three major releases in seven years. React is stable, upgrading it is painless as long as you don’t ignore deprecation warnings. What can be annoying is other (abandoned) dependencies holding you back from upgrading.
  - nox101 2y ago
    upgrading is far from painless. If you're using any 3rd party solutions and they aren't compatible with the latest React you're going to have a bad time.
    - alexanderchr 2y ago
      Yeah, as I said above I don't disagree. The ecosystem has lots of issues but React gets all the hate, unfairly in my opinion. It's a pretty well maintained piece of software.
deleted 2y ago
[deleted]
uhoh-itsmaciek 2y ago
Great to see this--there are some nice features that encourage using standard web technologies like forms, and some solid quality of life improvements. 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. 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. Has anyone explored this side of Suspense? [1]: https://github.com/TanStack/query/blob/main/packages/query-core/src/thenable.ts https://github.com/TanStack/query/blob/main/packages/query-c...
- acemarke 2y ago
  Yeah, _we library maintainers_ are feeling the same way :) - https://bsky.app/profile/acemarke.dev/post/3lcitbmmfss2i https://bsky.app/profile/acemarke.dev/post/3lcitbmmfss2i Big picture as I understand it: The legacy and always-undocumented-but-everyone-knew-about-it approach was throwing a promise while rendering. `use` still actually does the same thing, but it also attaches some extra status fields to that promise, _and_ checks to see if you're consistently passing in the _same_ promise reference. In other words, it's the job of an external data fetching library to keep track of what query entry is being asked for, create and save a promise per cache entry _outside_ of the React component tree, and then return that promise somehow so the app developer can pass it to the `use` hook. In a sense, it's an async `Map`. As another example of this, my former teammate Brian Vaughn (previously on the React core team) ended up building his own implementation of that behavior in the conveniently-named `suspense` package: - https://suspense.vercel.app/ https://suspense.vercel.app/ Ultimately, the `use` hook and Suspense _does_ do exactly what you're asking for - the rest of the component gets to assume the data _does_ exist, since `use` will only let the execution continue once the promise has resolved.
ENGNR 2y ago
Really glad they delayed the release to (hopefully) solve the parallel suspense issue. Haven’t tried it yet but high hopes, and great release overall.
- terandle 2y ago
  They did solve it (from the guy that originally reported the suspense issue): https://bsky.app/profile/tkdodo.eu/post/3layw6wk5bs2b https://bsky.app/profile/tkdodo.eu/post/3layw6wk5bs2b
- bhouston 2y ago
  Yeah, it would have been horrible if they broke React-Three-Fiber, that is one amazing library: https://r3f.docs.pmnd.rs/getting-started/introduction https://r3f.docs.pmnd.rs/getting-started/introduction
preommr 2y ago
Updates like this are exactly why React sucks. 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). 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! 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 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. [0]https://react.dev/blog/2024/12/05/react-19#actions https://react.dev/blog/2024/12/05/react-19#actions
- foretop_yardarm 2y ago
  It would have been a different story if these features had shipped a few years ago but react query is definitely the elephant in the room here.
- wackget 2y ago
  > the old way of doing things is only a few lines more, but is much clearer A description fit for React itself.
sunshinerag 2y ago
[flagged]
- xandrius 2y ago
  Legacy? Is writing pure ASM the modern way now?
  - esperent 2y ago
    There was a dumb hot take blog post here a week or so ago by some wannabe thought leader trying to cast React as "legacy" and meanwhile telling everybody about the "right" way to do frontend. I guess it got through to a few people. To me it felt like reading a tweet that somehow got expanded to 3000 words.
lucsky 2y ago
[flagged]
robertwt7 2y ago
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. 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. 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. 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 :)
- RexFactorem 2y ago
  [dead]
- lakomen 2y ago
  I worked with AngularJS, Angular, Vue, Svelte and now React. I tried React time and again but found it to be too complicated and ineffective. I like Vue best. But lately I have completed a few React projects, because of a graphql package that's only available for React. The current state of React is pretty good IMHO. There are some things you need to get used to, but that's the case in every framework, when in Rome. The SPA side is great, it also ranks well. But the SSR side is awful. Absolute nightmare. And it's moving too fast. Vue is vue and code from v2 even works with v3. React will now stop being easily embeddable without a compilation step.
- lmm 2y ago
  HN has long had a huge anti-Facebook bias, I wonder if it's just that.
deleted 2y ago
[deleted]
rkwz 2y ago
Curious, has anyone tried to use React without bundler like webpack, esbuild etc?
wetpaws 2y ago
[dead]
tuan 2y ago
Is it possible to build useActionState hook based on existing built-in hooks ? If yes, why does that hook have to be built in ?
- bogdan 2y ago
  The same reason useMemo exists
tuan 2y ago
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.
rizky05 2y ago
[dead]
deleted 2y ago
[deleted]

React 19

307 points by gajus 2y ago

deleted 2y ago

[deleted]

deleted 2y ago

[deleted]

deleted 2y ago

[deleted]

gr4vityWall 2y ago

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. Server Components also look fairly complex, and I'm glad I haven't had to deal with them so far. The improved error messages on hydration errors are welcomed. The <Context> as a provider and ref as a prop changes are nice QoL changes. 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. 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.

deleted 2y ago

[deleted]

riffic 2y ago

here's what really matters: https://endoflife.date/react https://endoflife.date/react

captn3m0 2y ago
PRs are welcome to add the new release (and merge all the 18 minor releases).
efields 2y ago
Imagine if HTML5 had an EoL.
- nicce 2y ago
  Some day
mardifoufs 2y ago
React is very backwards compatible, so the eol is much less impactful than for say, vuejs

demarq 2y ago

Awesome release. I feel sorry though for someone getting into frontend dev now. > 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. 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? EDIT: React is still an exceptional framework and this release is certainly an improvement. My criticism is more FE development in general not just React.

ChrisRR 2y ago
> Imagine you decided to start developing websites today, how do you even start I'm an embedded dev so I've so far removed from web dev, but recently started looking into learning web dev for some personal projects. My god what a mess. Any learning resource for a single topic , like javascript, Flask, CSS can't seem to stick to what it's trying to teach and insist that you start importing other libraries and frameworks. Most of the time they're not needed and the author just assumes that you understand this other library in order to continue following their examples So you google how to use that library, but the learning resources assume knowledge of a different library... When all the resources of just plain javascript and plain HTML/CSS. I don't want bootstrap or react, I just want to learn the fundamentals to build upon
azangru 2y ago
> Imagine you decided to start developing websites today, how do you even start? Not with React? Seriously, if you are starting developing websites today, the first thing you need to do is learn the web platform: html, css, javascript (probably typescript as well while you are at it), svg; and some basic server-side stuff. React is for when you get pretty comfy with those.
notapenny 2y ago
> Imagine you decided to start developing websites today, how do you even start? With HTML and CSS. And you don't touch JS until you understand the fundamentals of those. And only after those three do you touch a FE framework. I'm not even kidding either. Whether its React, Angular or any back-end driven templating, those things are all abstractions over fundamentals.

cyral 2y ago

The blog post is an easier read: https://react.dev/blog/2024/12/05/react-19 https://react.dev/blog/2024/12/05/react-19

nailer 2y ago
const error = await updateName(newName); Why would updateName return an error? Why not just throw an Error like JS/TS?
- Mogzol 2y ago
  It's just an example async call, it could be anything. It's not the important part of that code example, it's only purpose is to show that an async call is happening. It could be written as a try/catch, or it could be written how they wrote it. I guess they chose that way because it's short and to the point.
  - nailer 2y ago
    Good example code is otherwise uninteresting apart from the concept that is meant to be shown.
- BillSaysThis 2y ago
  updateName is a call to the backend/server to update the database...
- rtpg 2y ago
  Some guesses: - People really like Result structures - People who wrote the API believe in the "operational issues and business issues should not be comingled" philosophy (so this function might raise on a connection error, but it _won't_ raise when there's simply an error like a name conflict) - People who wrote the example write Too Much(TM) Go

htunnicliff 2y ago

One of the best parts of this release: ref as a prop: Refs can now be used as props, removing the need for forwardRef.

terandle 2y ago
Being able to <Context value={1}> instead of <Context.Provider value={1}> is also a nice, albeit small, QOL change. Feels like they are really honing down the API. Esp once they kill off useMemo and related hooks with the compiler.
quasarj 2y ago
Very nice, something I actually care about!

blastonico 2y ago

I see people complaining a lot about React, why is it? What are the alternatives? PS: I'm not a frontend engineer but I find this topic interesting. Thanks!

bandrami 2y ago
Using a scripting or templating language on the server to form and send HTML and CSS to the client as $DEITY intended
- Muromec 2y ago
  Django is still there and is still better than Phoenix by the way. I didn't really touch it in about 10 years, but ... nothing changed. It's amazing!
  - doodlesdev 2y ago
    > and is still better than Phoenix by the way. What aspects of Django do you think still stand out compared to Phoenix? It seems like a very solid framework, specially with the recent release of Phoenix LiveView 1.0, which seems like a pretty solid approach to frontend. For context, I’ve worked with Django before but didn’t particularly enjoy the experience—not because of the framework itself (its documentation, ORM, and admin tooling are excellent) but because I’m not a fan of Python, particularly its packaging ecosystem and approach to async, which I find lacking. I haven’t used Phoenix or Elixir before, so I’m curious to hear from someone who has experience with both.
    - Muromec 2y ago
      Django is really thought out and polished in terms of devx. Take ORM for example. You write a model and you get out of the box: - migrations to create the model and to apply schema changes; - form validation for crud; - admin with permissions to edit it; - helpers to get model by id or throw 404. Phoenix kinda is in the same market, but you write your migrations yourself, admin panel is a package somebody slapped on top, etc. It’s not that Phoenix isn’t usable, but getting on that level takes time and effort

pixelsort 2y ago

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

0xblinq 2y ago
+1 I’ve used it in a largeish project and I liked it a lot. I rally hope I never have to deal again with redux or sagas
babyshake 2y ago
When I go to Jotai npm docs page (https://www.npmjs.com/package/jotai https://www.npmjs.com/package/jotai) I don't really get the impression of how this helps get away from using a lot of different context providers or Redux. The nice thing about context hooks is they are composable, combined with cached queries you can have a decently maintainable pattern. How does Jotai provide a tangible improvement on this?
- pixelsort 2y ago
  The benefits would depends on how your code is structured, which dependencies you use, and overall complexity. Contexts provide and elegant developer experience, up until they don't. Have you ever implemented nested SplitView components under Dockview? It can be brutal on contexts. As a developer, I value solutions that never fail me. I wasn't driven to Jotai out of good taste. Simplicity and reliability are the benefits I find the most tangible. But Jotai's atomicity brings renderer optimizations as code splitting advantages that I haven't seen from the flux/redux clones before either.
- kn8 2y ago
  https://github.com/KidkArolis/kinfolk https://github.com/KidkArolis/kinfolk - recoil/jotai, but simpler

wg0 2y ago

Breaking news - full support for custom elements. Web components that is.

EternalFury 2y ago

Nothing new to what I am going to say and not strictly related to React 19. I once loved client-side frameworks like React. 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. sigh

norswap 2y ago
Frontend frameworks really do make things simpler once you go beyond small applications though. Automatically re-rendering when the data/model changes is the right thing to do. We can argue over the specifics for sure, but simply imperatively changing your UI whenever your data changes doesn't scale very far, neither in term of codebase nor in terms of team.
- taeric 2y ago
  I think there are assumptions here that are not shared? First, there is an implication that the HTTP model is benign in the complications that we see in web applications. I don't think it would take a lot of arguments to bust this? Trying to hide it, also leads to several problems of its own. Second, that the rest of the abstractions in a browser are benign in the complications most people complain about. The DOM, CORS, general document structure, CSS(!), and all of the extra APIs that browsers have added through the years are building on some rather awkward layers. I don't think it is hard to argue that the biggest reason that browsers have had the success and development that they have had, is the privilege that we have given port 80 in the world. Now. I think an area we would have solid agreement on, is that I don't necessarily think we had better options along the way? Bringing this back to frameworks, though, tooling is tough to ignore. The tooling that people used to have in easy application creation is tough to scoff at. I think it is safe to say that Dreamweaver was also not that bad, looking back. We had some odd purity tests on whether or not it should use tables for layout. Hard to really keep that complaint top of mind when I look at the absurd amount of markup that is in so many sites, nowadays.
  - 2y ago

jmull 2y ago

Does react use semantic versioning? I’d hate to have to deal with incompatible versions at the rate they release major versions. 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)? 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.

acemarke 2y ago
Yes, React uses semver. React 19 has been in development for over 2+ years - React 18.2 (the last meaningful minor release) came out in June 2022, so the release pace has been slow enough people have complained that it's _too_ slow: - https://macwright.com/2024/01/03/miffed-about-react https://macwright.com/2024/01/03/miffed-about-react (looks like the author may have an HN-specific redirect, so you might need to copy-paste that URL)
alexanderchr 2y ago
The numbers are high because they jumped directly from 0.14 to 15.0, but the cadence is not particularly high: 18.0 was released early 2022, 17.0 late 2020 and 16.0 late 2017. That’s three major releases in seven years. React is stable, upgrading it is painless as long as you don’t ignore deprecation warnings. What can be annoying is other (abandoned) dependencies holding you back from upgrading.
- nox101 2y ago
  upgrading is far from painless. If you're using any 3rd party solutions and they aren't compatible with the latest React you're going to have a bad time.
  - alexanderchr 2y ago
    Yeah, as I said above I don't disagree. The ecosystem has lots of issues but React gets all the hate, unfairly in my opinion. It's a pretty well maintained piece of software.

deleted 2y ago

[deleted]

uhoh-itsmaciek 2y ago

Great to see this--there are some nice features that encourage using standard web technologies like forms, and some solid quality of life improvements. 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. 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. Has anyone explored this side of Suspense? [1]: https://github.com/TanStack/query/blob/main/packages/query-core/src/thenable.ts https://github.com/TanStack/query/blob/main/packages/query-c...

acemarke 2y ago
Yeah, _we library maintainers_ are feeling the same way :) - https://bsky.app/profile/acemarke.dev/post/3lcitbmmfss2i https://bsky.app/profile/acemarke.dev/post/3lcitbmmfss2i Big picture as I understand it: The legacy and always-undocumented-but-everyone-knew-about-it approach was throwing a promise while rendering. `use` still actually does the same thing, but it also attaches some extra status fields to that promise, _and_ checks to see if you're consistently passing in the _same_ promise reference. In other words, it's the job of an external data fetching library to keep track of what query entry is being asked for, create and save a promise per cache entry _outside_ of the React component tree, and then return that promise somehow so the app developer can pass it to the `use` hook. In a sense, it's an async `Map`. As another example of this, my former teammate Brian Vaughn (previously on the React core team) ended up building his own implementation of that behavior in the conveniently-named `suspense` package: - https://suspense.vercel.app/ https://suspense.vercel.app/ Ultimately, the `use` hook and Suspense _does_ do exactly what you're asking for - the rest of the component gets to assume the data _does_ exist, since `use` will only let the execution continue once the promise has resolved.

ENGNR 2y ago

Really glad they delayed the release to (hopefully) solve the parallel suspense issue. Haven’t tried it yet but high hopes, and great release overall.

terandle 2y ago
They did solve it (from the guy that originally reported the suspense issue): https://bsky.app/profile/tkdodo.eu/post/3layw6wk5bs2b https://bsky.app/profile/tkdodo.eu/post/3layw6wk5bs2b
bhouston 2y ago
Yeah, it would have been horrible if they broke React-Three-Fiber, that is one amazing library: https://r3f.docs.pmnd.rs/getting-started/introduction https://r3f.docs.pmnd.rs/getting-started/introduction

preommr 2y ago

Updates like this are exactly why React sucks. 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). 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! 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 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. [0]https://react.dev/blog/2024/12/05/react-19#actions https://react.dev/blog/2024/12/05/react-19#actions

foretop_yardarm 2y ago
It would have been a different story if these features had shipped a few years ago but react query is definitely the elephant in the room here.
wackget 2y ago
> the old way of doing things is only a few lines more, but is much clearer A description fit for React itself.

sunshinerag 2y ago

[flagged]

xandrius 2y ago
Legacy? Is writing pure ASM the modern way now?
- esperent 2y ago
  There was a dumb hot take blog post here a week or so ago by some wannabe thought leader trying to cast React as "legacy" and meanwhile telling everybody about the "right" way to do frontend. I guess it got through to a few people. To me it felt like reading a tweet that somehow got expanded to 3000 words.

lucsky 2y ago

[flagged]

robertwt7 2y ago

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

RexFactorem 2y ago
[dead]
lakomen 2y ago
I worked with AngularJS, Angular, Vue, Svelte and now React. I tried React time and again but found it to be too complicated and ineffective. I like Vue best. But lately I have completed a few React projects, because of a graphql package that's only available for React. The current state of React is pretty good IMHO. There are some things you need to get used to, but that's the case in every framework, when in Rome. The SPA side is great, it also ranks well. But the SSR side is awful. Absolute nightmare. And it's moving too fast. Vue is vue and code from v2 even works with v3. React will now stop being easily embeddable without a compilation step.
lmm 2y ago
HN has long had a huge anti-Facebook bias, I wonder if it's just that.

deleted 2y ago

[deleted]

rkwz 2y ago

Curious, has anyone tried to use React without bundler like webpack, esbuild etc?

wetpaws 2y ago

[dead]

tuan 2y ago

Is it possible to build useActionState hook based on existing built-in hooks ? If yes, why does that hook have to be built in ?

bogdan 2y ago
The same reason useMemo exists

tuan 2y ago

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.

rizky05 2y ago

[dead]

deleted 2y ago

[deleted]