I think one difference is that this is usually abstracted to quite some degree. Most devs rarely (if ever) have to deal with C/C++ build systems, as package managers and whatnot deal with that.

For most people installing some C/C++ library it's just "apt-get install libfoo" (and maybe libfoo-dev), and they never have to deal with ninja/autotools/cmake/etc, whereas for JavaScript you directly have to deal with the tooling by using "npm install libfoo".

The same task mentioned in the article would probably be a lot easier: install package, write some code, "c++ -lfoo main.cpp".

This is fair, but, the original article mentioned installing a random module on github. A C/C++ library large enough to have distro maintainers, is more akin to a large JS library that has UMD scripts hosted by Cloudflare. In that case, a developer could just do '<script src="https://cdnjs.com/lib.js">' in a html page.

I'm not saying JS is perfect, or that other languages don't have these issues. I haven't used Rails in years but I remember spending a day trying to get a gem installed and figuring out why nokogiri wouldn't compile. Almost every language has these problems.

Most of the C++ is curated by the package maintainers. That's the key: do not let upstream programmers do it (they adore their unique build systems and other stuff like that).

That's how you get quality user experience. It creates balance between developer of the library/tool and the user of the library/tool.

In my last C++ project (it's been a while) we ended up including many of our dependencies in source as we required different versions, different build options or small modifications compared to the packaged version.

Most of the time we would create a minimal CMake file to build the library to our specs or adapt the existing CMake file.