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