This trope is so tired, and the reason for using the NPM/Node ecosystem has never been about talent being rare. Choosing JS at all is because you value developer time over time chasing down suitable third party dependencies, handling build incompatibilities, and generally dealing with the mess that is multi-platform development.
I think Javascript/NPM was just an example and that he was complaining about overengineering. There are examples of this in every specialisation (not just front-end) like the companies using Kubernetes when their entire workload could fit on a single machine.
As somebody who has been writing in these technologies for 20 years I disagree. The entire purpose of jQuery, for example, was exactly because talent was rare. Keep in mind jQuery was around for years before it was popular. It was its Sizzle engine masking the standard DOM methods that made it popular.
When talent is rare you can artificially widen the availability of talent by lowering the barrier of entry. Lower qualified job candidates are dependent on the crutches that allowed them entry, though, which comes at a cost of lost innovation potential and productivity overhead. The cliche don't reinvent the wheel is completely about developers distancing themselves from innovation. When talent is suddenly and explosively available to the job market there isn't a valid business reason to do that especially as companies have smaller budgets for hiring fewer developers and more developers are competing for fewer available positions.
You're implicitly equating making development easier with lowering the barrier to entry. If you make that assumption, then you could say that Boost does the same thing. To avoid this, you would have to never make anything easier to use, which is the whole point of tool development to begin with.
> there isn't a valid business reason to do that
This assumption is quite strange, because "don't reinvent the wheel" is usually a tenet of the more seasoned developer, not the junior developer. Carrying it out to extremes (leftpad) being another beast, usually junior developers will be the ones wanting to build something that already exists, generally for the purpose of testing their ability.
But in general the more senior people I've worked with are the ones who have the philosophies that boring is better, reuse existing solutions if possible, and don't do anything too new or in a novel way, because that is typically the road to knowledge siloing.
The term easier is highly subjective so I did not use that word on purpose for that reason, but otherwise the connection I drew between lowering the entry barrier and a superficial abstraction layer was pretty explicit.
I am not a C++ developer and I have no experience writing in that language. I know that Boost is a template system for C++. I know this because for a long time I maintained a multi-language parsing utility and was considering extending support to C++. I never extended that support to C++ in my utility but C++ developers who introduced me to Boost were absolutely confident that parsing Boost logic from a C++ code sample would be next to impossible. Its trivial. If you have experience with embedded languages that sort of multi-dimensional parsing is not as hard as it sounds. A more elegant example is JSX which is a pseudo-XML construct embedded in JavaScript that can recursively contain JavaScript in various ways which then can contain more pseudo-XML islands and so forth. There was also a jQuery template scheme that introduced psuedo-HTML into script tags of actual HTML.
Typically the goal is to make systems that are more simple opposed to more easy. Easy is a disorganized pile of spaghetti code because it took less effort to write with no prior planning. Cleaner and more organized code takes greater effort with fewer interesting parts. Easier is generally preferrable to entry level employees who don't yet have the experience to differentiate easy from simple.
> This assumption is quite strange, because "don't reinvent the wheel" is usually a tenet of the more seasoned developer
I absolutely disagree. This is what I call an experienced beginner. That is somebody who has been doing the job for a couple of years and has gained confidence with certain techniques and conventions, but has never grown to a level of sophistication or problem solving that most businesses would consider valuable enough for senior level responsibilities. This is the kind of thing that most people would refer to as Dunning-Kruger, because the expertise is limited to something designed for engaging beginners and that expertise is confused with excellence.
> But in general the more senior people I've worked with are the ones who have the philosophies that boring is better, reuse existing solutions if possible, and don't do anything too new or in a novel way, because that is typically the road to knowledge siloing.
There are all kinds of justifications for avoiding writing original logic and most of them are pretty weak. If it cannot be expressed in terms of project risk or financial harm the justification is generally a form of bike shedding. That means the developer is framing the conversation in a way their limits their uncertainty exposure without consideration for the product.
I have not much more to add, but FWIW the people espousing the "boring is better" and "don't reinvent the wheel" mantras were experienced SV devs, 15 and 30 years experience. They said there is a business justification and it's one of risk, namely that the more home-grown or nonstandard solutions you have, the less likely other people on the team will know what's going on when one of them breaks. There's also the maturity value of an existing codebase in that it has been proven to do the thing it sets out to, whereas a new endeavor may encounter roadblocks that require a rewrite partway through, and also lack documentation and good error messages, don't have the same years of bugfixes, etc.
