Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Micro-libraries should never be used

bvisness.me

Post reply on HN
Print view View original

71–80 of 179 posts

Re: Micro-libraries should never be used

#71

Post by edfletcher_t137 »

IshKebab wrote: post #64
edfletcher_t137 wrote: post #51

Where do you draw the line: is 10 lines "micro"? 50? 100? It is never quantified within, yet the very click-bait-y title relies on the term. How many bugs can hide in 50 lines or 100? And you really want to copy-paste that code at a static point in time?!

I don't think they need to draw an exact line for us to know what they're talking about.

The fact that we're even debating it shows that they do. And I didn't ask for "an exact line". I asked for anything. What is your qualification for a "micro" library? I'm betting it's different from 9 other respondents. That's a problem.

Furthermore, that's not even the main contention I was highlighting. Without a proper definition, the advice of "just copy/paste these" is dangerous. Someone will draw their line at something too large, copy/paste that in and inherit bugs/vulnerabilities they never fix. That's a big problem.

Re: Micro-libraries should never be used

#72

Post by ristos »

jaredsohn wrote: post #31
ristos wrote: post #15

Micro-libraries are really good actually, they're highly modular, self-contained code, often making it really easy to understand what's going on. Another advantage is that because they're so minimal and self-contained, they're often "completed", because they achieved what they set out to do. So there's no need to continually patch it for security updates, or at least you need to do it less often, and it's less likely…

>I would argue the problem is how dependencies in general are added to projects I haven't done anything with this myself (just brainstormed a bit with chatgpt) but I wonder if the solution is https://docs.npmjs.com/cli/v10/commands/npm-ci Basically, enforce that all libraries have lock files and when you install a dependency use the exact versions it shipped with. Edit: Can someone clarify why this doesn't work? Woul…

I'm not sure why you're getting downvoted. The left-pad incident on npm primarily impacted projects that didn't have lockfiles or were not pinning exact versions of their dependencies. I knew a few functional programmers that would freeze the dependencies to an exact version before lockfiles came around, just to ensure it's reproducible and doesn't break in the future. Part of what was to blame was bad developer practice. I like npm ci.

Re: Micro-libraries should never be used

#74

Post by ivan_gammel »

ristos wrote: post #33
ivan_gammel wrote: post #28

Earlier quoted context omitted.

> So there's no need to continually patch it for security updates, or at least you need to do it less often, and it's less likely that you'll be dealing with breaking changes. Regardless of how supposedly good or small is the library, the frequency at which you need to check for updates is the same. It doesn’t have anything to do with the perceived or original quality of the code. Every 3rd party library has at least…

They don't need to understand the low level dependencies. People can create metapackages of a lot of a bunch of self-contained libraries that have been audited and forked, and devs can pull in the metapackages. The advantage is the modularity, which makes the code easier to audit and is more self-contained. When's the last time ls, cat, date, tar, etc needed to be updated on your linux system? probably almost never.…

> How often does a very large package need to be updated for bug fixes, security patches, or new versions?

I don’t think you understand my comment, because you are asking the wrong question again. It is not how often you need to actually update one dependency, but how often you need to check for updates that matters. That has to be done frequently no matter what and must be automated. E.g. despite low number of CVEs in coreutils you have to check them very often, because the impact can be very high. Once you have this process in place, there’s no advantage in using micro-libraries. I’d actually expect that in a micro-library environment most breaking changes happen when a library becomes unsupported and you need to choose an alternative, making the migration process more complicated than in case of a bigger framework which just changed the API.

Re: Micro-libraries should never be used

#75

Post by ristos »

Barrin92 wrote: post #70
ristos wrote: post #15

Micro-libraries are really good actually, they're highly modular, self-contained code, often making it really easy to understand what's going on. Another advantage is that because they're so minimal and self-contained, they're often "completed", because they achieved what they set out to do. So there's no need to continually patch it for security updates, or at least you need to do it less often, and it's less likely…

">The UNIX philosophy is also build on the idea of small programs, just like micro-libraries, of doing one thing and one thing well, and composing those things to make larger things." The Unix philosophy is also built on willful neglect of systems thinking. The complexity of system isn't in the complexity of its parts but in the complexity of the interaction of its parts. Putting ten micro-libraries together, even if…

It's not a willful neglect of systems thinking. Functional programmers have been able to build very large programs made primarily of pure functions that are composed together. And it makes it much easier to debug as well, because everything is self-contained and you can easily decompose parts of the program. Same with the effectful code as well, leveraging things like algebraic effects.

Re: Micro-libraries should never be used

#76

Post by unstable »

IshKebab wrote: post #62
unstable wrote: post #58

> You can write isNumber(foo) instead of typeof foo === "number". Indeed you can, but it depends what isNumber does. This is more like what it should do IMO: function isNumber( foo ) { return ( (typeof foo === "number") && (foo == foo)) || ((typeof foo === 'object') && (foo instanceof Number) ); } And that is I think the value of micro libs, at least in JS, you don't want to think about all the edge cases when you on…

Doesn't that exclude NaN (which you probably want despite the name)? I think this really highlights that you probably do want to think about those edge cases... In any case this is a bad example because Typescript exists.

Accepting NaN as a number can potentially crash your app, that's why I reject it in isNumber.

I only tried to highlight some edge cases that I personally don't like to spend energy on, trying to get it right, when writing code. Btw, isNumber is a dynamic call in the example and unrelated to TypeScript. TypeScript doesn't exist at runtime.

Re: Micro-libraries should never be used

#77

Post by ivan_gammel »

foul wrote: post #50
ristos wrote: post #15

Micro-libraries are really good actually, they're highly modular, self-contained code, often making it really easy to understand what's going on. Another advantage is that because they're so minimal and self-contained, they're often "completed", because they achieved what they set out to do. So there's no need to continually patch it for security updates, or at least you need to do it less often, and it's less likely…

Micro-libraries anywhere else are everything you said: building blocks that come after a little study of the language and its stdlib and will speed up development of non-trivial programs. In JS and NPM they are a plague, because they promise to be a substitute for competence in basic programming theory, competence in JS, gaps and bad APIs inside JS, and de-facto standards in the programming community like the oldest…

The whole web stack must die and be replaced. JS, CSS, HTML, HTTP are huge cost center for global economy.

Re: Micro-libraries should never be used

#78

Post by prng2021 »

ristos wrote: post #15

Micro-libraries are really good actually, they're highly modular, self-contained code, often making it really easy to understand what's going on. Another advantage is that because they're so minimal and self-contained, they're often "completed", because they achieved what they set out to do. So there's no need to continually patch it for security updates, or at least you need to do it less often, and it's less likely…

Why even stop at micro-libraries? Instead of "return num - num === 0" why not create the concept of pico-libraries people can use like "return isNumberSubtractedFromItselfZero(num)" ? It's basically plain English right?

You could say that if all the popular web frameworks in use today were rewritten to import and use hundreds of thousands of pico-libraries, their codebase would be, as you say, composed of many high modular, self contained pieces that are easy to understand.

/s

Re: Micro-libraries should never be used

#79

Post by ristos »

ivan_gammel wrote: post #74
ristos wrote: post #33

Earlier quoted context omitted.

They don't need to understand the low level dependencies. People can create metapackages of a lot of a bunch of self-contained libraries that have been audited and forked, and devs can pull in the metapackages. The advantage is the modularity, which makes the code easier to audit and is more self-contained. When's the last time ls, cat, date, tar, etc needed to be updated on your linux system? probably almost never.…

> How often does a very large package need to be updated for bug fixes, security patches, or new versions? I don’t think you understand my comment, because you are asking the wrong question again. It is not how often you need to actually update one dependency, but how often you need to check for updates that matters. That has to be done frequently no matter what and must be automated. E.g. despite low number of CVEs…

Maybe I'm not understanding your argument. Are you saying that if all these larger programs wrote all those utilities from scratch, it makes it so that if someone messed something up, the rest of the large programs are unaffected?

All of those larger programs can mess things up in different ways, opening up all sorts of attack vectors and bugs. And a smaller utility that's much more easily auditable and easier to contribute fixes to is arguably less likely to have attack vectors in the first place.

I'm not sure you have to check large libraries less often. I would argue at least as much if not more often, because it's harder for people to audit larger codebases and to also contribute fixes to them. A significantly smaller number of devs can (or could, if they had bandwidth/time) understand a large self-contained codebase than a very small self-contained codebase.

I think that if a larger library is made of many smaller, modular, self-contained parts, that are composed together, and you can swap out any smaller building block for something that fits your use case (inversion of control), then that's a really good way to write a large library. Sloppier code might find it's way in due to time/resource constraints though, or the authors might not notice that some of the code isn't entirely modular/composable/swappable.

Re: Micro-libraries should never be used

#80

Post by edwinjm »

ivan_gammel wrote: post #77
foul wrote: post #50

Earlier quoted context omitted.

Micro-libraries anywhere else are everything you said: building blocks that come after a little study of the language and its stdlib and will speed up development of non-trivial programs. In JS and NPM they are a plague, because they promise to be a substitute for competence in basic programming theory, competence in JS, gaps and bad APIs inside JS, and de-facto standards in the programming community like the oldest…

The whole web stack must die and be replaced. JS, CSS, HTML, HTTP are huge cost center for global economy.

You can use Flutter now. Go use it. Stop whining.
Post reply on HN