Micro-libraries should never be used
bvisness.me
Micro-libraries should never be used
1–10 of 179 posts
Re: Micro-libraries should never be used
#2I suspect this might be seen as trolling, but why isn't there a standard lib of stuff like this?
surely it can't be beyond the wit of programming kind to have a standard lib, or even layers of standard lib for Node?
What is the argument for not having a standard lib, apart from download speed?
Re: Micro-libraries should never be used
#3Why don't people just copypasta the library into their codebase with the license header intact and keep it out of npm
Re: Micro-libraries should never be used
#4I think the JS library ecosystem is a debacle, but there's really only one point in this post that grabbed me:
"Would future updates be useful? No. The library is so simple that any change to the logic would be breaking, and it is already clear that there are no bugs."
Maybe what you want is a library ecosystem where things can be marked "this will never change". Something crazy happens and you actually need to update "is-number"? Rename it.
Of course, you can simulate that with a single large omnibus dependency that everyone can trust that pulls all these silly micro-libraries in verbatim.
Re: Micro-libraries should never be used
#5I 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 :)
Re: Micro-libraries should never be used
#6In my Laravel projects, there are a few packages of much more niche/hobbyist origin without corporate backing, some haven’t been updated for a while, and others are perfectly fine and don’t need much maintenance.
Normally, packages are listed in my composer.json and stored in vendor/. For those packages, I created a separate folder called vendor_private/ which is part of my Git tree, put copies of these weird little packages in it, and set up my composer.json to consider that folder a repository.
Works like a charm. My big important packages are still upstream. I can customize the little ones as needed to fit better, or have better code, and not worry about them going unmaintained. It’s also way quicker than copying the files individually out of the package and into the right places (along with updating Namespaces, configuration, etc.) Once in a while, I’ll go back and see if anything worthwhile has changed upstream - and so far, it never has.
Re: Micro-libraries should never be used
#7Missing benefit: Libraries are a way to distribute and share the costs of labor, resulting in a more efficient ecosystem.
This doesn't apply to micro-libraries, but it looks like that cost/benefit list is intended to cover libraries in general.
Re: Micro-libraries should never be used
#8I 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 benefi…
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)?
Re: Micro-libraries should never be used
#9I suspect this might be seen as trolling, but why isn't there a standard lib of stuff like this? surely it can't be beyond the wit of programming kind to have a standard lib, or even layers of standard lib for Node? What is the argument for not having a standard lib, apart from download speed?
I'm not taking an absolute position either way -- the devil is in the details -- but here's my steelman for the opposing view:
When you put something in the standard library, it's harder to take it out, meaning that you're committing development resources to support the implementation. Furthermore things change: protocols and formats rise and fall in popularity and programming style evolves as the language changes (e.g. callbacks vs. promises in JS). Therefore the stdlib becomes where libraries go to die, and you'll always have a set of third party libraries that are "pseudo-standard", like NumPy in Python.
Having a minimal stdlib lets you "free-market" the decision, letting the community effects take care of what is considered standard in the ecosystem, and lets you optimize its minimal surface, like what happened with C.
Re: Micro-libraries should never be used
#10Seems a lot like the classic "I put only a couple of the strong advantages and enumerate everything I could think about as disadvantage". While I'm bias (I've done a bunch of these micro-libraries myself), there's more reasons I/OSS devs do them! To name other advantages (as a dev consuming them):
- Documentation: they are usually well documented, at least a lot better than your average internal piece of code.
- Portability: you learn it once and can use it in many projects, a lot easier than potentially copy/pasting a bunch of files from project to project (I used to do that and ugh what a nightmare it became!).
- Semi-standard: everyone in the team is on the same page about how something works. This works on top of the previous two TBF, but is distinct as well e.g. if you use Axios, 50% of front-end devs will already know how to use it (edit: removed express since it's arguably not micro though).
- Plugins: now with a single "source" other parties or yourself can also write plugins that will work well together. You don't need to do it all yourself.
- Bugs! When there are bugs, now you have two distinct "entities" that have strong motivation to fix the bugs: you+your company, and the dev/company supporting the project. Linus's eyeballs and all (yes, this has a negative side, but those are also covered in the cons in the article already!).
- Bugs 2: when you happen upon a bug, a 3rd party might've already found a bug and fixed it or offered an alternative solution! In fact I just did that today [1]
That said, I do have some projects where I explicitly recommend to copy/paste the code straight into your project, e.g. https://www.npmjs.com/package/nocolor (you can still install it though).
[1] https://github.com/umami-software/node/issues/1#issuecomment...