React 19 Breaks Async Composability
github.comHa 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
I'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.
I'm old, but I still think that knockout.js is the bee's knees.
Svelte and solid are nice alternatives.
I tried svelte but it is not it too. I'm happy with Lit tho, have no plans to change with all the Web Components interop. With React 19 I can ship most components in Lit and create a React shell and everybody is happy, me and my customers.
Since 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.
Svelte has a seamless SSR framework called SvelteKit that is platform-agnostic and made by the same people who make Svelte in the first place.
Yes but the issue is that Vercel has all the core Svelte maintainers on their payroll too. My Q is why would we expect Vercel to not interject as well? I mean we have evidence they did this in one community library, why not another? That is the risk.
Talking about that, Vercel suddenly ejected many open source projects they "sponsored".
Svelte has a pretty prominent BDFL, having to corrupt him first might be enough.
Personally, I think the moment SvelteKit stops working on plain container images & Cloudflare Workers is the moment Svelte dies.
This simply isn't going to happen.
Thanks for the work you put into the Svelte platform, competition helps keep ecosystems more honest
Just in case it wasn't clear: I mean this might be enough to prevent bad things from happening.
For sure — just wanted to be totally explicit that SvelteKit will always be platform agnostic
> Svelte has a pretty prominent BDFL, having to corrupt him first might be enough.
I don't know him personally, but the power dynamics is clear: one person vs a corporation is often just one attractive offer away from significant changes
This is why I'm sad about Svelte core being maintained by Vercel employees as well. They have definitely positioned themselves well to be in control of a lot of modern web development and deployment, but it makes me not want to use Svelte, SvelteKit, React, or Next.
Vue is the only main independent framework that exists now, apart from jQuery.
> 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)).
"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
Or 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.
It's not hard to get perfect back button behavior with SPAs. You just have to care enough to do it _and_ have written code decent enough that it can be shimmed in.
I 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?
I 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.
It's insane how toxic the js environment is. it seems like if a project is over 6 months old, nothing will work. When I yarn install on an old project, i'm rolling the dice. I had a 2 year old next.js side project i was working on and the amount of work to make it work the latest version with just updating the dependencies and reading the upgrade docs were infinitely more complex than just starting over from scratch.
no thanks. I will stick with Rails.
The funny thing is that they eventually circled back to server-side rendering. It just has a cool TLA now.
React's server components is pretty fundamentally different from how something like Rails or old-school PHP does "server-side rendering".
It's a lot closer in spirit to something like Phoenix LiveWire.
Just the fact that Yarn seems to be the dominant package manager now when it seems like last week it was npm. What will it be next week?
I truly wonder, do people use this stuff for software that is expected to be maintained for 5-10 years? I feel that with the speed at which everything changes, gets deprecated, discontinued, succeeded, etc. you'll spend a good chunk of your time staying up to date with the current js ecosystem. That doesn't seem very economic to me.
Naw it's back to npm
Pnpm ? Seems every week another flavour without any benefits.
PNPM isn't exactly new; it's been in development since 2016[0] (which makes it 9 years old).
I've been using it for quite a while now. It has excellent mono-repo features, pnpmfile.js hooks, and it's just downright faster than NPM. Way, way faster.
I switched to it a couple of years ago, and it was definitely a breath of fresh air: no more waiting for 5 minutes for dependencies to install! I still find this to be the case when the odd create-XXX-app script finds itself using NPM.
[0]: https://github.com/pnpm/pnpm/commits/main/?after=5d1ed94e6c4...
pnpm has some advantages
I have used yarn since 2018. It was developed in 2016.
What does dominant even mean in such a short term context? It hasn’t even been 10 years.
As far as companies go, we move so slowly that when someone brings up a tech fad, the fad is gone by the time the committee actually gets to decide. So we stick with the status quo.
Basically npm fell heavily behind in development so people switched to yarn; it's back to npm now. This is over a timescale of 10 years or so.
I'm one of "those".
I'm using bun now, but I was on pnpm for a while.
To be fair to React itself, it evolves quite slowly and cautiously. It is almost the same now as it was in 2019. But the closer your stack is to the native browser apis, the more robust and long-living it will be, which is why I have faith in Lit.
Likely you are changing your node version during that 6 months. Similar to ruby with RVM, node has NVM. I create an .nvmrc file denoting the desired node version, and it works reliably all the time.
To be fair I’ve had similar issues with Rails
In that regard, my experience has been the following churn scale:
JavaScript churns more than Rails which churns more than Elixir/Phoenix.
I believe this is caused by “how sound the fundamentals are” (technical debt in the language itself and its stdlib).
PHP devs meanwhile: You guys churn?
For better or worse, you can take 10+ years old PHP code and it'll mostly just work.
I wrote a bookmark manager in 2005-ish using security-conscious PHP, and it still works great.
I rewrote it in React for fun and not only is it totally out of date, but Github's dependabot has sent me probably 200+ security advisories based on its dependencies.
My handcrafted legacy.c64g.com site made in 2005 still works with php8.3 (I see I have to renew the cert). I just had to switch from mysql to mysqli. However my Symfony sites had to be rewritten. Friends don't let friends code using Symfony. There was no upgrade path. Deprecated components with no replacement. I was so fed up with all the bullshit from 2010-2013 with the OO fetishism the "treat PHP like it's Java" from fresh students and graduates that I had to abandon it and switch to Go, which gave me peace of mind and a factor 100 performance boost.
I maintain a PHP codebase that dates back 15 years and I can count the breaking changes on one hand, and they were all tiny one-line changes
The backward incompatibility story https://www.php.net/manual/en/migration70.incompatible.php is not empty
In 10+ years of professional PHP development, the only time I've ever had to fix a codebase while updating the PHP version was when mcrypt was deprecated, and it was only around half an hour of work to replace it with a modern equivalent, including the time to re-encrypt the data.
Meanwhile, I've had the misfortune of inheriting a React application that would no longer build a mere six months after the original developer left the company. I've come to loath working on React projects due to the insane amount of library and tooling churn in that ecosystem.
Not contesting anything related to churn and JavaScript, my experience has been similar.
Glad to hear those changes did not impact you re PHP
That was in 2015, and it barely impacted anything I touched. So, granted, technically not quite 10+ years, but you get worse churn in JS frameworks over an 8 months period. (Unless it's jquery.)
That's not it. The core issue is AAA sites vs apps. Let me explain.
Public sites need to load quickly and use progressive enhancement, work without JavaScript even. Next.js is driving this with server side rendering and hybrid approaches. They've done a great job so far.
Then there are applications that have a browser UI. These typically use a JSON-based API (REST, RPC, or GraphQL doesn't matter). These apps don't require server side rendering and their API backend can be anything.
In the latter model, you just host a bunch of static assets and point them to your API. No need for compute, everything is done client side (except API operations of course).
In the first model, you need to pay for rendering and it guides you into doing the API the same way. Closer to older PHP/ASP sites but on steroids.
This move caters to Next.js. IMO, as a lot of recent developments do.
The issue really rears its head when we consider that most are in the second category but "modern" frameworks like Next.JS don't really cater to that market.
I used React for a long time to build frontends for my REST APIs. When I started, CRA was the standard to get started with. CRA got deprecated and I wanted to shift to Next.JS since that seems to be a little more full-stack and I wanted built-in routing instead of relying on react-router. Once I got going on Next.JS everything turned out to be connected to Vercel. Even the tutorial at one stage expects you to sign up for a Vercel account. This really turned me off of React because there doesn't appear to be a single framework for people who want to build the latter category of web apps without either a) tying together multiple disparate modules/libs or b) signing up with 1 framework with 1 vendor. Either option doesn't appeal to me.
I shifted over to Angular (despite everything) because it seems to have finally stabilized and has a pretty good feature set for what I'm looking for. Plus build times on Amplify have really come down. Build times for similar sized apps take around 4 minutes(!) for React applications and routinely under and about 1 minute for Angular applications. I honestly just want a frontend framework where I can build a foundation fairly quickly and just get on with building features instead of worrying about if dependencies have suddenly been sunset or if the author made some breaking change to some key library I don't even interact with directly and right now this is Angular.
> want a frontend framework where I can build a foundation fairly quickly
Vue with Quasar has been that for me. And previously Vuex-orm, now Pinia-orm. With a RESTful backend.
However lately I've been using React because of a graphql backend (I hate graphql) and it's a relay type graphql and the frontend relay library only works with React.
React itself is pretty easy to pick up. But Relay is a pain in the ass. Fragments, @arguments, @argumentsdefinitions, the naming is a super pain in the ass. And it's even more of a pain with Typescript and doesn't work with Javascript. Reusing queries is not possible because of the naming requirements. You can't just have a PostFragment, no you need to have a MainPagePostsFragment and a ProfilePagePostFragment and a PostDetailPagePostFragment etc. But I digress.
React has been surprisingly cute so far. But I've also just been with it for 1 version only, 18. I could imagine switching to it because of the ecosystem and because most frontend jobs are React jobs. You can easily embed it into for instance static HTML files, unlike Angular or Vue, keyword easily.
Angular syntax is beautiful, but the framework is too time consuming. I have recreated a real-time forum, which took about 3 years to build with Angular in 2 weeks with Vue.
Bottom line, Vue, for me, is the most productive framework. Angular, Vue and React are all very similar. Svelte is a bit alien, because of its state management and kit being the nextjs equivalent, but apparently the fastest because of the compiler.
I had the same issues with rails, although that’s a while ago; not sure if it improved.
I've adopted the practice of avoiding libraries with major version > ~3. If you needed to re-design your API so many times, I don't trust your judgement enough to build on top of it.
That said, I still use React and... it's at 19.x :'(
React jumped from v0.14 to v15.0, so in reality it's more like major version 4.3 right now.
Ah, cool, didn't know - joined the train late.
Yeah but that's not just a React issue. It's even worse for Angular, but Vue's transition from v2 to v3 was pretty smooth because of backward compatibility. Svelte has no supported way to create a SPA anymore, you'd have to use Vite for that. It's SSR like next.js. Terrible.
But Angular is the worst in terms of backward compatibility and it has the worst state management too. It's like they took everything bad from React and made it a standard.
I have a harsher take, 95% where react is used it is used without the need.
The minimum technology required to solve a problem isn't always the same technology that a team has experience with, has existing projects/code in, can readily hire for, etc. Nor is it necessarily the same technology capable of solving future problems. Besides, some people just like the mental model of some tools and enjoy working in that way. The idea that we have to pick the minimum tooling every single time usually seems like flawed thinking based on that out-of-context Tim Berners-Lee quote.
Prior to React, most developers just invented a strategy for structuring code on the client side. What’s your preferred alternative?
React isn't a way of structuring code though. It's a whole (huge) framework dedicating to making web apps/pages. And most of the time it seems to be used to replicate functionality that the browser can already natively do (for example, navigating to another page).
You want a good example of how a non-react website and its code might be structured, look at GitHub. At least from a user perspective, I've never had a problem using the back button or ctrl-clicking links while navigating GitHub - which is not something I can say of most other React and heavy-js websites.
>replicate functionality that the browser can already natively do
That's.. basically every lib. Welcome to abstractions.
This used to be confined to web dev, and my backend job was happily tinkering away at 15+ year old code written in stable languages and frameworks, deployed via RPM/Puppet. But we took on too many graduates and now suddenly everything is being rewritten in new languages and we have an insane amount of Kubernetes config attached to everything.
Class components was the last good react idea.
I miss class components!
(I know we _can_ use them still but it's hard to convince teams of people to stick with them and ignore what the docs say are best practices for the last five years.)
Functional Components are 10x easier and cleaner to use in React
Functional Components are not functional in the sense of functional programming. They are shared mutable state.
Function-based components. They have vaguely functional aspects but they are not functional indeed. I think most people say functional because "function-based" is too long.
If I recall correctly we have stateless functional components (not managing any state). Functional in React should mean immutable state.
You could already use functional components before. The main issue with React now is all these hooks and effects.
The 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.
> 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.
Hooks make it easy to compose logic and effects. The actual implementation has some serious warts but the fundamental idea is great.
The React compiler looks like it will eliminate a lot of the error prone manual dependency tracking that usually trips people up with hooks.
I didn't like hooks from the get go because it was the first time I found the automagical behavior that web dev was somewhat leaving behind starting to creep back in.
It's insanely hard (nigh impossible?) to debug an aging app that has use useEffect's and useState's everywhere. (This wasn't the case with the class components (not suggesting that class components were the be and end all))
Now the Compiler sounds nice, and sure there is going to be a lot less code. But, at what cost, it does sound like it's just more magic, moved further and further into the React internals. Which I think unfortunately gives the developer less understanding and power.
I'm just ranting, it's not like the React lib itself is yet entirely divorced from it's principles circa half a decade ago, but I fear it may. Perhaps, they could promote and support more sub packages of React itself e.g. rendering, state
I've seen a lot of JS frameworks come and go. Eventually they all become hard to work with as complexity accretes to address more use cases and keep performance up. The same is true of native frameworks. SwiftUI and Compose are great when you're just getting started but as soon as you start building complex apps things get hairy fast.
I think we still just haven't figured out how to build a UI toolkit that is both highly expressive to use and performant for complex UIs.
I think there are some really great ideas in hooks but it might take a new language built around them to make them truly ergonomic. The React compiler is a step in that direction.
"move fast and break things" as zuckerborg himself said
most of the js ecosystem is made of stream of consciousness kludge that is constantly being "refactored" and "deprecated"
effing tiresome as hell dealing with that sh-t...and this mentality seems to have seeped entirely into nu-dev as i see it also in other ecos now
And just what does a former PHP dev know about anything
Terrible shitshow. Web dev is all broken and horrible. Well at least the popular stuff is. No idea why anyone uses this outside resume building.
Fortunately it is very easy to opt out of all of this. Nothing stops you from having a backed deliver HTML and then sprinkle some basic JS and CSS on top. In theory at least, in practice everybody's brain has been smashed to bits by repeatedly colliding with the hype train. But the old approaches still work, even better than in the old days (thanks to improvements to all the relevant standards).
Well yes, but people do write for resumes, not for anything else. For quality we would live in another world.
Yep. And there's also Phoenix, Rails, and Htmx.
It's a jobs program. Maximize breakage and churn for everyone while disrespecting compatibility and stability.
There’s hope.
Vanilla js with type annotations via jsdoc and a build less setup works amazingly well now.
I’m rebuilding our companies data viz with this set up as the “glue” between apis and charts.
Throw in web components and for some use cases I think you really don’t need react, etc.
HTMX is the way forward.
Nothing 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.
It 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!
React since 17 feels like coding with LLMs: it had a bug, they asked ChatGPT to fix it, it addes more bugs, they asked ChatGPT to fix all of them and now we have a useless piece of software completely unrelated with the initial solution
But it all suffers. We have been doing web dev for 30 years and it all works fine, fast and scalable. I am not sure what other people are so obsessed with but we don’t have these issues.
So if we use stuff to make stuff easier why are people still trying to bang nails in with a piece of glass by using react when easy was using html/css/js made easier with htmx?
Well call me a heathen, but I've never even considered React. Instead I always generate HTML server side and spruce it up using a little JavaScript if necessary (I even use jQuery sometimes). It's reliable, works fast, easy to debug, requires little maintenance, doesn't require a build chain of >100K files of several hundreds of megabytes.
Of course I'm open to the possibility that I'm Doing It Wrong™.
This is just hype, just like with React years ago. There is no "one true way forward"
Besides, HTMX is just HTML with JS on top which devs have been doing for literally 20 years. Rails had that kind of functionality in 2005 because I remember using it.
Yeah. We built junk like react because browsers sucked. Compute was expensive. We pushed processing to the client so someone else could pay for it.
Now we have gone full circle back to building web apps using something like htmx and no longer have a complicated mess to deal with. Render html on the server. Push it to the client.
If you want to reduce maintenance costs, yes. Javascript is a shitshow of constant breaking changes left and right, whether it is in your runtime framework, or your build system like gulp or more prominently webpack. Try maintaining 10 projects with these frameworks. You'll quickly look for something that is not as maintenance intensive.
No, you can't stay on Webpack version X, because (real example) it turned out that version of webpack relied on md5 which wouldn't work in newer node.js versions.
Is that a document markup language?
Maybe backend programming will become a lot simpler and easier and once they release XML2.
It'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
By removing these constraints, htmx completes HTML as a hypertextWhy 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?
No it's not
From 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.
As 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
What 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).
The 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.
Sorry, 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.
I 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.
This 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.
Their solution is graphql, but I believe that the backend should have data for each component ready.
Example social network.
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/FrontPage
returns all the relevant data regarding the user's profile page./api/pagedata/UserProfilePageYes, 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.
I don't know who decided it was right to flag you into oblivion, but GraphQL is unrelated to this.
You don't always have full control over the backend. You may depend on another team, or maybe even access a public API. React was (and still is) good at that, but with suspense, it's as if they forgot that a Web-App may want to do more than just "take stuff from server and show".
What does that mean? (for someone not familiar with React)
Nothing functional breaks because of this. Waterfall requests, which already had bad ux, have worse ux now.
It 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.
What does 'rendering' mean in non javascript terms?
I have a feeling it means 'generate html' in english.
Recursively expanding components until you end up with nothing but HTML.
I hate tech hyperbolizing...
is it something similar to Deferable Views in Angular? https://angular.dev/guide/defer#overview