> If that would be the case there wouldn't be the flurry of JS frameworks which try to "fix" the DOM
jQuery was a part of the generation that tried to "fix DOM manipulation" which browsers now have caught up to (hence you don't see jQuery as wildly used anymore).
The problem the frontend ecosystem is trying to address right now is the scale of architectures of code, and managing complicated state.
People don't chose JS framework depending on how they mutate/read the DOM, they chose JS framework depending on how it handles complexity around mutating state and that it gives them Good Enough patterns for managing bigger code bases.
Well, except when it's chosen by cargocult, which is probably most of the cases.
Strange then that frameworks advertise how fast they are at rendering, mutating, and creating objects in the DOM, and one of the main JS benchmarks everyone likes to measure their performance by is literally a benchmark about DOM manipulation: https://github.com/krausest/js-framework-benchmark
Oh wait. It's not strange. Because state manipulation is a largely solved problem, and even the least performant state manipulation is blazingly fast. However, presenting components in the browser's DOM is tens of magnitudes of orders less performant than anything you can throw at state manipulation.
And every single framework is busy solving one single problem: how do we touch the DOM as little as possible?
Which popular frontend framework advertise their DOM mutation speed on their frontpage exactly? Most frontend frameworks I come across nowadays advertise their developer experience and their features, not their DOM mutation speed.
And when I say state manipulation I'm not talking about performance, I'm talking about the architecture and people working with the codebase. No one cares about state manipulation performance because as you said, it's a solved problem.
What do you think words like "performant framework for building web user interfaces" (Vue), "rendering is blazing fast, because Lit touches only the dynamic parts of your UI" (lit) and similar mean?
No, they don't mean "our architecture and state manipulation".
> No one cares about state manipulation performance because as you said, it's a solved problem.
Indeed. That's way in any modern all modern frameworks, without an exception, the main focus is how to touch the DOM as little as possible because it's slow as molasses.
From your own example, here is the text from https://vuejs.org/ as of today:
> The Progressive JavaScript Framework
> An approachable, performant and versatile framework for building web user interfaces.
> Approachable - Builds on top of standard HTML, CSS and JavaScript with intuitive API and world-class documentation.
> Performant - Truly reactive, compiler-optimized rendering system that rarely requires manual optimization.
> Versatile - A rich, incrementally adoptable ecosystem that scales between a library and a full-featured framework.
Yes, performance is mentioned. But it's hardly the main selling point, and they don't even mention DOM manipulation, they're talking about the rendering in general.
Lit isn't even a framework, it's a "web components library".
> all modern frameworks
Yeah, "all modern frameworks" being one framework + one library?
Or, as most people in the frontend space [1], you only understand the absolute surface level of the technologies you use? And unless it's spelled out in the exact words you expect, you don't understand the concepts?
[1] I'm a frontender myself, and the amount of people I meet who don't even have the most basic understanding of the tools and technologies they use is mind-boggling.
jQuery was a part of the generation that tried to "fix DOM manipulation" which browsers now have caught up to (hence you don't see jQuery as wildly used anymore).
The problem the frontend ecosystem is trying to address right now is the scale of architectures of code, and managing complicated state.
People don't chose JS framework depending on how they mutate/read the DOM, they chose JS framework depending on how it handles complexity around mutating state and that it gives them Good Enough patterns for managing bigger code bases.
Well, except when it's chosen by cargocult, which is probably most of the cases.