[Lws803]

I would argue that "They should either be copy-pasted into your codebase" would cause more code liabilities and maintenance required further down the line. I've personally seen codebases with a ton of custom code, copy-pasted code, inspired implementations before and it was horrible to get them up to speed with the latest functionality / best practices. I agree that having too many micro-libraries might not be beneficial though, but perhaps look for larger, more well-established libraries that encompasses those functionalities :)

[quonn]

What‘s an example for „latest functionality“ or „best practices“ that should or could possibly change for a function like leftPad and that would not automatically happen by virtue of being in the code base (such as formatting)?

[SOLAR_FIELDS]

You don't even have to talk about hypotheticals when it comes to this "vendor everything instead" philosophy. This is basically how the C world works, a lot of which is driven by a general allergy to dependencies by embedded developers - partially out of necessity (space and overhead are MUCH more important constraints in embedded land) - but also partially out of cargo culting.

I guess the opinion I'll share here is that I don't hear too many people arguing that the way embedded developers manage C libraries is at the forefront of how we should be handling and distributing code.

[pton_xd]

Many industries, like AAA game development, work this way.

There's a good reason for it -- code quality and performance is important. Understanding what your code actually does and how it does it, is important.

And as a result, AAA game software is able to push the boundaries of consumer compute performance. Micro-library-built software is generally just bloated crap that barely works. But it is fast to churn out, so there's that.

[SOLAR_FIELDS]

Fair points. But for every bad library there are 10 rock solid ones that are going to do a better job handling edge cases and being performant than you can for almost no additional effort.

Really what this comes down to is the pickiness of package repo maintainers and general skill level of engineers within the ecosystem. This kind of crap and cruft discussed in the article happens in ecosystems where the barrier to entry is tiny. You don’t really hear about left-pad like fiascos in Java land or Rust land. Not saying all devs are great that use these technologies, but in Rust case you really don’t contribute packages without jumping over some serious learning curve hoops and in Java land the canonical repository (Maven Central) is difficult enough to contribute to that it also staves off fly-by-night contributors