It's increasingly harder to find non-legacy single page apps that aren't using React or Angular (Vue and Ember are distantly trailing behind). Corollary: it's increasingly harder to find jobs for anything other than React or Angular.
After technology du jour becomes popular, people will use it not because it's good or even necessary, but because it will ensure their employment. And then the rationalizations sink in afterwards.
I think it's a much more important skill to acknowledge that you don't need things like microservices, node, and react when you can deliver a simple, robust solution without any of that stuff.
Believe it or not for many managers "I refactored something and fixed the problem in an hour" isn't very desirable. When you go to your next interviewer they won't be impressed either, though they absolutely should be.
> Why we switched from Mongo to Postgres
Wow, no shit. A database that was made 21 years ago and is still maintained is actually better - who would've guessed?
There are learning curves, inner platform effect (have to do the framework way of doing things), major breaking changes and outdated information, opinionated authors you may not agree with, huge dependencies for users to download, performance bottlenecks and gotchas arising from not using the framework properly or even the framework itself is slow. These things are basically guaranteed.
It is also hard to explain that you can pick up their framework (e.g. switch to Vue.js from React), many companies just say "no" unless you can provide strong experience. Some companies have better policies and they insist only on core knowledge and principles, but, unfortunately, I personally find them to be in a minority.
Most of the web apps that are being built today have no need for a complex front end and, if they do, it's only in a few places. But, as you quote, programming is pop culture, so every new Form => Datastore app is going to be built using a toolchain more complicated than quake was built with.
Wouldn't that also be the case if, for example, React/Angular were demonstrably superior technologies to the alternatives? groupthink doesn't have to be the only explanation.
PHP is a massive player... despite incoherent implementations, inconsistent name spaces, glaring holes in functionality...
Both of those are popular not because they are the "Best"... but because they are popular. They came out at the right time and got the momentum in the right spots.
Granted... some of that might be my own opinion, but those languages have MASSIVE issues and shortcomings. They aren't at the top because of "demonstrable superiority". They are at the top in spite of the issues.
The reason they got popular because they solved a need, if I am not mistaken making dynamic web pages was a pain before PHP, PHP made it easy.
The "best" language is useless if most devs find it hard to use.
Utter nonsense.
Developers use these frameworks (a) because they like it, (b) because there is a wealth of knowledge on the internet about how to fix every little problem, (c) because it allows them to be productive with their peers and (d) because often they learn something new. People get bored doing the same thing over and over again for 30 years like you seem to be advocating for.
Imagine going to a doctor and getting a prescription because "they like it".
>there is a wealth of knowledge on the internet about how to fix every little problem
Let's hope they're using the same version you're using.
>because it allows them to be productive with their peers
Productivity without a framework must be impossible...
>they learn something new
They learn something about the framework at the present time, which may be worthless after the next breaking change, and is not generally applicable to the web platform itself.
I have some very troubling news for you...
You are underestimating the appeal and intellectual stimulation gotten from learning something new regardless of merit.
Right now at my current employer "we" are about to embark on replacing our entire data pipeline with a very popular queuing system designed to process hundreds of GB or more of data per day. Our current pipeline moves a few tens to hundreds of MB per day (not second, minute or hour) from the point of intake to our internal data stores. There are two reasons as I see it for the choice: resume driven development by the "architect" who proposed it (and management who want to put the management portion on their resumes) and laziness to address other issues regarding why there are delays at certain points in the pipe.
Before criticising something as "resume driven development" it might be better to actually have a detailed conversation first.
Languages and frameworks are how programmers communicate with each other. The same argument could be made for the English language. Developers will naturally congregate around common language because there is value in that. It's wrong to dismiss that value proposition as mere pop culture.