An open source library is necessarily generic and has to be battle tested to make sure it fulfills all use cases, while the library you write only has to cover your own needs that makes it easier to understand, extend and debug

That's true but the vast majority of what you find on NPM is not mainstream, battle-tested libraries.

Libraries that do clear that bar tend to be widely useful but that suggests generality you won't necessarily need for any single use case. A couple of good engineers might struggle to beat a well-established open source library at everything it does, but that is rarely what they are trying to achieve. They just need something that is better for their own specific needs at that time, which might be a useful and realistic target.

Also many "battle-tested" libraries are not really very high quality - they all have bugs, unnecessary complexity and technical debt. Higher degree of testing they get is often offset by the higher number of feature requests, and more features means more complexity and more bugs.

And in reality I saw it many times when a niche library written by a solo developer is of a higher quality than a super popular behemoth written by hundreds of developers over 10 years.

- ubiquitous things, like data structures

- hard to get right things, like time

- implementations of specs, like Unicode

- hardware interfaces, like CUDA

For everything else, I'll take the above and roll my own solution.

> - ubiquitous things, like data structures

There are a few basic data structures in JS, but almost everything else is in user-land.

> - hard to get right things, like time

Date is a notoriously bad API in JavaScript.

- implementations of specs, like Unicode

We just get a String type in JavaScript which is UTF-16, so...

Well, no, we aren't. We are talking about the Elm language, which compiles to JavaScript.

There are also other excellent languages that target JavaScript that have these things.

I've also seen many developers for years adopting mainstream libraries and frameworks wrongly.

The atrocities I've seen built with Ember, Rails, Angular, and the like.

Often these people built their own (albeit less powerful) libraries and could work much better with them.

In my experience, if someone fails at using mainstream libraries, they will also likely fail in creating their own, at least if it is to later be used and maintained by anyone else successfully.

The problem with mainstream libraries is to grasp the mental model of their creators.

I met a bunch of developers who understood software design patterns as they are taught in the GoF book, but couldn't see them when applied in a framework/library. Often this was because the design patterns weren't used 1:1 or framework creators simply used the wrong name for a pattern.