Why I Hate Frameworks (2005)

The way I like to explain the difference between the two approaches — and therefore the two educational requirements — you are outlining here is the difference between being a software developer and a software architect. A software developer is focused on developing a certain feature or fixing a certain bug within the context of an architecture that's already determined, rarely making decisions about how to structure the overall data or control flow of a system or what abstractions the system uses, but accepting what's already there; meanwhile, a software architect is going to be making those more broad abstract philosophical decisions that form the framework of how further features are implemented.

This is not to suggest that there is a rigid distinction between the two — all software architects are going to also be software developers in the process of building an architecture, or when new architecture is not needed, and many software developers will occasionally act as software architects. Nor is this intended to suggest that the architecture of a software project must be planned out in advance with all of the concepts and data and control flow either — just that there are points in the process of developing software where these large-scale architectural decisions about what abstractions to use and the flow between them must be made. But there do seem to be two somewhat distinct "hats" people who program wear.

And interestingly, your argument also falls apart in the same way as the framework argument. It might make the average developer more productive on an average project. But most projects are not average, and neither are most developers. Everyone has some unique combination of strengths, just like every project has special cases that don’t fit within the box of a framework.

A framework is great if you don’t know much about the domain and just want to get something together quickly. But if you’re working on anything novel, then eventually you’ll bump against the walls of the framework. Hopefully you designed the project in such a way that you can break out of the framework for these inevitable special cases.

And I like frameworks! I’ve used a few in various languages and think they do a good job organizing the code for the basic cases. But every professional project I’ve worked on has eventually been trapped by piling workarounds on top of the framework to make it work for some unsupported or complex case, or an inevitable architecture fail which the framework has not considered an escape hatch for.

Just like developers and their tools. I have an IDE and nvim at work. The IDE has a lot of power for major refactoring and hinting features, and it’s reasonable enough for an untrained dev.

But it is very slow for the other 99.8% of my job where I’m not doing a big “find and rename all instances”. I am usually wading through a large project and jumping between files to try to understand a complex system. Once I understand it, I’m jumping between those files again to make my changes. All of that is much faster in a lightweight editor than an IDE. But I still open up the IDE every now and then to double-check some change that I made, or do those big fancy refactors.

> completely changes how you write your frontend

You can use it for only a part of your UI, and you can implement any parts of your UI that are embedded within react components without react as well. It doesn't lock you into doing things its way in any manner whatsoever, it is literally just a library with functionality that you can utilize wherever relevant in your app.

> completely changes how you write your frontend

JSX is not an integral part of react. It's quite feasible to use react without using JSX, and I have done so in the past in some of my side projects when I wanted to avoid setting up a build system for a while. JSX just compiles down to plain old function calls, and you can use those directly without JSX without any issues.

> (JS -> JSX with embedded HTML)

JSX doesn't really have embedded HTML, it's just syntactic sugar for plain function calls that only somewhat approximates HTML.

> has lots of react-* libs built around it

Which are usually either libs that implement a react component with react or just wrap some non-react library in a way that's slightly easier to use than using the library directly in an app using react, but it's not like that latter is impossible or even difficult.

> comes with a script initializing an app skeleton

Such scripts exist, but they are not integral parts of react and are by no means required to use react. React is just a library, and if you want to, you can use it without doing anything else except including a single .js file with a in your html file, even if the more usual way of including react in your project is a lot more convoluted.

You're conflating React the library with create-react-app which is a collection of pre-configured tooling for making SPAs. React on it's own is very much just a library with a couple functions.