React 19 Breaks Async Composability(github.com) |
React 19 Breaks Async Composability(github.com) |
Kinda new this day was coming, sad to see it actually happen
Even tho we don't have a clear alternative yet.
Vue is the only main independent framework that exists now, apart from jQuery.
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)).
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
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?
> 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.
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.
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.
Example social network.
/api/pagedata/FrontPage
/api/pagedata/UserProfilePage
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.
I have a feeling it means 'generate html' in english.
no thanks. I will stick with Rails.
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.
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.
That said, I still use React and... it's at 19.x :'(
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 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.)
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
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.
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.
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.
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.
Maybe backend programming will become a lot simpler and easier and once they release XML2.
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.
It's a lot closer in spirit to something like Phoenix LiveWire.
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".
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?
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.
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.
That's.. basically every lib. Welcome to abstractions.
Maybe I should check out Vue again, there’s something to be said about open source libraries that succeed without corporate ownership.
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.
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'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...
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.
I'm using bun now, but I was on pnpm for a while.
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).
For better or worse, you can take 10+ years old PHP code and it'll mostly just work.
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.
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!
Of course I'm open to the possibility that I'm Doing It Wrong™.
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.
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.
The React compiler looks like it will eliminate a lot of the error prone manual dependency tracking that usually trips people up with hooks.
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.
Glad to hear those changes did not impact you re PHP
Personally, I think the moment SvelteKit stops working on plain container images & Cloudflare Workers is the moment Svelte dies.
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
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 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.