So yes, maybe React was over-engineered for their problem. But I think they only realised they over-engineered their problem after having over-engineered their problem...
A better point would be "I used React to test-build an app then to build it again natively for speed."
--
As an aside, I do agree that React (and I'm extrapolating this to many of the web frameworks) have an incredibly steep learning-curve and onboarding cost. I'm an avid Vue fan and I've found the architecture around Vue 3's "single-page components" to have created so much technical debt and complexity that I spend more time debugging the build pipeline then actually developing. I still like the flexibility and acceleration I get with Vue, but Vite often leaves me feeling like I'm just fighting the framework... I guess I just miss Gulp.
I can only assume we’ve adopted the Reddit pattern of upvoting sentiment at this point.
I don't agree with this statement: "The best benefit to all of this, in my opinion, is that it allows more junior-level people build interfaces that they wouldn’t otherwise be able to build at all. I say, React has commoditized the web app development."
In my experience, React is pretty complicated for junior engineers who don't grok how the actual runtime works. On the other hand, what React has really enabled is for large frontend teams to exist and work together meaningfully. I remember the days of vanilla JS and large codebases. I can imagine that today those codebases would be easier to maintain and work on due to things we've learned and developed (thanks to React, by the way), but I still strongly believe that the productivity gains from React for a team greater than like, 2 front end people on a project that needs to be maintained for longer than 6 months is worth the effort.
I wish I were joking.
For others who might not be familiar, redux is a library you can add to your react project to help manage state. There are others but redux seems to be the most popular.
There are a lot of instruction abstraction layers that just aren't needed. Older games are a great example. I am still amazed at the size of the modern StarCraft, Rollercoaster Tycoon, or CS:GO executables with all the new layers of emulation and compatibility stuff. Sometimes even 10x the original size.
However, there are ways to use libraries like react (preact.js anyone?) without a dozen plugins and a huge runtime layer. Look at HTMLX, the new cool kid that was originally an XHR request that inserts document.querySelector(name).innerHTML = response and is now a large package of 145KB of JavaScript.
Part of the issue is the growth of these frameworks and part is that the developers don't know how to use them in performant ways. They're just trying to ship stuff, performance is optional.
Building DOM is not a hard problem at all. Yes, it's more tedius with Vanilla DOM. But that's not a hard problem.
Hard problem is making it fast, reliable and predictable.
When the whole premise is flawed, JSX or not, does it really matter if there is a better or worse way of misusing a technology not meant for UIs?
Leave HTML and JavaScript to Wikipedia and other hypertext document libraries.
Unfortunately, WASM is not there yet, but people are trying: https://platform.uno.
This is distinctly the opposite of my experience. Being able to reuse common components makes logic encapsulated. The browser sort of has this with custom elements, but that adds its own level of complexity.
React, despite everyone's best efforts with CRA and other tools, is hard to get up and running with. It just takes time, and you inevitably need to eject. But once you codebase gets big, idiomatic React (at least in every case I've worked with) is much easier to scale than rolling your own everything.
Is this article written by a marketer ?
Of course one could argue that Javascript itself doesn't allow much control over performance.