Svelte's main point is that the performance claims of frameworks like React are just bullshit marketing-speak. That I agree with it. The value of JS UI frameworks in general, isn't in performance, but rather to provide a "declarative, state-driven UI development" because raw JS/HTML/CSS development is terrible and makes it easy to make terrible architectural decisions and write unmaintainable spaghetti code. In this way, whether you go with Vue or React or Angular, it makes no effin difference to performance.

But yes, there is overhead in managing the virtual DOM and yes, you can get yourself in trouble if you don't structure your application in line with how the framework expects you too.

>React sold us the idea that the virtual DOM could give us a better programming model and still outperform the template based frameworks of the day.

React made a stronger claim. It wasn't just about React vs some Templating framework. React tried to argue that direct DOM mutations are expensive and that using virtual DOM will yield more performance. As a general claim, that is a bullshit claim.

>Their alternative is to add more complex compiler steps, which I’m sure could work great. However it’s awfully dogmatic to suggest that this is better simply because it eliminates one kind of not-strictly-necessary overhead.

And it's not a bad argument. The DOM is an abstraction and the underlying implementation is highly optimized. DOM mutations are not the expensive thing, it's the final render, and that part has had an enormous amount of work done to make it smart and fast. By the way, Flash had a great built-in rendering model. The Flash display list hierarchy was very well architected and it wouldn't re-render the entire page if only a part of it changed.

>But this isn’t how you sell a framework to programmers, in my opinion.

Claiming your framework is faster than the other guys IS how you sell a framework to programmers. That's how React and Vue were/are being sold.

My impression is that it's the kind of claim that's actually true in general, despite being false in all the particulars.

Like, every step of the way, yes, virtual DOM adds extra steps to the process, and they have a cost. But, in the big picture, if you're manually manipulating the DOM then you're liable to just swap out entire chunks of the tree rather than making surgical manipulations. Because manually managing all those surgical manipulations would quickly become a fiddly, unmaintainable mess. But, if you do it that way, you're asking the browser to do a lot more re-rendering, and that would be costly.

I worry that this conversation falls into the same trap that most performance discussions fall into, where we quickly become focused on what things would be like if people had unlimited time to chase the best-case scenario, rather than what things are like for the 99% of us who are just trying to get something that works acceptably by the next deadline.

> As someone who has written fiddly DOM manipulation code, no its not my preference over React JSX, but having the level of understanding TO write surgical DOM manip code should be a basic floor of ability for any web developer using react or otherwise imo.

I'm not sure I agree with this. Basically, it requires a much higher degree of experience and skill to write DOM manip well. There aren't really great resources that I've seen, because it's all very context dependent and something you learn over time. We used to send people straight into the DOM when they wanted to make a simple app, and the result was a lot of huge unmaintainable messes, security nightmares, and poor performance.

The value of React is that you can just follow the docs on reactjs.org that will give you a mediocre default. If your needs go beyond that, you can get a more skilled person to come in and improve the critical parts. The world's need for web apps outstrips the supply of highly-skilled, highly-experienced developers, so it makes sense to have libraries that lower the bar.

Turning things into JavaScript-heavy single-page applications has, I would assume, an effect of shutting out people who are good at HTML+CSS, but less so at JavaScript. I don't know how likely a profile that is nowadays because I'm buried deep deep deep in backend-type work, but it used to be fairly common to have front-end people like that who were stronger on design than programming.

Is this a form of unwitting rent-seeking behavior? Has the profession created an artificial supply-and-demand problem by convincing the managers of the world that they need expensive single-page applications built by Software Engineers™, when a (less expensive, I'm assuming) Wordpress site developed by a web designer would have sufficed?

For context on where I'm coming from: I've mostly been a back-end developer for a couple decades. I've known HTML and CSS since the '90s, of course, I'm just now starting to learn Web development in earnest, mostly as a hobby. I'm finding React's learning curve to be just incredibly steep. For the stuff I've been doing, I've had a much easier time getting acceptable (to me) results out of a more oldschool-flavored tech stack, with server-side templating and a moderate sprinkle of vanilla JS. No, it's not fancy, but I'm not looking to flex; I'm just looking to whack together a website that looks nice.

I'm not saying developers don't have an attitude problem. We often do. I just think you might be assuming malice where there might be none.

As a bootcamper who came from a philosophy background to frontend, you will be surprised how many 15 year "veterans" in web dev can't write coherent code without a framework, couldn't tell you how designing data one way or another impacts their code design, and when you confront them on this, bring it to their attention, they find any which way to dismiss the problem with "do we really need that"/"why do we need that" as if their's virtue in pretending to be the Product team in the face of shoddy engineering. Enterprise agile largely enable this fairly low floor. Engineers can handwaive anything in the name of the holy right now.

I agree with you in general, but I can’t agree with this statement. Web development needs fewer gatekeepers.

I don't particularly like React and I never used it, but I can see how it improves performance over naive use of browser APIs, because you can easily do things that are really bad for performance and require needless layout calculations when updating DOM manually, while tools like React will sort the updates in more optimal way without too much thinking.

This is neither here nor there. Some people write awful React code too.

> having the level of understanding TO write surgical DOM manip code should be a basic floor of ability for any web developer

I mean, knowing how to do it is good and all, but knowing how to do it well is a rare skill. There's a ton of random performance gotchas to be aware of (like, reading a property in the middle of a bunch of writes causing double repaints) and frameworks do consistently apply optimizations that you as a regular dev would probably not ever think of (sorting optimizations being some of the least trivial ones).

"Swapping out entire chunks of the tree" is in fact a very sensible choice given that the browser rendering pipeline is highly optimized and can run in parallel, whereas any v-diffing step has to be done in single-threaded, non-native JS. You also save on the overhead of storing the vDOM itself, which will be quite significant.

Not using react made everything work amazingly fine. Granted this was an application with fairly low amounts of DOM manipulation (popup things when the user clicks on stuff, some lists that elements can be added/removed to/from), but those sorts of things seem fairly typical.

I wanted to use React because the code was so much cleaner and concise, but it was just way too slow.

I've been hard on React in other places in this thread because I agree with the premise of the article that VDOM is not free and that the value of React is not in performance over raw DOM manipulations, but rather in code organization.

Having said that, React isn't bad either. That it was too slow for you, I suspect, comes down how you wrote and structured your application and not necessarily React. It's been a few years since I did any meaningful React development, but back when I did, React code was simple enough that it wasn't hard to understand and trace trough, or profile. I guess I'm curious, what the bottleneck was.

Interestingly enough, this was the opposite of my experience. For my next project I used Mithril because it was far easier for me to debug, trace, and profile through.

> That it was too slow for you, I suspect, comes down how you wrote and structured your application and not necessarily React.

I had on the order of 100 inputs with two-way binding. My code was structured along the lines of the existing react tutorial of the day (maybe 10ish years ago?). Per suggestions of members of the react community, I restructured it to use ImmutableJS to allow for faster VDOM diffing, which did cause a noticeable speedup, but was still dog slow.

One DOM mutation is faster than one VDOM-to-DOM flow, though, of course, since the latter's doing the same thing plus more. The latter also uses a lot more memory, and keeps it around indefinitely unless you want to risk performance-killing deallocs and allocs later (I'm making some assumptions there—I'd expect a typical VDOM implementation's memory is rarely released, since re-building that data structure would be high cost if you need it again and largely defeat the purpose).

VDOM's also pure JS in the typical implementation, which is going to tend to be slower and (much) less memory efficient than getting the fuck out of JS and into the browser's C++ or Rust or whatever, ASAP (React's, for instance, is a big ol' tree of JS objects, AFAIK).

If you're often modifying or inserting 10,000 elements per update and can't be bothered to somehow batch those yourself, virtual DOM is probably a performance win. If the count is typically more like 1-10, it's probably overhead. In between, shit, I dunno, benchmark it.

Virtual DOM comes with a different set of trade-offs in terms of needles and haystacks. If you have lots of mutations relative to the size of the DOM, then virtual DOM overhead per mutation is relatively low. But if you're only updating a single element in a very large tree, then you are incurring a lot of overhead per mutation.

Another modern confounding factor to be aware of is that some browsers (notably Chrome) have made it so that mutations through the DOM API no longer cause a repaint to block the main thread (which is how every UI system ever should work, really). What this means is that any performance benchmark that uses JS APIs to measure UI responsiveness is going to be problematic (either by not measuring repaints correctly, or by adding a ton of confounding factors by shoving the macrotime queue of setTimeout/friends into the measurement)

Also, qualitatively, there's different levels of overhead. A repaint takes in the order of hundreds of milliseconds (i.e. it can be noticeably expensive). DOM API calls are also "expensive", but only in the order of a millisecond or so; you do want to touching the DOM unnecessarily if possible and virtual dom helps avoid silly mistakes like re-querying the DOM on every event like in the `$('.foo').on('mousemove', () => $('.bar'))` anti-pattern. Virtual DOM is "overhead" in the sense that allocating memory for a virtual DOM node is "expensive" (compared to not allocating any memory). But we're in microsecond-per-instance territory at this point. You need large haystacks with very small needles at high frequencies in a slow device to experience human-noticeable performance degradation from virtual DOM object allocation overhead.

Not really. Rendering was always a heavily optimized area. The DOM, by the way, is also an in-memory data-structure, and can also be clever on how it batches draw commands to the hardware (GPU or otherwise). I was always skeptical of the performance benefits of frameworks like React for that reason.

The big benefit of UI frameworks (React or Angular) is that it organizes your code into a defined, maintainable pattern. Traditionally JavaScript has been a mess of a programming language so with raw JS/HTML development it was easy to shoot yourself in the face and do the wrong thing.

>I was under the impression that a lot of optimization was done in reaction to, err, React and similar frameworks?

That's not true. There is an enormous amount of investment being poured into the entire HTML/JS/CSS stack.

How so? It improved on JQuery's performance ten-fold which was the "easy" way to webdev at the time.

React, imo, is about the programming experience. "Thinking in React" is a lot more than just VDOM, and the benefit of "thinking in react" is about the developer experience not the pure benchmarkable output.

Svelte has been around for a few years now - and I've yet to see/hear about an application built with Svelte at scale.

The reason I think React works so well and is so popular atm is because it works just as well at a small scale as it does on a team with 5-6 active contributors (in my experience, at least).

That isn't to say that Svelte can't deliver the same wonderful experience at scale, I've just yet to see a truly shining example of it.

I may also be in the minority, but performance of front end frameworks is near the bottom of my evaluation checklist.

I've used svelte for some one off personal projects, just to get a feel. And it's fine but nothing about has convinced me to lead a project/team towards picking that over React, Vue, or even some SSR framework.

When you start or build a new product/team and can freely choose which Framework you want to use, you can have a look at Svelte.

For our company Svelte is easier to use, it has (in our opinion) less bloated code (e.g. state handling) in our app as React or Vue (which we used before). BUT, Svelte has other problems, especially when you heavily use dynamic components, which are easier to handle in Vue or React.

That React has better active contributers is one big point for React. But it depends on Facebook.

Do you have an example?

What do you mean 'at scale'. It's a UI framework that runs JS and mutates the DOM - there's no issues with 'scale' here.

That Svelte isn't popular is because some frameworks get popular and go viral and others don't. That's it.

This is complete and utter nonsense. Were you programming seriously before React? There were like 50 popular frameworks all competing with each other and no one framework dominated. React has completely taken over because it provided a dramatically better developer experience and solved a lot of hard and very real problems. As an incumbent it has staying power because there is benefit in sticking with the herd, it remains a pretty nice developer experience, and because it has essential features other frameworks don't really provide yet (React Native being the biggest one although I do realize other frameworks are working on this now too).

Svelt isn't popular because to disrupt a solid incumbent you need something that is dramatically better at solving problems devs actually care about (not corner case performance benchmarks when React is "good enough" 99% of the time). Svelt has failed to do that, plain and simple.

Dismissing Svelt's success/failure by saying all framework success is because of fads is an excuse and, if you are part of the Svelt community, maybe is a clue as to why Svelt has failed to be sufficiently introspective in either accepting it is a niche framework (which maybe it is great for) or that it needs to change if it wants to be more mainstream.

Indeed I was.

>There were like 50 popular frameworks all competing with each other and no one framework dominated. React has completely taken over because it provided a dramatically better developer experience and solved a lot of hard and very real problems.

I'm not saying React isn't a good framework, it is perfectly nice, though I think you're overstating it. AngularJS was a perfectly fine framework as well, and that was out long before React.

>Dismissing Svelt's success/failure by saying all framework success is because of fads is an excuse and, if you are part of the Svelt community

I'm not part of Svelt's community. I haven't actually used Svelt at all. I barely know about it. But I've been around for a while. Why certain frameworks go viral and others do not, is not always based on merit. I'll buy the argument that Svelt doesn't have enough of a benefit over React ... it also came out a few years later and doesn't have Facebook's marketing weight behind it either. Does that mean React is the best thing ever? Eh, it's alright. Having done everything from Flash/Flex/Starling, to Silverlight, to Backbone, to AngularJS, to React, I actually get more excited about State management patterns than widget overlays with some declarative patterns and data-biding. By the way, when it comes to ergonomics of building complex SPAs, I think we're just hitting the place that Flash/Flex was 15 years ago in Web Development.

And it still is. Mixing JS and HTML/DOM does result in fragile code and you shouldn't do it. React VDOM and JSX is not the same thing .. at all. Again, JSX isn't new. XML-based declarative UI frameworks with data-biding were an old thing by the time React arrived on the scene. That's how Flash Flex (MXML) and Silverlight (XAML) worked, for example.

It basically embodied the bad side of JS frameworks pre-React.

It managed to take alllll the wrong lessons from Flex.

Svelte vs React on a single side project I work on in my free time by myself is different conversation than Svelte vs React on a team that's moving fast and has more than a single dev.

I understood what you meant, I just disagree that this is a real consideration. Both are just UI frameworks following modern conventions in architecting your SPA code-base. From that point, both are just fine. Other considerations, like the fact that React is more popular and therefore more likely to be supported in the future, and therefore has more devs familiar with it, are way more important.

Large teams were using jQuery back in the day, with none of that HMR prettier-on-save Redux devtools fanciness. There's nothing inherently "unscalable" about the technology, especially now that most frameworks more or less use the same framework design paradigms.

> nothing about has convinced me to lead a project/team towards picking that over React,

This is just a cost of switching consideration. For better or for worse, first movers advantage is a thing. You're also not likely to switch from date-fns to dayjs or postgresql to mysql because you are invested into your choice of technologies, even though each pair might in theory be perfectly interchangeable.

Sorry to pick on this point but depending on your application this should be more (or much more) important. Too many teams have this same opinion and it's glaringly obvious how little they care about performance. I'd agree that raw performance isn't really important, but the ways you can and the tools you have to optimize the performance of the app are if you find that you have bottlenecks is and this does partially depend on the framework.

That said, I would agree, all frameworks would probably be fast enough for most use cases, and even with the optimization aspect arguably the most important aspects are about application structure and how the framework forces you to structure your application. As you mention, I think this is why React wins, the way it forces you to think about things unidirectionally, think about state and components separately, etc. are all big wins for understanding your application.

Also worth noting is that Svelte doesn't really have a big company backing it like React does and so the ecosystem is smaller, which could contribute to its relatively small size.

I've been working in React for ~4 years now, at all types of scale. While I've definitely seen performance issues, it's never been a case of a flaw in the approach the React takes.

I guess a better way to phrase my point - until I encounter a scenario where the performance is bad enough in React to warrant looking at other frameworks, choosing a framework based on pure performance is an over-optimization.

Of course, this would be a different conversation if React was known for being the one and only bottleneck in web app performance - but afaik that is a rare case.

One of the lead developers of Svelte uses it at the New York Times on some of their high traffic interactive data visualization pages, including their COVID charts.

I think what people mean when they say “at scale” is they want to see a large codebase, with a large team working on it, where Svelte is the primary front-end choice.

The part that I think the article misses is that VDOM is just an implementation detail of React. No one actually really cares about it, and its not the reason why people use React.

> It's important to understand that virtual DOM isn't a feature. It's a means to an end, the end being declarative, state-driven UI development.

I find this bewildering because it makes me feel like the article does actually understand React. It realizes it was faster than frameworks it initially competed against, it understands that virtual DOM is a means to an end. But then at the same time it is classified as a meme that only wins in performance against things nobody would ever do.

In a way, writing it like this makes it harder to critique.

At the end of the day, I've never spoken to a developer who was using React because it was fast, but because it was easy to use and understand.

Svelte’s approach requires detailed knowledge of the structure of state, and requires compilation: components’ <script> blocks are not written in JavaScript, but rather a language with the same general syntax but different semantics, and some places where JavaScript is too flexible to be tractable get replaced with special template syntax (like {#each} instead of for-loops or Array.prototype.map). Svelte cannot be implemented as a JavaScript library (I disqualify eval()). Svelte is also deliberately severely limited in what it can express in various places, whereas React gives you the full power of JavaScript (for better and for worse).

You could perhaps implement an optimising compiler for a small subset of React components that avoid problematic patterns and are written in TypeScript with proper specifications of the types of state and props; but if you considered it unacceptable for this compiler to change the component’s semantics, I think you’d be surprised at how little serious React code in the wild could actually be supported. Even simple loops might be out of reach. The Svelte approach can’t be a progressive enhancement, it’s an all-or-nothing (at the component level).

One could argue that React's hooks are the same: they look like JS but change JS semantics.

However, your point is still valid.

If Facebook comes up with something else, I think it will be something new. Maybe that is Reason, or something that abuses WASM/Rust in the core architecture. Who knows. The project has a lot of tech debt, and the ecosystem has changed quite a bit as well.

    It's important to understand that virtual DOM isn't a feature. It's a means to an end, the end being declarative, state-driven UI development. Virtual DOM is valuable because it allows you to build apps without thinking about state transitions, with performance that is generally good enough. That means less buggy code, and more time spent on creative tasks instead of tedious ones.

    But it turns out that we can achieve a similar programming model without using virtual DOM — and that's where Svelte comes in.

This is probably true today, especially for newcomers, but the article is from 2018 and the context of the time period is significant here, I think.

Having used React since around 2015, there definitely was an aire of "React is fast because of the Virtual DOM!" and it was one of its big selling points early on. I can remember reading this article and nodding along, but reading it now evokes more of a sense of "I remember when VDOM mattered". I think around that time was maybe the tail end of VDOM being a big selling point, and this article might've even precipitated that, to a degree.

As React's usage has grown, I think the significance of VDOM as a feature has fallen by the wayside in favor of things like "everyone uses React so we use React too." The competition between frameworks at the moment seems less about performance and more about their approaches and tradeoffs.

The article is about VDOM and nothing else. It does not "miss" the part about why react is popular, it simply does not discuss it.

Secondly, you're dismissive of the idea that 'the virtual DOM is fast' is a meme (in the original Dawkinian sense; I'm not talking about gifs with Impact-typefaced captions), which suggests you haven't spent a lot of time around developers on places like Twitter and Stack Overflow. This misperception _absolutely_ exists, and this article was written to correct it, not to 'sell' Svelte.

Svelte isn't intent on 'taking over'. We're quite happy providing developers with an alternative to React that enables them to write less code and not have to worry about performance. That said, I'd argue the 'irrelevant' label is somewhat unfair (https://twitter.com/swyx/status/1409529125539254277, https://2020.stateofjs.com/en-US/technologies/front-end-fram...).

Svelte performance is a nice bonus but it is the last reason I prefer Svelte over React. I prefer Svelte because it is truly reactive (unlike React) which makes everything easier, cleaner & more readable.

Svelte is the only framework you can grasp in 10min by just looking at a few examples. To get started, you don't even have to read a tutorial or documentation, the code is self-explanatory.

React is a complex beast and, in my opinion, all this is an overkill / overengineered environment for expressing UIs.

I find Svelte to be the only framework that "make sense". Ultimately UI is not that complex, it's a store -> derived variables -> UI where each step is a reactive function of the previous one. A framework should let you express this very concisely and take care of everything else for you.

If x = y + z then I want to write x = y + z, end of the story. Like in a Excel sheet, just write the formulas and that's it. No useStates, hooks, componentShouldUpdate(), and other wierd stuff.

Svelte is to React what Pluto is to Jupyter Notebooks, less popular because of legacy, but, in my opinion, obviously more elegant & cleaner

The state management in Svelte is fantastic.

I feel that way about a lot of articles like this. I want to know what you do well, I don't want to hear someone complain about something else.

Sell me on what you do well and what that means for me.

I work in React a lot and I don't feel like I run into this “pure overhead” type concept in the way they describe it and thus this article makes me:

1. Wonder what they're doing in React that they feel this way.

2. The article quickly becomes much less relevant to whatever it is I'm thinking about.

Because that is the topic of the article.

It never even says "The virtual DOM overhead is a problem". It actually says exactly the opposite, it's often fast enough and not a problem. It didn't call Virtual DOM a meme, it called "the virtual DOM is fast" a meme.

Performance wise, as the article says, it is pure overhead. Virtual DOM is the solution to a problem the javascript frameworks create themselves.

I've had argue against managers that no, using a virtual DOM will not magically make our pure JS app run any faster. Especially once I put in the work to make the DOM as seldom accessed as I could.

There is a fantastic reason these JS frameworks work that way. Instead of building creating and update logic, you just need creation logic and always rebuild the widget. But that's super slow, so you use a virtual DOM to make it faster. Just not as fast as it would have been if you hadn't used the framework.

The tradeoff being that your code is often significantly simpler and easier to maintain. Though that also breaks down in some parts.

I think you're interpreting their messaging as "Svelte's compiled DOM is faster than virtual DOMs ergo Svelte is appropriate for every application" whereas the implication is certainly "Svlete's compiled DOM is faster than virtual DOMs ergo Svelte may be a good choice for applications that are constrained by virtual DOM". I don't think it's a reasoning failure, but rather a misunderstanding (an inadvertent straw man on your part).

> Svelte probably hasn’t taken over because the real world isn’t synthetic benchmarks and most apps have more significant concerns than how many times a component can update per second - and even then, in my experience React is more than capable of doing a decent job here

I think this makes a fair amount of sense. Often an incumbent needs to be quite a lot better in order to justify the learning curve, and I'm not sure that Svelte is. That said, I've been part of a lot of Python projects because Python's problems don't often manifest for new projects, but rather at scale (real workloads suffer from Python's poor performance, development velocity decreases at scale due to type annotations, package managers crawl as the dependency tree grows beyond the "toy" category, etc). I wonder if perhaps there's a similar effect in which React is "good enough" for new projects but not enough for

> The irony is that Svelte compiles code that will then run on a JIT under a JavaScript engine. That’s strictly overhead.

I don't understand this claim. In order for it to be "strictly overhead" we have to assume that Svelte's compilation step has no benefit i.e., the output code doesn't reduce the JIT's workload but even more than that, the output code has no advantages (i.e., performance advantages) over React?

> I know this article is from 2018, but it never landed well for me, and Svelte’s virtually unchanged irrelevance should be some kind of cautionary tale. I don’t think there is anything wrong with Svelte. But this isn’t how you sell a framework to programmers, in my opinion.

The way you sell a framework to programmers is largely by the backing of huge tech companies who use it in large, noteworthy projects. That's presumably not an option available to Svelte developers?

Modern software commonly goes through multiple transformation (compilation stages) and it's increasingly common for some of them to be AOT, and some to be JIT, and neither AOT or JIT is overhead, even in combination. They have different pros/cons and in fact together you get the best of both worlds.

This doesn't negate your main point, but I wish you didn't end with an example of "irony" that actually is incorrect.

React gave us not a better programming model, it gave us an other programming model. In some cases template based enignes are better than JSX, but that discussion has nothing todo with Svelte or React.

React boomed cause at that time everybody has enough of bloated frameworks and with JSX you had a wonderfull thing to tinker code... thats what developers like, tinker all the day complex bloated code. Why made it easy, when you can have it complex? ;-) And it came from well known Facebook, thats it, nothing more.

I rememnber the day when everybody was shouting, Redux is the best thing every ;) And now "hooks" Really?

On their machines.

That's often a critical distinction. Developers often get the nicest computers, and they often get to have good, fast Internet connections that are close (in terms of Internet topology) to the server where the site is running. So they can't necessarily perceive the effects of the browser being starved for resources, or jank from the app being chatty over a high latency connection, or resources failing to load due to a spotty connection, or anything like that.

What some of these technical decisions add up to is situations like a family member who's using a cheap Chromebook and has flaky Comcast cable internet, bewilderedly asking me why this site they're trying to use keeps showing them a blank page or somesuch. They know that, if the page doesn't load at all, the browser usually gives them a, "We couldn't load that page. Try refreshing," error. What they don't get is that, if it's a React app and some JS resource fails to load, it'll stop the rendering of the site cold, and they'll just see a blank page, or a half-loaded page, or some other confusing state. And I've yet to figure out a way to explain things to them that gets them to see this as, "The Internet is being flaky." They see it as, "Your site is flaky."

They're not entirely wrong about that. The people who develop Internet and Web standards have put a lot of time trying to engineer the Web to tend toward failing gracefully. React (and frameworks like it) seems to have, in one stroke, undone all that and instead engineered things to tend toward failing catastrophically.

I don't know if you could get a JS-first framework that doesn't behave that way, so maybe it's a necessary evil? But, I get that React solves a real problem that some people have, so it'd sure be nice if it weren't.

You can keep telling yourself that React only took over because it makes things more complex and it came from Facebook, if that's what makes you happy.

And this, ladies and gentlemen, is how we ended up with web pages that lead modern mid- and even high-end personal computers grind to a halt.

a more catastrophic failure of reasoning, that is far more prevalent, is not understanding that virtual DOM is overhead on top of the regular DOM, not some magic fairy dust invented by facebook geniuses that just makes the web better (tm) because you are a dev whose first exposure to web development was via a React tutorial where you built some <popular app> clone as it held your hand every step of the way, and now you are loosed into the jungle of problems in the wild ready to crush the spirits of those old tired jquery devs. bwahahahaha.