[eternityforest]

My priority is always decustomization.

Anything that makes me think of the words "Bespoke" or "Artisinal" or worst of all "A perfect fit to the project needs" is where I look first for problems. I also look at anything that provides multiple ways to do the same thing.

The JS community understands it better than anyone. At the application level, any program, be it amateur or professional, is almost always readable and maintainable. Because there's no interesting algorithms, no abstractions you haven't already seen in a design patterns list, and just generally nothing special about the code at all. They use libraries for everything.

When you stop trying to write interesting and beautiful code, and stop trying to innovate at any level below the application, stuff gets a lot easier.

Of course some projects really do have interesting technical challenges... but so many projects don't.

[sarchertech]

> The JS community understands it better than anyone. At the application level, any program, be it amateur or professional, is almost always readable and maintainable.

Oh man. We have worked on some very different JS applications.

[eternityforest]

Maybe a better way to phrase it would be "Half the JS community understands that better than anyone, and the other half diarrheas out endless tiny useless frameworks and tries to get you to use them, but lets pretend that's not an issue".

[sarchertech]

Yes there’s that as well. But I have seen plenty of the type of code bases you’re praising that were a nightmare to maintain and debug.

Everything is a trade off. Most developers probably shouldn’t write their own database engine. But at the same time adding another dependency to handle padding a number with zeroes is overkill.

In practice after 2 decades doing this, I’m much more likely to run into an over reliance on libraries these days than the other way around.

[eternityforest]

Left pad was more of an issue with mutable dependencies it seems like, and with using tons small dependencies instead of larger trusted ones.

Yarn's zero install and the like could probably have stopped that from ever being an issue. Many lodash/underscore/whatever utilities have that feature, and with dead code removal I don't know why people still use micro libraries.

There's of course malware concerns, but that's why you don't use things that aren't popular with a million eyes on them unless you want to check it yourself.

[sarchertech]

> using tons small dependencies instead of larger trusted ones

That’s certainly not what the JavaScript community as a whole does. If anything that’s closer to the way many other languages do it with large standard libraries.

> There's of course malware concerns, but that's why you don't use things that aren't popular with a million eyes on them unless you want to check it yourself.

Those popular libraries often have hundreds to thousands of dependencies and sub dependencies themselves, many of which almost certainly don’t have a million eyes on them.