This is an absolutely perfect take on what’s wrong with front-end web right now. I've been trying, and failing, to explain this at work for several years now. Indeed, swimming against the cultural tide is hard.
React is built on two fundamental ideas that are both extremely valuable. The first and most transformative is that the web is mostly made of _components_, and specifically that organizing the markup, javascript, and CSS makes many thing easier. The second idea is that _declarative programming_ is better than imperative.
The thing is, HTML and CSS are already declarative. So React is not inventing this, nor bringing it to the web, but rather providing a pretty solid idea for how to make Javascript (or more generally, complex interactivity in the browser) declarative as well.
Thus, as MacWright argues, there is a sweet spot for React (or similar libraries) where you have highly interactive, complex UI elements on the screen.
But the rest of the web really, really doesn't need it, and when you try to apply "React Everywhere" things get very bloated, slow, and complicated, very fast. This is _especially_ true if you didn't start from scratch with Next.js or create-react-app, but are incrementally converting an established application. It's just painful.
I think more and more people are realizing this, and the fact that Dan Abramov himself agrees is pretty indicative that the tide is going to turn. But the question is, what next?
One major problem that the author didn't go into is the special pain of bundling front-ends these days. The actual work of setting up and integrating a "modern" javascript asset pipeline with a server side framework is not trivial, and I've yet to see a framework nail this. In the ones I've used there's always some gotcha - if you don't roll your own web pack (and understand what every bit of it is doing), you will eventually run into some library you want to use that just won't play nice with the rest of your bundle, and then you have a problem. And on the JS side, even simplicity-focued tools like Parcel are SPA oriented, thus gluing them together with your server-rendered app is non-trivial.
I think that will remain an issue for a while. But it also means there's an opportunity for the "old school" frameworks to keep working at this and, if they really nail the bundling and server-rendered / reactive component handoff, to thrive in the next decade of web development.
React is built on two fundamental ideas that are both extremely valuable. The first and most transformative is that the web is mostly made of _components_, and specifically that organizing the markup, javascript, and CSS makes many thing easier. The second idea is that _declarative programming_ is better than imperative.
The thing is, HTML and CSS are already declarative. So React is not inventing this, nor bringing it to the web, but rather providing a pretty solid idea for how to make Javascript (or more generally, complex interactivity in the browser) declarative as well.
Thus, as MacWright argues, there is a sweet spot for React (or similar libraries) where you have highly interactive, complex UI elements on the screen.
But the rest of the web really, really doesn't need it, and when you try to apply "React Everywhere" things get very bloated, slow, and complicated, very fast. This is _especially_ true if you didn't start from scratch with Next.js or create-react-app, but are incrementally converting an established application. It's just painful.
I think more and more people are realizing this, and the fact that Dan Abramov himself agrees is pretty indicative that the tide is going to turn. But the question is, what next?
One major problem that the author didn't go into is the special pain of bundling front-ends these days. The actual work of setting up and integrating a "modern" javascript asset pipeline with a server side framework is not trivial, and I've yet to see a framework nail this. In the ones I've used there's always some gotcha - if you don't roll your own web pack (and understand what every bit of it is doing), you will eventually run into some library you want to use that just won't play nice with the rest of your bundle, and then you have a problem. And on the JS side, even simplicity-focued tools like Parcel are SPA oriented, thus gluing them together with your server-rendered app is non-trivial.
I think that will remain an issue for a while. But it also means there's an opportunity for the "old school" frameworks to keep working at this and, if they really nail the bundling and server-rendered / reactive component handoff, to thrive in the next decade of web development.