I think JS gets shit on the most because its both the largest, most popular, visible and relatable. Imagine trying this same exercise with a C++ library you found

>The cmake build is doesn't work without -GNinja (you do have ninja installed, right?)

>No actually use Bazel/Buck/Pants/Meson

>Oh you installed $DEP, but not the right $DEP with $DEP-X support

>pkg-config can't find $DEP-X

>Pre-build $DEP-X was built with GCC N, and you have GCC N-1, try building from source

>GOTO 1 for DEP-X

I'm embellishing here, but I feel like I always do some version of this song and dance when trying to build a C++ project. And then after all that is done you somehow still end up with linker errors in your final project.

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.

Now I want to see John try to build a client on another stack, like deciding between Carthage vs CocoaPods vs etc. for his iOS hello-world and running into the problems with that.

Or, hell, how about the packaging systems in Go or Python? "Yeahhh, we don't really use X anymore, go ahead and use Y."

John certainly failed the perseverance test though.

It's true that basically every language (except Rust?) has nightmarish package/environment management/tooling ecosystem problems. Why is this, anyway? It's a little nuts that it's easier to learn how to code than it is to figure out how to install a module.

Right now you can click File > Swift Packages > Add Package Dependency and let SPM handle it for you without thinking. I know not every package supports SPM yet but it's clearly the path forward and something everyones working towards. I think the other point I've found doing both web and iOS is you don't need any dependencies to get started on iOS, a hello world app is as straightforward as opening XCode, creating a new project and plugging in your phone.

I don't know. I think both of the examples you provided really require less perseverance and are more of an analysis paralyis issue.

In John's case, even after he got some help he still couldn't set up and run the project which is really frustating.

JS gets shit on a lot, but I think npm install with a package.json is kind of one of the easier setups.

Eh, yes and no- that only gets you started if someone else already picked modules for you. Snowpack and such make modern ES modules with npm bearable, but the sheer volume of modules that rely on webpack's preprocessing bastardization of the module system is really depressing. I really wish they had used comment directives or something other than the import statement for things like attaching CSS files to builds.

> Snowpack

oh look, another one

shrug it basically just copies files out of node_modules to another folder for sane browser use of module imports (no concatenation or build process). Basically, for people who liked bower but are stuck with npm.

I've used it for some personal projects, but doubt that I'll use it for anything paid anytime soon.

Well, since you mentioned ruby, I've never had - not even once! - to wipe out my gems folder in 10 years I'm coding with it. I think most ruby developers never had too.

With javascript? Well, for instance, take Expo's official release notes for each new SDK and it's right there, as the recommended practice: wipe out your `node_modules` folder and run `yarn` again every time. And good luck not having your `yarn.lock` file randomly changing versions after a while.

It's just a single silly example, but it tells how much more stable the ruby development experience is.

dude what dealing with ruby gems is like 50% of iamdevloper's schtick.

The node environment and the browser environment is a pretty unique aspect to JavaScript. It adds some complexity for novices. An hour spent trying is a bit on the light side though.

This is one reason I'm so excited about Deno. It's basically like browser, but for (ESM) modules. Solves so many of node's problems.

the python experience especially is so painful...

there is always the other python binary hidden somewhere in the depths of the filesystem...