7 ms·
React 19 Breaks Async Composability
- sensanaty 2y agoAs a React dev at $DAYJOB, how React remains at the top despite the existence of infinitely better alternatives like Vue or Svelte will forever be baffling to me
- shepherdjerred 2y agoWhat do you like about Vue? I use Vue at work and yearn for React (though, I haven't written much React since the shift to hooks).
- sensanaty 2y agoThe biggest one to me is the lack of reactivity footguns. Vue will just handle reactivity for you, with no weird gotchas, and it will work 99% of the time without any performance penalties. You can just push/pop items to/from a reactive array, and Vue will just handle that for you. You never have to worry about weird double-render issues, and memoization is done by the framework automatically and intelligently. There are some edge cases, like Maps and Sets where you don't get reactivity out of Vue which is unfortunate, but in the large majority of usecases it's dead simple. Other than that, at least for myself Vue's mental model makes more sense with the event bubbling. You don't have to drill down 20 different methods to change a piece of state, you just rely on the children firing an event and then you just change the state straight from the parent, it feels like a natural extension to native browser events.
- shepherdjerred 2y agoSorry, I didn't see this 'til now. I am astounded that you haven't had reactivity issues. With Vue 3 + the composition API I've found the reactivity to be much more difficult to understand than React.
- nikanj 2y agoI find it fascinating how frequently the best practices change, and how dogmatically people still want to follow best practices. As an industry, we spend absolutely incredible amounts of work refactoring working code into the new paradigm.
- ibash 2y agoClass components was the last good react idea.
- teitoklien 2y agoFunctional Components are 10x easier and cleaner to use in React
- akritrime 2y agoYou could already use functional components before. The main issue with React now is all these hooks and effects.
- crooked-v 2y agoThe whole point of hooks is to substantially simplify "effects stuff", as compared to the total uncomposability of class components. While the specific implementation of hooks has its bugbears, I think it's pretty telling that nobody else is using class components either, even in projects with fundamentally different engines like Svelte.
- azangru 2y ago> as compared to the total uncomposability of class components How do you mean? React components were composable from the get-go; this is practically the definition of a component: you take a piece of ui, you encapsulate it in a component, and then you can compose it with other components into more complex UIs. Class components were reacting to component's life cycle as opposed to hooks that react to data changes; but there was nothing stopping you from extracting reusable pieces of logic into standalone functions and using them in lifecycle methods. I thought the whole point of hooks was to support the React fiber architecture, because closures are immutable as opposed to class fields.
- jenadine 2y agoWhat does that mean? (for someone not familiar with React)
- orangepanda 2y agoNothing functional breaks because of this. Waterfall requests, which already had bad ux, have worse ux now.
- crooked-v 2y agoIt makes anything that does lazy loading in parallel noticeably worse by forcing waterfall-only loading, in order to make rendering and management of loading states slightly better.
- anonzzzies 2y agoTerrible shitshow. Web dev is all broken and horrible. Well at least the popular stuff is. No idea why anyone uses this outside resume building.
- wordofx 2y agoHTMX is the way forward.
- mrkeen 2y agoIs that a document markup language? Maybe backend programming will become a lot simpler and easier and once they release XML2.
- Akronymus 2y agoIt's essentially a small extension of HTML via JS, that allows all elements to fetch HTML from a server on events, and replace a target elements inner/outer html/append to it. From their page [1]: motivation Why should only <a> & <form> be able to make HTTP requests? Why should only click & submit events trigger them? Why should only GET & POST methods be available? Why should you only be able to replace the entire screen? By removing these constraints, htmx completes HTML as a hypertext [1] https://htmx.org/ https://htmx.org/
- FriedrichN 2y agoNothing is the way forward. It's programming, we make stuff that does stuff. Preferably with stuff that makes making stuff that does stuff easier and with stuff that will be supported for a long time. Maybe I'm too cynical, but whenever something is presented as some messianistic "way forward" I just think "ah yes, another way forward" but feel we're mostly moving laterally.
- ht85 2y agoIt is exactly that. We make stuff, problems arise, we make new stuff that does not suffer from said problems. Because everything is a trade-off, new stuff creates new problems. Those are the problems complainers complain about, ignorant of their history. The cycle then repeats. Maybe I am not cynical enough but doing easy things from the past is completely trivial and doing unimaginable things from the past is not that hard anymore. Looks like the cycle has some forward momentum in the end!
- mrkeen 2y ago> when navigating to a new screen, it's better to show a loading state as soon as you can (often a skeleton UI), rather than delay the transition. In a better language, this would be the programmers choice on a case-by-case basis, with no need for the higher-ups to break or fix everyone's behaviour at once. Either return a Page(Future(Components)) or a Future(Page(Components)).
- tomgp 2y ago"Navigating to a new screen" is such a basic behaviour of the web the idea that we need to rely on a framework to manage this in some way is absolutely insane. At this point the complexity that React imposes on developers is out of all proportion to the benefits that it provides. Yes there are cases where React is exactly what's needed but when each new version introduces new "best practices" based on how "bullish" Meta's developers feel about a given approach it removes a crucial advantage that helped these libraries become popular i.e. that it's easy to onboard new people on to a project because thewre's a consistent approach across code bases. Right now there's not a consistent approach across 2 or 3 years of React releases and that's before we come to the torrent of metaframeowrks designed to smooth over inconsitencies and deficiencies (state managment! styling!). I don't know what the answer to this is but having spent a good portion of the last 7 years or so on and off React projects I would advise anyone to think carefully before investing time and /or money in the ecosystem. On balance the benefits aren't worth it the large majority of cases. note: i've used library and framework carelessly and interchangably here, React has historically been keen to market itself as a library i.e. something you dip into when needed but in practice it bends the whole dev process around it so I feel framework is more apt
- Varriount 2y agoOr better yet, just... Navigate to a new (real) web page? Maybe passing some state via URL parameters? At least then the back button has a reasonable chance of working correctly.
- mrkeen 2y agoI believe I was only talking about a single page load. Instead of a choice between progressively loading in /page-a or waiting for /page-a to fully load before showing it, just direct the user to /page-b instead?
- EugeneOZ 2y agois it something similar to Deferable Views in Angular? https://angular.dev/guide/defer#overview https://angular.dev/guide/defer#overview
- sergioisidoro 2y agoFrom the discussion: > My favorite way to do data fetching is as close to the place where I am using the data. React made it possible up until this change. Well, yes, but we are nowadays in a situation where every component interacts directly with the state, or makes calls to the API (eg with the overuse of query), going against one of the architecture principles of react. It's like we're not building components, we're building component sized micro-ui.
- danfritz 2y agoHa great we finally arrive at the "Next.js React features" which basically forces everyone to use Next.js or an additional framework on top of React which now have to play catchup with whatever react - next.js think is "best" (for Vercels wallet). Expected outcome if half or the react core team is a Vercel employee. Kinda new this day was coming, sad to see it actually happen
- meiraleal 2y agoI'm not sure yet if I'm happy or sad with Vercel's destruction of React. After 10 years of React, I think imploding it from inside was the only way React could lose its lead. They achieved it! Even tho we don't have a clear alternative yet.
- joquarky 2y agoI'm old, but I still think that knockout.js is the bee's knees.
- dudus 2y agoSvelte and solid are nice alternatives.
- azemetre 2y agoSince Vercel is doing this to React why would we think they wouldn’t also do this to Svelte? Maybe I should check out Vue again, there’s something to be said about open source libraries that succeed without corporate ownership.
- yencabulator 2y agoSvelte has a seamless SSR framework called SvelteKit that is platform-agnostic and made by the same people who make Svelte in the first place.
- azemetre 2y ago
- azangru 2y agoI thought these two short video demos by Ryan Florence of how this problem is mitigated in the upcoming react router 7 would be relevant for this topic. - https://x.com/ryanflorence/status/1801383836250739057 https://x.com/ryanflorence/status/1801383836250739057 - https://x.com/ryanflorence/status/1801388170891903252 https://x.com/ryanflorence/status/1801388170891903252
- SebastianKra 2y agoThis looks nice for a single query, but, like basically all the previous discussion around this, he skips over the case where you might need to kickoff fetching of dependent data. So in your loader, you would have to fetch the data, transform it, extract a key for the second query and then prefetch that. ...and in your component you would have to do the exact thing again, except you probably have to write the transformation logic twice, because hooks don't compose well with promises. Of course you might say that dependent queries are a bad practice anyways, but in the real world this happens quite a lot. To be clear, Suspense was always bad at this. To my knowledge, there was never a good way to combine SWR and lazy fetching with Suspense. You may or may not have been lucky, if your queries mapped well to the component tree. I would like to see a solution from either React-Router or Tanstack-Query, but both of them prefer discussing the problem away.
- ddaalluu2 2y agoTheir solution is graphql, but I believe that the backend should have data for each component ready. Example social network. /api/pagedata/FrontPage returns a big ass query result, all posts with comments, comment count and reactions, all the data you would ever want in your front page. /api/pagedata/UserProfilePage returns all the relevant data regarding the user's profile page. Yes, if you change or extend a certain page, you will have to change the backend query. If you have 2 different teams for frontend and backend that's not straightforward, so there should be something where the frontend team writes the detailed expected json response and the backend team transforms that into queries. Or, let's be real, the queries get generated. One could even imagine a middleware that translates expected json to graphql queries. Why not directly graphql? Because it's a major pain in the ass, because of relay. Graphql is Facebook. And instead of having the simple structure you can easily query, they added this stupid node relay structure which makes everything overly complicated. I could imagine a Go backend or Rust where you have a comment with the expected JSON, and you type go generate and boom generated queries with search and pagination.
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]