Counterpoint: These tools add complexity, and you don't need them. If you step out of the system and look in, you see madness. The problems they solve are created by other tools; they are problem-generating systems.
That's like saying the Unix philosophy adds complexity because it dictates a tool should do one thing well. Composition of tooling (consisting of many individual tools) is the basis for lots of rock-solid stacks.
I don't think the Unix philosophy is universally correct either, but "too many tools" is a complaint without much consequential basis. It's an aesthetic problem not a functional one.
The unix approach works because the tools themselves almost never change and the platform doesn't change either.
Web tooling changes, and the web platform changes. The more tools you use, the greater your risk. If something changes and you coupled 100 things together, you have to do a lot of changes. If you control it and delegate stuff to standard browser functionality, you have to do less changes.
There's also the issue of tools going out of date and being deprecated. Again, that's risk.
I am speaking specifically to examples used in the article, and related web dev paradigms that are popular. In the general case, there are tradeoffs to be made when adding tools, libraries, additional code of any sort to a work flow. In the case of web dev, adding these are bad tradeoffs.
You don't have any concrete complaint beyond the number of tools, and the nebulous idea that solving the problem each addresses within a smaller ecosystem would be somehow better.
Removing ESLint means... you don't have a linter. It doesn't have an upside. Removing Tailwind means you need to write more verbose CSS. Removing Babel means you have to use older JS idioms for browser compatibility. Etc.
I don't think complexity comes just from the number of tools, but the disparate things you "need" them to do. Redis, Vite, large CSS toolkits -- you're learning a bunch of large components.
I mean complexity comes from many places, but compared to the 'Unix philosophy' most of these tools are quite large. Obviously, there's quite a bit to learn about the way a *nix OS works, but if you treat tools as small and composable for simpler interfaces it helps a lot.
The web dev example of pub/sub is funny, because chances are if you're using Rails your primary DB (probably Postgres) already has a pub/sub system in or. Or you can just use any RDBMS for your job management system.
Not really I guess. Of course some tools are not mature, but many are mature and solid enough to solve real tech tasks.
Real problems are not caused by tools / problem generating systems but by silly people who fetishize complex tooling for simple jobs. Tooling is chosen not by merit but by hype.
