Ha 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!
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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'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 :'(
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.
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.
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.
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.
(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.)
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.
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.
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.
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).
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.
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
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
> 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
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.
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.
/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.
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".
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.
Kinda new this day was coming, sad to see it actually happen