Micro-libraries should never be used

Post by funcDropShadow » Mon, Aug 19, 2024, 7:44 PM UTC

a_wild_dandan wrote: post #32

mattlondon wrote: post #17

Earlier quoted context omitted.

> Micro-libraries are really good actually, they're highly modular, self-contained code Well I think that is the point, they're not self-contained. You are adding mystery stuff and who knows how deep the chain of dependencies go. See the left-pad fiasco that broke so much stuff, because the chain of transitive dependencies ran deep and wide. NPM is a dumpster fire in this regard. I try to avoid it - is there a flag y…

There is a "no downstream dependencies" option; it's called writing/auditing everything yourself. Everything else -- be it libraries, monolithic SaaS platforms, a coworker's PR, etc. -- is a trade off between your time and your trust. Past that, we're all just playing musical chairs with where to place that trust. There's no right answer.

Post by surgical_fire » Mon, Aug 19, 2024, 8:48 PM UTC

1attice wrote: post #164

ivan_gammel wrote: post #142

Earlier quoted context omitted.

They are not designed for modern use cases and certainly not well-designed according to modern understanding of this word. In fact they did not stood the test of time as something worthy of preservation, they only survived and mutated, because it is extremely hard to replace them. And of course we should blame the technology: the sole purpose of a standard is to be used by people. If people struggle with it the stand…

> And of course we should blame the technology: the sole purpose of a standard is to be used by people. If people struggle with it the standard is unfit for its purpose. 'People' is equivocal here. While complex, and (as you point out, in so many words) an evolved standard, the HTML/CSS/JS stack is arguably one of humanity's greatest achievements, up there with the invention of paper, or perhaps cuneiform. It's imper…

Post by 6510 » Tue, Aug 20, 2024, 8:04 PM UTC

tgv wrote: post #21

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 But you need the functionality anyway, so there are two dependencies: on your own code, or on someone else's code. But you can't avoid a dependency, and it comes at a cost. If you don't know how to code the functionality, or it will take too much time, a library is an outcome. But if you need leftPad or isNumber as an external dependency…

   module.exports = function(num) {
     if (typeof num === 'number') {
       return num - num === 0;
     }
     if (typeof num === 'string' && num.trim() !== '') {
       return Number.isFinite ? Number.isFinite(+num) : isFinite(+num);
     }
     return false;
   };

    isNumber = num => isFinite(num+''.trim());

   function isNumber(num){
     switch(typeof num){
       case "number" : return !isNaN(num);
       case "string" : return isFinite(num) && !!num.trim();
     }
   }

Post by tgv » Sun, Aug 25, 2024, 9:06 AM UTC

6510 wrote: post #175

tgv wrote: post #21

Earlier quoted context omitted.

> I would argue the problem is how dependencies in general are added to projects But you need the functionality anyway, so there are two dependencies: on your own code, or on someone else's code. But you can't avoid a dependency, and it comes at a cost. If you don't know how to code the functionality, or it will take too much time, a library is an outcome. But if you need leftPad or isNumber as an external dependency…

If incompetent it provides a way to be sure? Could you for laughs explain for which cases these are, why they are needed and why they did it this way? 1) num-num === 0 2) num.trim() !== '' 3) Number.isFinite(+num) 4) isFinite(+num) 5) return false; 6) Why this specific order of testing? Why prefer Number.isFinite over isFinite? https://www.npmjs.com/package/is-number module.exports = function(num) { if (typeof num ==…

Post by Ygg2 » Mon, Sep 02, 2024, 7:41 AM UTC

jvanderbot wrote: post #157

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 are ok - TFA even says you can use self-contained blocks as direct source . Mirco dependencies are a god damn nuisance, especially with all the transitive micro-dependencies that come along, often with different versions, alternative implementations, etc.