"This gives us the best performance characteristics when you're following best practices (i.e. hoist data fetches to Server Components or route loaders), at the expense of making an already bad pattern a bit worse." [1]
Their rational was pretty solid in the PR, but seems they overestimated how ready the community is to embrace newer best practices and they are back tracking.
My impression from the later responses was that they underestimated how often this particular pattern for parallel loading with React Suspense is used. The people that are slow to embrace the newer patterns would likely not have used Suspense at all, so nothing would have changed for them. This would have affected a specific subset of people that used Suspense for parallel loading, but didn't switch to route loaders.
What are they, in plain terms? Is it just manually hoisting what you know a route needs all the way to the top of the tree? Or is it some compile time magic that analyzes your components used, making the decision for you on what to fetch for a route?
Haven't used them myself yet. As far as I understand it's essentially moving the data loading into the router. The router has an API for the loaders so the rest will work automatically like loading states. So yes, this means you have to define what to load at the top where you define the routes. Though I think this also works with nested routes, but I don't have any experience with them.
> So yes, this means you have to define what to load at the top where you define the routes.
And Meta's way of doing this is with Relay, so you are still defining component data requirements with the components and query fragments, but there's a compile step that produces those route level queries.. so you still get "co-location of a component's data requirements with the component", and "top level early data fetch" for the render-as-you-fetch pattern.
This change breaks the fetch-as-you-render pattern where components make individual data requests for their data, because that pattern is considered bad for performance (for Meta's use case).
It feels like the react team has decoupled from the best interests of the community. Much of the appeal of react was in building the SPA. There are so many web apps that are best built in react on the frontend. Instead we now get this Vercel-driven RSC use-client mess which is of little benefit to the SPA crowd.
The fact that the suspense change made it this far shows how the react team has lost focus. Now more than ever, the ecosystem is really primed for a competing framework to dethrone react. I say this as someone that has invested a lot into using react.
This seems unfair given how the team reverted the change. You can argue they messed up and maybe aren't as in tune to some segment of their user base as they should be, but not that they aren't interested in making the best software they can for everyone.
That's not unfair, the move was clearly to benefit a PaaS provider in detriment of the majority of React users. They are clearly not taking most users need in consideration and they should be judged for that.
If you've worked with React and especially built e-commerce stores with it you'd realize what they are aiming for mimics a lot of the work that went into Relay but for the larger community. This is a continuation of that and not driven by trying to pump Vercel bills.
Kind of discredits all your opinions on that topic
I love Preact, in many ways it's superior to React. But I wonder if their positioning might be weighing them down, that they will always be catching up to stay compatible with React, to implement the same/similar interface. I know "preact/compat" is optional and separate, but there's an expectation that they will keep up with React's new features - even if it doesn't fit well with the design and goals of Preact.
Preact is how I wish React would have evolved: stay small, keep a simple interface, focused on being a view library instead of a sprawling framework.
I did an evaluation on the various frameworks 2 years ago, and it largely came down to only these 2 choices:
- React (if you want the largest support, packages, community, but sacrifice on performance)
- SolidJS [1] (best performance, composability, low-level primitives, but sacrifice on packages/community)
Every other choice like Angular, Vue, Svelte are just somewhere in between these 2 spectrums which I felt was not worth it. Either choose the one with the largest ecosystem or one which has the best primitives & performance.
- React (vdom, slow) (largest ecosystem)
- Vue (vdom, faster than react) (large community)
- Svelte (fine-grain, faster) (best dx pre-v5) (composability is still not as flexible in v5 compared to SolidJS) (small ecosystem)
- SolidJS (fine-grain, fastest, most consistent) (dx similar to react) (small ecosystem)
People who love Angular really love it, so I trust that there's a legitimate place for it. I think one of the main things people love is that the convention and tooling eliminates a ton of the noise and redundancy that the other tools tend to lead to as teams slap applications together without sufficient guard rails.
Essentially a lot of the tools we use are only meant to be view layers, and we constantly cobble together supporting layers (models and controllers for example) ad-hoc. Angular handles that off the shelf. I suspect a lot of people are put off by this because it feels imposing and they might not realize they're implementing the same stuff manually, and likely doing it worse.
I used to think it's plain old garbage but realized that's ridiculous. There are reasons people prefer it in some scenarios.
SolidJS is my favourite by a long shot, but I find myself using React because I know so many people I write for and work with are more comfortable with it. I'd be glad to use it more often if it made sense.
I'm currently learning Angular and it's an absolute dumpster fire of a framework in the sense that it offers no clear philosophy. It's just a jumbled mess of concepts and syntax.
I think where it shines though is that it's completely batteries included, which I can see being useful for large enterprises where it's near impossible to change things.
Having recently worked on a very legacy React app, it became apparent to me the value of frameworks like Angular. If you can maintain it and upgrade it gradually, React is arguably the better choice. But if you're leaving it to stagnate, Angular is a far better proposition.
I think we're on the same page here. I've also found that a non-trivial number of teams actively maintaining React apps are still totally capable of rendering them into a state of dysfunction and paralysis in the same way that stagnating apps can devolve.
They think they don't need batteries included because it's 'bloat' or the opinionated patterns are inferior, but after a couple years they've got a couple dozen seriously bad patterns and a 400kb application that could easily be pared down to 100 or so.
This isn't so much a virtue of Angular or React specifically, but a reality of the deficiencies in our industry when it comes to the human side of the equation. These people would be better off following Angular's general conventions whether they realize it or not.
So much of Angular versus React is "No one got fired for picking Google tech" versus "No one got fired for picking Meta tech" with some of the obvious problems of their "parent" organizations' approaches visible in the maintenance efforts.
In all honesty, I think neither one of those are the main measurement you should be using from a business point of view. React has a huge ecosystem, but many packages are out of date or poorly maintained. This means you either still roll your own or you take on the pain of working with the bugs or compat mismatches you inevitably get (looking at you, React 18). On the other end, I would say for the majority of modern web apps, performance doesn't matter too much, so long as it isn't absolutely abysmal. So what are the right metrics, in my subjective opinion? Readability, and by extension refactorability, and ease of iteration. In other words, developer experience, because that will literally save your business actual time and money.
I think bringing in component libraries that include the kitchen sink, the farmhouse and the farm... as well as the neighbors farm are a big issue too.
Corporations fill their ranks with junior developers, more breaking news at 11.
I remember plenty of multi page applications from big corp that ran like a dead dog too, back in the day. Or ASP sites that wrapped the ENTIRE page in a form, with all of the frustrating complications that entailed.
I think that's what lead into a lot of "Alt.Net" development and tooling... when the blessed ASP.Net MVC came out a lot of the alternatives just died quickly though.
I switched to straight HTML, JS + .ASHX handlers for a lot of things leading up to that point.
If you really think the performance of the framework is something you need to optimize but want to keep the react ecosystem, you could also use react (or preact) with preact signals which I think should make react perform more like newer frameworks like solidjs in terms of not rerendering entire trees of components unnecessarily.
I'm not sure this is really the first thing that needs to be optimized for most people though, despite there being a lot of frameworks whose sole reason for existence seems to be fixing this aspect of react's performance.
Any slow app would be just as slow if the team had built it using different tech, because it's the design of the software that makes it slow, not the framework.
There is no framework that has a "pit of success" that makes it inherently easy to build a fast app, so any team that uses a framework poorly is just as likely to use a different framework poorly. If they switch and things improve it's probably because the new framework happens to fit their mental model rather than any inherent function of the framework itself.
A good team that designs their code to make the most of a framework could write a good, fast app using any particular tech.
I've spent a lot of time thinking about what the "pit of success" looks like for a framework to make it inherently easy to build a well performing app ("fast" is a different subjective matter), even in some of the worst cases of a naive developer doing naive things. (I think I got really close to a "pit of success" with Butterfloat if you enjoy working with RxJS. Its defaults are tuned for smooth performance even if you are doing too much work in a component.)
There's no framework that has a "pit of success" on every subjective performance quality metric, but I do think some frameworks more than others have larger "pits of failure" that make it too easy to get bad performance even doing what you think is supposed to be the right thing. Because I've vocally picked on it many times at this point, an easy example to mind is Angular's Zone.js is a big opaque library that can accidentally drop you into a "pit of failure" without you realizing how you got there. I'm glad a couple years after I raised some warning flags about Zone.js that Angular is finally addressing that elephant in the room and removing Zone.js as the suggested option and are close to removing it as the default option.
(I'm less glad that the reason that finally pushed them to do that is adding Signals. It seems wild to me to have proper Observables and also Signals and that just seems like another potential pit full of accidentally doing the wrong thing because it looks easy but the interactions between imperative code, Signals, and Observables is going to necessarily be complex and fraught with scheduling problems. I can't say that I'm surprised that Angular development is again moving one step forward while also two steps back at the same time.)
I know others with similar rants about React Hooks and how easy it is to miss needed dependencies in the dependency list of a Hook and too easily fall into a pit of failure.
It is useful to evaluate frameworks with some small eye to "how hard does this make it to do performance right if we follow its 'best practices', even in the case of simple mistakes?"
This seems to completely throw out DX. Svelte is an enormous productivity increase from SolidJS, trading microseconds of performance for that (Svelte is still very fast) does not seem worth it at all. That's like saying your two choices are Python and C, Rust not being worth it.
> That's like saying your two choices are Python and C, Rust not being worth it.
Not a great example since that’s actually why all the other propositioned system language replacements never took off in the way rust did. Rust is (or can be, but importantly, when used idiomatically and not just “in some form”) as fast as C.
There were lots of other languages that tried to replace C with better DX but failed because they weren’t Pareto optimal. So I kind of get GP’s point: DX alone won’t cut it.
I wouldn’t call the ecosystem of svelte small. Since it adheres to HTML and javascript so closely, the effective ecosystem is pretty much the things supporting plain javascript and plain HTML, which is a lot of things.
(Though two years ago I think sveltekit — the app framework for svelte, without which svelte is incomplete for many cases — may not have been quite ready for production, so it was probably fair at the time.)
Well TBH svelte works just fine with vanilla javascript libraries, so you could argue that the ecosystem is not as small as you think. Almost every other library/framework in this space requires a wrapper around the vanilla javascript library.
One of my criteria these days is portability… web components are a frustrating API to use directly but one of the reasons I develop with Svelte is that it can produce web components that, should we pivot frameworks some day in the future, will be able to live inside another framework.
React absolutely fails in that regard. I try not to be a conspiracy theorist but I think React actively avoids web component compatibility as a form of vendor lock in.
React 19 has full support for web components and it scores perfectly on the “does your framework play nicely with web components” test suite whose name I don’t recall.
They are moving to "Runes"[0] which IMHO feel clunky compared to previous reactive declarations. There's some perf reasons, but Svelte performance was not an issue for me to begin with.
There's new syntax for props, reactivity and state that's slightly more complicated for hello world applications but you really notice the differences for even mildly complicated components.
export let foo;
vs
const {foo} = $props()
looks far worse until your doing something like extending an input and you no longer have to deal with $$RestProps ugliness
Ugh, this post is so much drama, while the actual events are pretty boring and happen all the time. React team changes something, there are unintended consequences, the change is reverted.
Yes, it was very much intended consequences, based on their perception of usage and what usage should be like, which was biased. They admitted it and plan on reverting though.
I think you're entirely forgetting about Rust, AI/ML/whatevs, or any of the other myriad topics delivered daily. It's what happens when you open up comments from anyone anywhere at anytime.
The first problem here is putting a UI widget in charge of fetching data. React was originally designed to be the V in MVC. Had we left it as the V in MVC we'd be loading data in controllers, like we do in every other framework. Having a React component be the model, view and controller is a mistake, and we can still reverse course.
> React was originally designed to be the V in MVC.
React wasn't designed to fit in the MVC model. However, if we are trying to draw an analogy, as far as I can see it most closely resembles the controller. It is where the events are handled to update the "model" (state), which are propagated to the "view" (DOM element). What makes you say V?
"Just the UI: Lots of people use React as the V in MVC. Since React makes no assumptions about the rest of your technology stack, it's easy to try it out on a small feature in an existing project."
How so? Under MVC, V is the visual representation of the model. React does not exist there at all. It relies on the DOM and associated technologies to provide that.
React does give a mechanism to keep the visual representation in sync with the data and it provides a place to handle events that update the data. While it is not designed for the MVC model, so we cannot truly speak to it in MVC terms, the closest analog to those seem to be the M and C.
I'm assuming you had to go back to a commit from 8 years ago because all future commits realized that whoever wrote that React is the V in MVC was confused?
This is much like saying the DOM is not truly part of the view because it doesn't directly represent the pixels that the user sees. Both the vDOM and actual DOM exist entirely to facilitate a particular kind of presentation, and can be logically separated from the model which could in principle be presented in purely audio format or something. If that's not a "view", then what is?
I think the point is React does not provide the DOM, the browser does. Unlike MVC frameworks in languages that do provide their own UI. Smalltalk being the grandfather of that.
Yes but the DOM is the render target for React and hence the V. Just because it's a complicated way to talk to the screen doesn't mean it's not doing that.
Are you saying that you do need to directly specify pixels to count as a View? I don't consider that a useful engineering principle. If not, I can't see how what you said changes anything. I saw their point roughly the same as you did, and I think it's bad.
The div object is where the visual representation is handled. React in this case is only concerned with passing data to it, which is explicitly the model's concern under MVC. Although I suggest that event handling is really why people choose React, and that is the controller's concern according to MVC.
Again, React isn't designed for the MVC model, so we have to really stretch ourselves to find any kind of similarities. But if React was only the V to the greatest extent that we can pervert the meaning of V, what value does it add?
I think what OP and others are talking about when they refer to React as being the view part of model-view-controller is that a server might render a React component in the view layer after the controller has decided what data to collect and which layout to use.
I think something other people sometimes talk about are single-page applications, in which case it's not a single component being rendered but an entire application. At that point MVC was simply disregarded by the developers because React is really just trying to be the V in MVC.
That would be what is known as the template layer, not the view layer. If we're just randomly making up definitions for MVC, then sure, anything goes. But as nobody has provided the the arbitrary definition they just came up with off the top of their head, surely we're sticking with the standard Smalltalk usage?
> That’s a link to a route handler (controller) that makes a graphql call (model) and then explicitly updates the DOM with renderComponent (view).
See, we're already not talking about MVC. Under MVC, the model updates the view. But, as you say, in your code the "controller" does the updating. Maybe you could argue that React is serving the role of the model here by actually being the place where the DOM gets updated, but, ultimately, we're always going to struggle with finding such analogies when React isn't designed for the MVC model.
Right, but the model does know everything about signalling change. Under MVC, the model is responsible for updating the view through the passage of messages.
Which is essentially one major part of what React tries to offer. Granted, in an ugly way as it has to deal with the harsh limitations of Javascript instead of having the power of Smalltalk to work with, but such is life.
> React was originally designed to be the V in MVC.
So much this. As we built more sophisticated apps using React we were constantly frustrated with how much code was ending up in the views, and how difficult controller frameworks were to work with (looking at you Redux). So we built our own mini-framework that explicitly separates the view from the controller. Seems like a simply change but it is amazing how much more productive it makes developers, especially with large complex applications that need refactoring as they evolve.
Unfortunately our skills are in writing code, not marketing, so we don't have a fancy website like most frameworks. But the details are here: https://github.com/aha-app/mvc
That’s why I think the most sane way to use React (or Vue) nowadays is through Inertia.js.
Have a proper backend doing all the backend stuff and just render page components as if they where just the views of the framework.
All this server components nonsense is solving a problem that maybe Facebook has but almost no one else does. But people think they do, so a lot of complexity is added for no real reason.
Caleesi voice: React wasn’t invented to stop the wheel of MVC, it was invented to break the wheel
And I think life is better without the V-C distinction. Models ofc still exist but the field has gotten more fine grained for the term to still cary meaning
Going to assume you're talking frontend? Otherwise you'd be claiming most Spring, Django, Rails, Angular, <enter common backend framework> codebases are a nightmare to work in. While there are many good application architectures that don't fit into the MVC pattern (or introduce additional layers, e.g. - auth), separating DB ops (M) from business logic (C) and endpoint handlers (V) has always been rather maintainable/testable in my experience.
Yeah, MVC (and MVVM for that matter), seem like architectural approaches that are great in theory, but with the reality of constraints, requirements, timelines, and ultimately many engineers' misunderstanding of things (frankly I'm probably included in that group as well), it just leads to a mess of interdependency and tight coupling among functionalities.
Now granted, this is pretty much a given for any architecture (nothing is perfect): so maybe my expectations of what things should be needs to be reeled in a bit.
> it just leads to a mess of interdependency and tight coupling among functionalities
Disagree with that. Most UI frameworks, including ASP.NET Core, JSP and JSF (Java based frameworks), Ruby on Rails, and Django (Python) are all based on MVC. That's no accident. MVC works very well.
“We care a lot about SPAs, team misjudged how many people rely on this today”.
This comment worries me because I was under the impression that RSCs are an option for a specific use case and not the one approach to rule them all. SPAs should be supported and expanded because they do serve a valuable purpose not only based on their use cases but also for developers. React being SPA friendly means people can spin up hobby projects, small applications and big non SEO reliant apps with ease. Going all in with RSC and ditching SPAs means that many will be discouraged from entering the react scene due to the sheer amount for things that used to be optional and now suddenly just became mandatory.
I liked react and I still like it. But I believe it’s on a path to alienate its user base.
Unrelated, but I'm impressed by how fast browsers can be in some cases.
I once created a HTML file with just a start/end HTML tag and 50k (unstyled) button elements in between, curious to see how it performs. I tried the same in Flutter on a release build (using Material widgets so they are styled) and the HTML was much faster.
I was able to tab through (changing focus by holding tab) the buttons in both Chrome and Firefox at a consistent frame rate with no signs of any lag, while FLutter struggled and lagged quite a bit with the same.
Would anyone know why that is? Are web browsers hyper-optimised for static documents (beating a "native" GUI toolkit for static documents)? Is Flutter just comparatively slow compared to Qt, GTK and so on? Does the styling have that much of an impact on performance?
I am aware that updating DOM elements is uniquely slow for browsers but this experiment was a surprise for me and I'm curious for an explanation.
> Are web browsers hyper-optimised for static documents (beating a "native" GUI toolkit for static documents)?
Yes. The browser is the world's most widely deployed and used runtime. I would assume Blink, WebKit and Gecko are the three most carefully optimised pieces of software ever.
CSS can certainly be performant but you need to be aware of what can trigger reflows, which will absolutely destroy your performance. Cascading reflows are horrible.
I will in a bit hopefully. It was a few months ago and I don't have Flutter installed on this computer but I'm doing it now.
Edit: I was coding it up now, but my storage is full (having trouble copying text to my clipboard and unable to save files) so I don't think I will be able to deliver on what I intended. Sorry about that.
On the HTML side, I had a code generator (in Javascript) that output `<html> <button /> <15000 more buttons.../> </html>` and wrote it to a file.
On the Flutter side, I used the default Flutter sample app (`flutter create .`) and I just used a similar code generator to put 15000 buttons in a Column widget.
I don't think I'll be able to do much else to help with reproducibility sadly.
If others try the same, I would be interested in if their results are any better than mine (with Chrome/Firefox being faster).
I think if you use ListView.builder() in Flutter instead of a Column you will see much better results - it ensures that Flutter does not have to layout 15k buttons all the time, just those that are visible.
Of course, it's unfair to allow Flutter to have optimizations but not the raw HTML, but disallowing well-known, real-world optimizations is also an unfair test IMO.
Desktop toolkits expose list/scroll virtualization to apps natively and expect you to use it, so they aren't optimized for the case of a giant single vertical layout. HTML doesn't so devs are forced to just throw piles of markup at the browser which has to digest it all.
But, that's a very web-specific UI design idiom that you just don't find in typical native apps. If you change your test to use desktop UI as it's intended to be used, and then stick say a few tens of millions of buttons in it, then the browser will find it much harder and the desktop toolkit won't break a sweat.
I feel like the percent of people using suspend is a tiny tiny fraction of the percent of people using react. I think this title is massively sensationalized.
The unfortunate part of this is that a large percentage of that small percentage is library maintainers, so it matters a lot more overall because of their role in the React space, even if users aren't necessarily using those features.
I think you're wrong, without knowing it. And in a way this kind of subjective judgment call "people must be using react like me I guess" is the entire cause of this misshap.
Don't assume usage patterns. Measure them, or you know nothing.
Thanks for the mildly condescending attempt to give me your earthly wisdom, though. Believe it or not, common sense can occasionally be just as useful as hard data. Maybe this can be a learning opportunity for you instead.
This is almost as biased as a personal anecdotal opinion:
- You're looking at open source projects only (Most users of Suspense are going to be commercial closed source)
- You're looking at all versions of React over the last 12 years (Suspense is fairly recent)
- You're not weighing by number of stars, users, contributors, activity (E.g. you're probably 5M "React getting started" projects in there)
So, no. Still not. Anyway, by now the React team acknowledged that their initial decision was biased and decided to not ship React 19 without a solution, so we're good!
I've noticed the internet becoming generally slow and laggy over the last few years for older computers and devices. Things from around and before 2015 to 2017 are becoming pretty unusable for doing basic web app tasks.
It works totally fine UNLESS you load something like a crazy landing page with animations. I always end up having to kill Firefox and prevent that site from opening.
One unexpected benefit of LLMs is they’re more performance friendly, I can query the docs of what I’m working on without loading the docs themselves.
I come to think that corporate people love React because if you stop following the news and not be constantly reminded about the direction React is currently heading, you will fall out of the loop and your projects will stop working in 1 year or so. Which is beneficial for the employees, as they will never run out of work to do, maintaining the framework itself rather than their actual project. And the framework gets more complex with each year, too, so you can pretend that you are doing some complex work without actually doing it.
I love svelte, and is what I reach for personally, but it's still early enough in its lifecycle that there's constant changes / new paradigms being introduced, especially if you include svelte-kit (originally it used sapper).
If I had a team that had gone all in on Svelte I'd be bemoaning the need to upgrade recent code already.
Hot take time: React is the most corporate framework to have ever corporated in the history of corporate, designed for one thing first and foremost: To make high turnover easier so they can fire you at any time and replace you with the next guy in line who'll already know how the entire thing works... because there is only one stupid way to do things in React. You either like it or it feels like pulling teeth.
I'm up for cheering for literally any alternative. Any.
To me Angular seems even more of a corporate (sorry "enterprise") framework, and does a better job at providing the "right way" for the entire application architecture. React (now) has a bunch of rules you have to remember, tricks to get performant code, etc., but it still leaves too much developer freedom on how to structure things. They should have gone full corporate, with rules and prescribed best practices on every aspect, so a new hire can just follow the manual. Redux was perfect in that sense, verbose and predictable, like a factory.
Of course, I would rather quit than work within such a strict framework, but React going there halfway is even worse.
Wow. 2y3m and counting (presumably, given article title).
It's very straightforward, yet a complete surprise to me. I guess I'm just replying to invite someone else to give me a long-winded explanation of how the JS ecosystem works.
ex. now I'm flummoxed as to how Vercel/next.js exists/releases new features, if they're based on React. Seems you'd either get stuck living on React top of tree, unreleased, or have an unholy merge to do.
React in particular puts out a point release with breaking change warnings, along with an upgrade guide, several months before the next major version so that developers have plenty of time to prepare for any required changes. (For React 19, this was the 18.3 release at the end of April 2024.) They also try to provide scripted code updates ("codemods") to ease the upgrade process.
which is why I switched back to vue.js, who so far is much simpler and get the job done if you need a true SPA with SSR only as an option instead of being the "new" primary focus(which made things much more difficult to use, and slower)
>"In React 19, we’re adding support for rendering document metadata tags in components natively:
function BlogPost({post}) {
return (
<article>
<h1>{post.title}</h1>
<title>{post.title}</title>
<meta name="author" content="Josh" />
<link rel="author" href="https://twitter.com/joshcstory/" />
<meta name="keywords" content={post.keywords} />
<p>Eee equals em-see-squared...</p>
</article>
);
}
When React 19 renders this component, it will see the <title> <link> and <meta> tags, and automatically hoist them to the <head> section of document."
This is one of the most brutally stupid things I've ever seen, and has pretty much sealed the deal on me dumping React at this point.
Why? It fixes a serious pain point React has had necessitating things like the helmet library. This seems like a perfectly reasonable of way of doing it.
It completely breaks the React paradigm of a single mount point that handles DOM concerns, and introduces god knows what kind of global side effects. The beauty of a React component was that they could be treated as fully self contained little bits of UI. This is basically taking us back to jQuery.
While that’s basically what all this stuff really does under the covers, it doesn’t feel “react-y” to me.
Using JSX does. Especially for stuff like meta tags where there can be a couple in force at once.
I’m not going to argue it’s perfect but it seems like it fits in to me. It’s basically acting like the restrictions on where the title and meta tags can go no longer apply so you can just sprinkle them wherever they hopefully belong in your app. And react takes care of putting them in the right spot.
> Very little of what react does seems reasonable to me though.
So are you someone who dislikes it in general and just using this as one more argument?
I’d be very curious to see the opinion of someone who likes react who thinks this is a bad idea.
>I’d be very curious to see the opinion of someone who likes react who thinks this is a bad idea.
I love(d) React to death from day one, and I've been using it every day professionally as a front end dev since 2016. This is precisely why the feature upset me so much. As another commenter said, they are clearly jumping the shark here. How exactly will this even work? Does this mean that every single render of every single component now has to tree shake the VDOM for <title> and <meta> tags? And now I'm encouraged to spread these things out all over my app instead of handling them centrally? Again, brutally stupid.
I'm so done with React. Since Vercel kidnapped it everything is done for/because of their platform and their interests. Most evil company I've seen in a long time.
The article says that React was about to make a change, the community pointed out it had bad trade-offs, and React backed off. What does that have to do with Vercel? Where's the problem with React here?
Vercel is a (more?) opinionated ecosystem that influences higher adoption of Server-Side-Rendering and other features. This encourages projects to use more niche APIs like Suspense, and due to the capital, marketing, and bearish adoption of Vercel products by vocal parties (startups) - will influence React's developers to cater to them.
I'm agnostic because I quit full stack web development ~6 months ago. I think the product development story sucks and combined with the market economics of the current tech industry is just not fun or profitable to invest my career in.
It's -probably- a good thing that stuff like SSR becomes mainstream/required. But I really don't like that one of the main entities behind it, Vercel, has raised $563M as of their latest Series E as they steam towards an IPO of their Framework/Cloud offerings.
So they made the choice that worked well in the mega-scale application they tested with and performed worse with the pattern they didn’t think was too widely used/would be much of a problem. And it would make planned future features easier.
That sounds 100% reasonable.
Someone noticed it, pointed out it was a big problem for them and enough others it got reverted.
Sadly, many products require sophisticated frontends, the FE is often a core part of the value proposition. React may be overkill in smaller cases, but it's a good tool in these cases of complex dynamic UIs.
Exactly. Things like LiveView (Phoenix) are changing the game somewhat, but if you need a sophisticated frontend, React is still a good way to go. PWAs in particular I think still have a lot of promise, even if they are being (intentionally) stifled by tech companies that have competing interests and want web apps to be as impotent as possible.
For simple frontends that don't need to be complex UIs, I definitely don't turn to React (I love simple tried-and-true templating systems like ERB and/or EEX), but I definitely think React has it's place. Not everything should be SPA, but that doesn't mean nothing should.
Heavy use of interactivity is hard. React makes it maintainable. It was hell before.
I've been working with React (and RN) since it came out and I've had nothing but good experiences, especially compared to the previous decade before React.
My motto is local-first, the more stuff the client does, the cheaper it is to scale and less bridging between the server you have to do.
Move everything to the client, especially the database. Let the database do the syncing. Plus you get offline and undo/redo basically for free. Pagination? Fuggetaboutit.
The more stuff the client does, the higher the payload is going to be and the more complex the bundling and tooling will be.
I'm in a company with around 100 devs now and I can certify you that front-end SPA do not scale at all unless you throw a insane amount of devs hours in the tooling, even then it barely does.
That's not mentioning the insane npm churn that you have to maintain, the testing story which is pretty abysmal outside of a few top libraries, the typescript tooling which is eating so much ram that I'm changing my laptop.
And I'm not sure why you mention the pagination as a plus where it's one of the big downsides of the front-end stack, there's a lot of hacks to make it behave okay in most situations.
> I'm in a company with around 100 devs now and I can certify you that front-end SPA do not scale at all
What is the difference between SPAs and other monolithic architectures, e.g. on desktop, that makes it so?
Why can’t you go with OSGI-style plugins, for example? Loose coupling, separate SDLC and deployments etc?
The reason it works fine in a native app and not on a browser is that the browser streams documents over the network. It's pretty much the worst place to download large payloads on demand.
Native apps do not suffer from this problem, your binary can add an extra 20mb without much downsides
Native apps do network downloads of comparable or even bigger size too. I do not see how this can be an argument in SPA vs MPA decision making. „Rich client“-server architectures existed long before SPA became a thing and on much slower networks, so pretty much every problem modern SPAs face, from UX to performance to change management, was already solved by someone. Isn’t it actually ignorance of JS frontend community which has reinvented many wheels in rather ugly way, that causes the trouble?
It's fine to stream 20mb in a browser as long as it's not part of the core JS.
Browsers can handle many GBs of storage. You can even store them via OPFS directly on the native filesystem if supported. There's also Chrome File Storage API and if all else fails IndexedDB (which is more limited, but works decent for synced databases).
This isn't the use case of an SPA though since those extra megabytes would end up in the bundle, this is more like a game. Ironically I would agree that games are better suited to the browser than SPAs because you can afford to wait, you use wasm and you don't have to reinvent the wheel of the basic browser features.
I'm aware of that, that's why I pointed out the insane complexity of the bundler tooling. Splitting in chunks isn't a solution, it's adding fuel to the problem.
Not really, it's just a solution to the need of complex apps and the need to support the ability to load pieces of the app without having to download and install it like a native app.
Native apps can do similar things with dynamically linked libraries, and there's a lot of complexity when it comes to compiling native code.
The web bundler tooling really isn't that complex nowadays, especially with Vite. It's one file usually 10 lines long. It can use SWC and LightningCSS, written in Rust. They're safe, fast, and require minimal config.
I'm also aware of those, that's exactly what we're using in my company. It's a power hog, so much so that I had to change my laptop to run the SPA properly. The local experience is absolutely terrible since it has to disable the bundling to use hot reload (at least that's what I guess is happening) and each browser reload takes >1min to load.
Then there's the complexity of the caching in continuous deployment, we literally have a custom metabase dashboard to make sure the caching isn't too bad and lasts a few days.
Then the default config doesn't scale either as you can guess and we have our own.
There's a reason I have this opinion, I know what I'm taking about, I've been using all those tools and they add a lot of complexity to your app.
The reason it works on an native app is because loading a dynamic library is essentially free, it's just stored alongside the binary.
That's exactly what I meant by "not scaling". Sure if you have much less developers than us and you don't make 100 deployments per day, maybe an SPA can work. I can assure you that when you need to support a complex product, it absolutely doesn't scale at all, even with some developers full time to try to fix the stack.
Our full bundle itself is close to 70mb and still growing every week, that's absolutely insane.
There's a reason why Vite has a default bundle chunk warning of 500kb.
There's really no reason it should be that large. If you just lazy load each route your chunks should distribute into manageable size pretty much automatically.
It sounds like you may also have a bunch of dependencies. Which can happen in a native app, but in a web app as you know you'll have limited resources so size is important.
You're all over this thread saying "We couldn't scale it, so you little plebs certainly can't." I'm sorry it didn't scale for you, but it's telling that you think your experience is THE experience. Facebook uses it, I think your company of 100 devs could scale it fine, as many do.
> Heavy use of interactivity is hard. React makes it maintainable. It was hell before.
Agree, React is great for UI interactivity.
> ...the more stuff the client does, the cheaper it is to scale and less bridging between the server you have to do.
Disagree. The most costly form of scaling is people. UI + business-logic + data-modeling + data access (ACL) all held in async client concepts is a complexity nightmare in my experience. Even for my team-of-one side-projects.
Server <-> client bridge is a feature for managing complexity over time. I may agree that added ceremony could make 95% tile app experiences default harder. But for anything that's not a toy, the #1 risk is always team/people/communication complexity.
average HN commenter: React is artificial complexity, you should be able to make any website using jQuery and plain HTML, because that's what I did when I last did front-end development in 2007.
also average HN commenter: If you use Python for your backend you're a moron, you need to use Rust so the API calls for your 0.5 requests/sec web app finish in 100ms instead of 125ms (note: 99ms is waiting for the database).
No one is saying that. People are starting to realize is that JavaScript frameworks are an unnecessary complexity to web application development. People have been seriously turned off by things like angular and react, and with good reason. With the advent of things like hotwire and htmx those JS frameworks are no longer strictly necessary, and many people welcome the news that their importance is fading away.
I've been maintaining React SPAs for 6 years now so I absolutely know what I'm taking about when I say that it doesn't scale. I experienced all the pains of the js ecosystem.
"almost made the internet slower"... uh, pretty sure it's been making things slower since inception when it replaced html + a few ajax requests. I know, I know, I'm old. Get off my lawn.
I do actually remember following its development, hate NAT, and of course feel constrained by the V4 32-bit address space. But V6 has its designs problems too and while over the years I’ve tried to use it, it has never been worth the hassle and, yes, is slower (probably because most connections are to V4-only sites).
I remember when React first came out… it was actually a dream for performance initially. The VDOM diffing made complex, fast moving UIs way easier to run performantly.
I lost track of it around maybe version 0.6, by the time I picked it up again we were in Redux land and the framework was five layers of crap deep. Sigh.
This is a friendly PSA that you don’t need to know or care about reducers, thunks, sagas, Redux, Flux, Next, React Native, React Native for Web, CRA, etc. in order to simply use React productively. Despite the humongous ecosystem with elaborate architectures and some slow or footgun-enabling implementations that’s grown on top of it, React itself is still a relatively small and lightweight library. A couple of lines is still pretty much all it takes to get from some pure HTML to working reactive rendering on the client. (I’d still do that on a new project—it’s a good opportunity to see what’s best from first principles today, as opposed to when you started a project last.)
The most radical addition since the early days are functional components and hooks, which are not mandatory to use (class-based components are considered “legacy”, but aren’t actually deprecated). Another one is RSC, and you need to care about those even less (though they can come in handy in some scenarios).
Okay, there was one more somewhat significant change under the hood: in 0.14 they’ve made React more of a general-purpose library, splitting DOM-related specifics into ReactDOM. This separation can’t come without some overhead, so it’s unlikely React would ever going to be the most performant for the Web. (Last time I looked, Preact was faster—they did abandon that layering and went with the coupled architecture.) However, that didn’t magically turn React into a slow bloated framework—but it did enable a variety of interesting non-Web applications such as rendering native apps, rendering on embedded LCDs, etc., where you can use React core as a standalone renderer with your own reconciler instead of ReactDOM.
To me, the initial allure of the vdom was how much further it got you then backbone.js’ “this.model.on(‘change’, this.render)”. When that one liner in backbone was enough, it was magical. But once you hit scenarios where overwriting the this.el.innerHtml, it became super painful (usually when that el was hooked up to 3rd party plug-ins, html5 video tags, etc).
Once react switched from class based components and mixins, each subsequent release was only more confusing. I remember the conference talk where they explained the problems with mixins (forgetting to cleanup and them all sharing one state), both of which can be solved in a few different ways, but they opted for a whole rewrite for hooks, which I “get”, but think it increased the complexity dramatically for a very low gain.
> The VDOM diffing made complex, fast moving UIs way easier to run performantly.
That was marketing more than reality.
VDOM diffing isn’t the slowest way to update complex UIs but it isn’t the fastest either. In practice your app often ends up generating a lot of VDOM which then gets diffed away… a bunch of work and then a bunch more work to determine the first bunch can be thrown away. The app developer needs to step in to manage and optimize the process.
Believe me, I know. We were manually diffing in a previous version before React came along and it was a shitshow.
The primary initial benefit with React was an improvement in reliability. Our previous implementation (in Backbone IIRC) wasn’t doing it quite right. Having it built into React was a gamechanger. Then with judicious use of shouldComponentUpdate you could minimize the amount of VDOM thrashing required.
I know at one point we explored immutable.js to make the diffing super efficient but the DX was pretty bad. I’m excited for JS to get records and tuples at some point and make that all way simpler. But for now it feels like shouldComponentUpdate and PureComponent are a lost art of React, few do it.
I’d love to see these narratives actually demonstrated in tests via blog posts. I suspect it’s more a demonstration of human memory and perception than it is of reality.
Well, you can go back and look at the original blog posts announcing React? I assume they're still on the internet somewhere. React was a pretty massive speedup over the portions of Facebook and Instagram's frontends that it replaced and they showed off their benchmarks a lot early on. That library had very little in common with the thing now known as React, though.
Enshittification is when a company offers an amazing product, but once they have a hold over the market, they make it worse and squeeze customers. It works because customers are so locked in and there are market forces stopping them from switching to a competitor.
Frontend development is not being enshittified. We have so many frameworks that you can switch to if React isn't your cup of tea. Hell, you can use Astro and use React, Vue, Svlete, etc and it renders to HTML. HTMX is a new framework and easy to pivot too since React devs know JSX.
React is also silently borrowing ideas from Svelte and Solid.js (and those were inspired from React) so all these frameworks are improving each other without even knowing it.
This is what I don't really understand when people are airing their grievances. What exactly is the problem? You can absolutely write webpages and software the same way you could 5, 10, 20, etc. years ago. There's absolutely nothing stopping you from making a VanillaJS website or JQuery or whatever. Nothing went away. There's just more choices.
> There's absolutely nothing stopping you from making a VanillaJS website or JQuery or whatever.
There’s nothing stopping me doing that on a solo project but frontend web dev is increasingly a monoculture around React so when you’re talking about making this decision in the workplace you end up using React whether it’s the right idea or not.
I worked at a place that ended up using React because a senior manager was concerned about hiring and wanted to use something we’d be able to easily hire for. It wasn’t actually a good tech fit but that wasn’t the priority. And in many ways he wasn’t wrong. There’s a mini-generation of developers that have only experienced front end development though the lens of React and have barely if ever used, say, raw CSS.
Their grip is not with React per se, it's with the pressure to use new, updated features. Hooks was like this when they were introduced. People were so used to using lifecycle functions and then hooks became the "official" way. Users could still use classes and lifecycle functions, but since it was not the new "preferred" way, devs had the pressure to update old perfectly working code.
We're seeing the same with RSC. Many Next.js users are updating their apps to use the new App Router, but I've seen many just stick to the Pages Router since it just fucking works for their app and RSC has improvements, but none they care about.
I've got applications that are years behind in React. I actually felt the opposite was true: I could upgrade React without having to change my code at all. And even more awesome: I could gradually use new features without touching any existing code.
I wonder if some of it is a perception issue: Everyone, including the instruction manuals, Stack Overflow, and search results, are talking less and less about the way I do things, and more about these new ways.
Kind of like swimming against the current back when JQuery/Angular were the dominant ones and suggesting React would get you laughed out of the room? How nobody would care if you could use React because every business was using and only hiring for JQuery devs?
The cycle continues. People acting like the [current popular thing] is the problem are missing the forest for the trees.
Resisting change for the sake of it, and having space to make pragmatic choices not based on popularity are quite different things.
The latter got a lot worse. Along with React came the rise of evangelists, celebrities and their courses and a generation of developers raised on the idea that github stars are the ultimate measure of software quality. The jQuery era was peaceful by comparison!
I think if you let what lives in your toolbox define you as a developer, you’re selling yourself short.
If you’re a decent engineer, learning a new library should be the boring part. It’s not like any of these libraries are introducing highly specific conceptual paradigms.
Individually or in small projects you might be able to do whatever you want. Won’t help when you work in a large team, going against hundreds of minds inclined to follow trends and maintain the status quo, which is reality at almost any business.
The average developer doesn’t get to choose at all. This liberty was taken away from them in the name of “easier maintenance”, a “larger
community”, “stability” (ha) and other ill-informed platitudes. This became a self-reinforcing cycle when companies started hiring for React experience.
To me, enshittification also includes the feature bloat that comes from product managers and designers having to justify their salaries, which slowly turns things that were once lean and elegant into sluggish UI goop.
And that perfectly describes what is happening to frontend development.
> We have so many frameworks that you can switch to if React isn't your cup of tea.
Yes, that is what I was alluding to by calling it a "revolving cycle": Dominant Framework A is a bloated mess -> Framework B appears, it's lean and a joy to use -> Developers switch to Framework B, it becomes dominant -> Framework B gets enshittified into a bloated mess -> Framework C appears, it's lean and a joy to use
Happens everywhere in software, but in web frontend dev, it happens a lot more quickly.
yeah early releases made intermediate stuff very lean and fast (as a user), more so than ad-hoc event based vanilla/jquery logic spread around (good luck tracking dependencies).
but I admit something is off with react somehow (and i'm pretty favorable to it usually).
Something seems off because marrying HTML, CSS, and JS is a complex abstraction and with trade-offs. Then you throw in SEO, so hydration gets created. Then JS can be used in the server too so you have to manage both states. Then, users don't want a blank screen, but a loading screen so they know the website is working.
Before you know it, you've created a whole new paradigm that has it's own sets of new problems, even those solved by the original HTML/CSS/JS model.
I loved React when it first came out. I never got into MVC frameworks like Backbone or Angular because they felt too heavy, but React came as a promise that it was only the View layer and that provided a lot cohesion, as you say, compared to too much jQuery.
But now it just feels so heavy and that the initial elegance has been lost to history entirely.
The amount of rope it gave to hang yourself. Hooks were the harbinger of the sad state that what was to come.
The OG React was a breath of fresh air because it introduced the world to immutable data flow. The component model was dead simple. You had a fat (for better or worse) class that served as a management point for your side-effects and IO, then a bunch of stateless transformation functions / components.
The old class + lifecycle methods imposed a much needed friction on the development process. Their clunkiness was a feature (imo). It raised the cost of creating stateful components / performing side-effects wherever you wanted.
Then hooks showed up. In a lot of ways, it feels like React is now rediscovering the bad parts of OOP: uncontrolled mutation and side-effects. "Immutable data flow" means very little when everything is launching side-effects, updating some global store, modifying 12 layers of caches, writing to local storage, etc. etc. etc. etc.
It became a complete nightmare to reason about what an application was actually doing. Most of my experience with React (at least as of a year ago) was debugging performance issues, or UI quirks from component A clobbering updates from component B, because some special GraphQL caching magic modifies some global cache somewhere in some provider, which is 37 layers removed from the code you're actually looking at.
>It became a complete nightmare to reason about what an application was actually doing.
And anyone with any kind of software experience knew this was going to happen when hooks were announced. But the community bought it wholesale and dove in head first, so the rest of us were dragged begrudgingly along. I think it's been long enough now to resolutely say it was a bad idea and should have never been pushed the way it was.
The last paragraph hits close because I've experienced a similar issue recently. It turns out some component library was responsible for excessive rerenders even when idle (eating up the daily quota of read operations on some database for a small project).
As a stopgap, I just made a completely unstyled alternative to that internal admin dashboard that uses Handlebars HTML templating (no Javascript) on the server. Inclined me towards dependency rejection (which is an approach I was already taking for some side projects).
Last time I wanted to make a simple static webpage, I thought just HTML/CSS would be enough. My friend wanted some background images that don't become stretched or cropped no matter what the window shape is. If there's some way to do this with CSS, I couldn't figure it out, while it was straightforward in React. Just took the window dimensions and calculated div sizing based on that. Even better, when we decided we actually wanted to use more vertical images when loading in a vertical window (perhaps a smartphone or a split window), that was easy in React.
I feel like HTML had a lot of assumptions around desktop PC usage.
I'll make one when I get home. IIRC: You'd scroll down vertically on the site, through divs with different backgrounds. The initial HTML/CSS approach was nothing special, just adjacent divs with background-image with background-size options, and I tried other tricks to no avail. The React approach was useWindowSize(), set div width to 100% or the screen width in px, set div height to (image aspect ratio) times width, set `background-size: 100% 100%` or the exact div width/height px.
Either ChatGPT has gotten better or I gave it a better prompt this time. It suggested this padding-bottom hack that sorta works but requires hardcoding aspect ratios, which I didn't want, but at least it demonstrates the layout we wanted with a Windows XP Bliss background image example:
The height of the container is governed by the height of the image (until the text becomes taller than the image). You still have fully fleixible in terms placement (place-self) and/or sizing (height: 100%) of the text container.
Yeah, that worked, thanks! I didn't think to try that, probably because I don't typically go towards absolute positioning (I'm sorta n00b), but it makes sense now.
Using grid like this isn't absolute positioning, we still have implicit sizing and regular document flow. We're just assigning the elements to the same grid area and letting that area be sized by its contents.
That results in empty bars on the sides or top/bottom, which we didn't want. We wanted the div to resize to match the aspect ratio of the image. Realized my above comment wasn't clear about this, so I edited it.
Well HTML/CSS needs to do a better job luring then. The React way makes a lot more intuitive sense.
Then again my friend somehow got lured into installing Bootstrap.js, some React router, and frikin Redux to "solve" this before I told him no. But it's not like he understood what any of that did.
When I first learned react and web programming, I was very confused about this! React was advertised as fast! From reading react docs, articles, tutorials etc. There was a concept called "fiber" that was around the corner that would make websites even faster; it had demos where pixels would dance around the screen. I didn't grasp what made it faster, but assumed it was doing some binary magic in the web browser!
I learned more, and ended up writing my own react-like framework in Rust/WASM. (Seed).
Now, I program in HTML, CSS, and JS. If the project triggers a certain complexity threshold, I'll bring in TS.
What exactly is a react like framework in wasm? Your wasm is going to end up calling the same dom updating functionality except with the extra IO overhead. I can’t imagine that’s going to perform better. This doesn’t even sound like a good use case for wasm.
Yep. The tide is turning fast toward Vue these days. React died with the departure of Abramov. It's been over 2 years since the last major release, and 19 just screams nonsense "makework" incremental stuff.
That doesn't refute what the GP is saying. "Tide is turning" is about a rate of change; that site only presents a snapshot of the current state of things.
Not saying you're wrong, as I have no evidence either way, but a more useful measure to see what's happening would be a plot of the numbers of React and Vue sites over time.
I stopped paying attention to web dev for a few years, and those were the years when everything went from hand-written HTML + JS (+ PHP/ASP on the server side) to the likes of Node and React etc. You can imagine my confusion when I checked back in.
I'm dipping my toes in now for the first time since then, and I gotta say - I don't hate it as much as I thought I would. Yes, you can end up with library soup if you're not careful, but a lot of what used to be difficult is now quite easy. There's been genuine forward progress, and it's really nice to see.
(Though there does appear to be some kind of allergy in the web dev space to describing things intelligibly. It's never "XYZ is a stateless UI library built in TypeScript", it's always "XYZ lets you build bleeding-edge shardable solutions in the Web 3.7 space using YAML elem-nodes called 'qooms'. Let our bosomy anime mascot walk you through our getting started guide by simply piping this Discord link into a superuser shell")
You're dipping your toes back in at the right time.
IMO a lot of criticism aimed at frontend development is latent cPTSD from a bygone era but things have really come together over the last half decade. NextJS and friends are bloated, but that's nothing to the shit-show that was Webpack et al. Now that that's mostly over, next-gen tooling like Vite make the development process a lot easier.
CSS especially is a lot better than it was a decade ago.
I knew we were going off a cliff the moment GitHub did their big client-side rendering rework and made it effectively impossible to review large PRs in the web UI.
This has all become too complicated as is traditional. Every JS framework I have ever used ultimately suffered the same fate. The only web framework that works long-term is whatever is documented on MDN.
Something approximating PHP + AJAX has always been the correct path. If you are doing things like shipping DOM across websockets, I think you may have missed an important step somewhere along the way.
I would like to see a “framework of opinions” somewhere. 0 actual software, just documentation for standard JS and browser APIs organized in a way resembling framework documentation.
The current style of web platform documentation tends to resemble a big list of objects, or the most basic and slowest introduction to web development possible.
Something in-between, with chapters like “templating” or “data fetching” that focused on some opinionated but framework less structure, would be nice.
This is a cool idea. If I read it correctly, are you suggesting that MDN create a parallel doc tree, like "web apps", that introduces HTML/CSS/JS with the specific aim of building vanilla web apps? I am sure that it would be popular.
Yeah! Though a similar tone to framework documentation, so it would have to declare some opinions on things (Templating must use the <template> element and custom elements, data fetching outside of the initial load must use fetch(), etc) and the surrounding glue code you have to use to compose all of these APIs together is described to you. (rather than just describing the APIs, like most of MDN's docs)
I think there's easily enough API surface area to cover every part of a front-end web application without any dependencies.
As a former fullstack developer who has been fulltime on infrastructure for a decade now and reading these comments, not only can I barely follow half of the conversations but they're so far removed from the fundamentals of sending data between two places over the wire that I'm extremely satisfied with the career choices I've made.
Not really. The whole point of ssr alongside react 19/rsc is exactly abstracting the idea of "sending data between two places". You're sending html and removing waterfalls by moving data fetches to be as early as possible
If you don't want an interactive website, sure, just do everything on the server. That's a fine decision. Most of us work on apps where interactivity is a must
Real question: Does modern Gmail use a web framework, like React? My assumption: Gmail has been reimplemented multiple times over the years to adapt to web app changes, but the end user feels very little difference (except speed?).
And Gmail is still absolutely dog shit at performing basic features that have been table stakes for email clients since the 1990s. Specifically mass moving/deleting/filtering emails.
Every company I work at that uses G-Suite has me begging for Outlook even though I haven't worked with Windows professionally in over 15 years.
That's really the distinction the whole "just use HTML + serverside" crowd glosses over.
As soon as you have the need for complex UI interfaces (anything beyond a multi-select box and modals) in the browser, which almost every serious SaaS app requires at some point, you're going to need complex JS components.
I still think its crazy to use React/Vue beyond very isolated components of functionality and 100% simple server side should be the default unless absolutely necessary. But that's why the frontend industry is already moving to 'islands' of complex JS that is SSR by default.
That said, there still seems to be a high burden of adoption of SSR "islands", where you have these complex frameworks like Rewind/Next that still assume React/Vue as the composition of server side views instead of just pieces of the page.
Which is probably why so many sites end up with a TON of JS views that are unneeded. Because frontend devs are in their own world/dev enviornment. We really need React/Vue SRR+hydration that blends well into Rails/Python/etc frameworks without needing to commit heavily.
End users don't want complex UI interfaces, they want to use your product to find value as quickly as possible. You can have a crayon drawing interface as long as things make sense and there isn't friction from using the product.
Some UI gets this but often I find that most does not and that's the most common complaint that I hear from company to company..."you have the most advanced product but I need to take a two month course to figure out how to use it".
Customers really just want to buy your product, do nothing and get money and the closer you can get to delivering on that experience, the better.
You will always get more value from building APIs and integrations with other products than you will from putting options in the hands of users, but the big players in industry know this and build big moats intended to keep you out rather than improve everyone's products and their customers happiness. The problem is as workers in this industry we've taken the money and been good soldiers rather than demand and enforce open standards that would benefit our day-to-day and society at large.
I haven't even started in on the darker side of UI/UX like dark patterns and "engagement". It's not like "Sam's Pizza Shop" or any other small (or even medium) business needs some super complicated UI/UX and building that out for them would leave them worse off. Complicated JS frameworks should be the exclusive domain of companies employing hundreds+ of engineers and even then you have the problems from the last paragraph. IMO if you choose to work on frontend and perpetuate all this behavior, you're part of the problem.
For ex our company routes phone calls and needed routing system that had 3 layers deep of hierarchical organization, reordering, sorting, weighting, grouping etc.
You could have done all of those with a new page load every time, or spread out into individual static pages, but that'd take 10x longer for the user. I built something that did all of that in a box that fit into one screen and one page load, and only 1 ajax request for autocomplete search box.
Some things just demand 'desktop style' complex browser UIs that server side simply can't provide...
Which is why every serious company that makes $$ uses it. Backend devs like to pretend they can throw the baby out with the bath water and call it day, then deliver poor UX because they limit themselves artificially, just because some people abuse JS.
None of what you did requires vite or nextjs and all of the tooling that comes with all of that.
And then in three years when the undermaintained bit of software needs to be updated the entire landscape has changed in the JavaScript world 4x over already and the tooling needs to be entirely redone along with the desired change.
Again, nobody is saying "you don't need JavaScript". We're saying that the way you folks are going about it is Hell's Treadmill.
At least if I have a languishing, old, unrebuildable bit of code on the server side, I can find some exploit to make it run my code changes without modifying any of the original code :D
> JS frameworks should be the exclusive domain of companies employing hundreds+ of engineers
Definitely not. All it takes is a few comboboxes, date/time pickers, or literally anything wanting client state, to deliver a FAR better UX using js than pure html. If you tried building the kind of experience expected by today's consumers without js, you would know. People have very little patience for mediocrity on the web
And every single fancy UX JS tooling to provide those features utterly fails to do so in a way that's compatible with screen readers to be usable by people with visual impairments. Things like fly-out menus can be completely unusable by people with tremors.
ADA lawsuits against websites are massively on the rise (I worked in the early stages of WCAG compliance and helping people seek to bring such lawsuits).
You don't need all that fancy shit to deliver something that works and every time you go overboard with it you're alienating someone...
Edit: Also, wth? Every browser supports showPicker() and you can control and style the crap out of that without pulling components and frameworks into the mix. Nobody's saying don't use JS at all here. You don't need teams of engineers, components and a whole frontend build toolchain to put forms on a basic website. THAT is the complaint here. Not "caveman think JavaScript bad".
There are excellent options for building accesible stuff in the frontend world nowadays. If somebody is building something that is not accessible, the issue is not with the tooling
To a certain degree that is true, but they're also much more replaceable.
Not only have I seen multiple organizations lay off entire frontend groups, but as time goes on I work with more and more people who specialize in only this end of the stack and need people like me to wade in and solve actual problems for them.
Under the hood I know how things actually work and I can quickly get up to speed on their issues, whereas it's not always so easy going the other way.
Also if I had a dollar for every time I had to help web engineers "figure out" why the Sentry p95s are so high when sending large binary blobs on multiple round trips between Eastern US and Japan, I'd be a rich man.
TLDR: Don't do data fetching in your components if your care about performance. Hoist it up to the route, so you don't have to wait for deeply nested components to render serially.
The frameworks aren't the problem, it's their authors. There's a virus in the JavaScript world that makes people think ever-more complex solutions make tools better. After years asking "why is it like this" (I'm a JS dev/framework author), I realized this is likely due to an inferiority complex because hearing "real programmers don't use JavaScript" makes people feel bad so they try to compensate with complexity and end up creating messes. That and complexity pays well.
I rewrote one of my apps in vanilla JS to get the most performance possible, the wheel I had to reinvent is under 150 line of code [1], definitely worst the small cost [2]
Since the author doesn't appear to understand the difference between the Internet and the Web, and thinks that React handles internet traffic, I think it's fair to assume that the rest of the article is going to be a hot mess.
Their rational was pretty solid in the PR, but seems they overestimated how ready the community is to embrace newer best practices and they are back tracking.
[1] https://github.com/facebook/react/pull/26380