NPM CEO Bryan Bogensberger Resigned

Only if it's a recurring issue. People can be a horrible contributor at Company A and a rockstar at Company B - should my entire future be anchored because of a single event? No thanks.

> I know it's standard business procedure to outright lie about these things

This is just silly. It's no different than how anyone reacts in any non-professional setting. Do you tell everyone in your life about every fuck up you make? So why expect that from our professional peers?

NPM/Node is very much a "we only provide the bare minimum for a language, everything else must be implemented on your own." The JavaScript stdlib is very small (not that weird when you consider it's originally a language to do stuff with in your browser).

The result is that a lot of "simple" functionality that most languages would put in the stdlib (left-pad is the most infamous example) has to be reimplemented by library developers. Now because programmers are for the most part not interested in copying the same code over and over, this means that these simple functionalities end up on the npm, which are then used in somewhat bigger libraries, right up until you essentially create a massive dependency chain for each major library, since the dependencies for that library rely on other dependencies and so on so forth.

This sounds interesting in theory, but in reality this almost always means that if one thing in this chain breaks (for example a "simple" library introduces a breaking change but doesn't properly adhere semantic, since nobody enforces semantic on the npm although it's recommended), essentially the entire chain is broken and the top level library stops functioning as well.

And then you end up with packages such as left-pad, which provide simple functionality that is almost universally needed for almost all major libraries. Now the last thing you want to have happen here is that the maintainer either removes or breaks the package, since this essentially results into a dependency hell cascade as suddenly several millions of packages are broken.

Python on the other hand has probably one of the biggest standard libraries I've seen in a programming language, and the difference is outstanding. Most PyPi libraries are moreso focused on adding specialized features or simplifying otherwise lower level libraries into more higher level ones (ie. requests is really nothing other than a really good wrapper around urllib). There's very few "simple functionality" libraries for PyPi, since most of this functionality is already in the standard library. Usually if a library that is "simple functionality" isn't in the standard library, it's because it changes too often (standard library is mainly for unchanging code. eg, requests) or is still somewhat specialized (ie. sqlalchemy or a couple of validator packages I use).

There's pro's to Nodes approach (ie. you're generally not locked down to a single approach), but generally Pythons approach on library management is better in my opinion.

I guess my broader thought was that PyPi is a more reliable free offering than NPM because it's not focused on a 'premium' version for the biggest users. But that's different than AWS - presumably they're sponsoring it in a broader "making development accessible is good for AWS" sense.