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

161–170 of 179 posts

Re: Micro-libraries should never be used

#161

Post by klabb3 »

oftenwrong wrote: post #87

The primary cause of the left-pad incident was that left-pad was removed from the npm registry. Many libraries depended on left-pad. The same could have occurred with any popular library, whether micro or not. To reformulate the statement made in the intro of this post: "maybe it’s not a great idea to outsource _any critical_ functionality to random people on the internet." It has long been a standard, best practice…

> To reformulate the statement made in the intro of this post: "maybe it’s not a great idea to outsource _any critical_ functionality to random people on the internet."

Well everything is critical in the sense that a syntax error could break many builds and CI systems.

This is what lock files are for. If used properly, and the registry is available, there are no massive issues. This is how things are supposed work – all the tooling is made this way.

In short, I think the lessons from the leftpad debacle are (1) people don’t use existing versioning tooling, (2) there is a surprising amount of vendors involved if you look at dep trees for completely normal functionality and (3) the JS ecosystem is particularly fragmented with poor API discipline and non-existent stdlib.

EDIT: Just read up on it again and I misremembered. The author removed leftpad from NPM due to a dispute with the company regarding an unrelated package. That’s more of a mismanaged registry situation. You can’t mutate and remove published code without breaking things. Thus NPM wasn’t a good steward of their registry. If there’s a need to unpublish or mutate anything, there needs to be leeway and a path to migrate.

Re: Micro-libraries should never be used

#162

Post by buildbot »

DonHopkins wrote: post #156
buildbot wrote: post #112

Earlier quoted context omitted.

That’s just the way Python works though, an import reads a script line by line defining the functions and executing calls. I think that’s true of any scripting language?

How it works and how it should be used are different. Say “no” to import side‐effects in Python: https://news.ycombinator.com/item?id=7536246 https://chrismorgan.info/blog/say-no-to-import-side-effects-... >I must be able to import your module— any module— at any time without anything breaking. Or even the beneficial side effect of some other module running 10% faster. ;) What side-effects, if any, are okay when impo…

Well yeah, I wouldn't hold it that way either. The number of PRs I've commented on to take side effects out from imports is like , 75% of all the PRs I've seen in my current job.

Maybe Python 4 can make anything except a function definition or import be a syntax error in a module haha.

Re: Micro-libraries should never be used

#163

Post by consteval »

userbinator wrote: post #11

and because it updates fairly frequently I fail to comprehend how a single-function-library called "isNumber" even needs updating, much less "fairly frequently". The debate around third-party code vs. self-developed is eternal. IMHO if you think you can do better than existing solutions for your use-case, then self-developed is the obvious choice. If you don't, then use third-party. This of course says a lot about th…

> I fail to comprehend how a single-function-library called "isNumber" even needs updating

Never underestimate the complexity and footgunny nature of JS' type system.

Re: Micro-libraries should never be used

#164

Post by 1attice »

ivan_gammel wrote: post #142
danielovichdk wrote: post #135

Earlier quoted context omitted.

HTTP, HTML and to some extent CSS are solid technologies that are very well designed and has been standing thr test of time. How people use them is another matter. But don't blame that on the technology.

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 imperfect, like all living standards, but it manages to be ubiquitous, expressive, and _useful_. And for those of us who grew up with these standards, they are second nature.

Like piano, mastering these standards gives you the ability to express complex UI concepts with grace and alacrity.

Don't smash up your parents' piano simply because practicing scales is a chore :)

Re: Micro-libraries should never be used

#165

Post by oftenwrong »

klabb3 wrote: post #161
oftenwrong wrote: post #87

The primary cause of the left-pad incident was that left-pad was removed from the npm registry. Many libraries depended on left-pad. The same could have occurred with any popular library, whether micro or not. To reformulate the statement made in the intro of this post: "maybe it’s not a great idea to outsource _any critical_ functionality to random people on the internet." It has long been a standard, best practice…

> To reformulate the statement made in the intro of this post: "maybe it’s not a great idea to outsource _any critical_ functionality to random people on the internet." Well everything is critical in the sense that a syntax error could break many builds and CI systems. This is what lock files are for. If used properly, and the registry is available, there are no massive issues. This is how things are supposed work –…

The key point is "If ... the registry is available", and the dependencies contained therein. We take on risk by relying on NPM to always be there and always provide us the dependencies we have already invested in. I'm arguing that organisations should take a more defensive stance against dependencies becoming unavailable. If you depend on it, keep a copy of it somewhere that you control.

Re: Micro-libraries should never be used

#167

Post by orhmeh09 »

foul wrote: post #86
orhmeh09 wrote: post #67

Earlier quoted context omitted.

Could you link to somebody who is teaching npm users to "fire and forget?" Someone who is promising a substitute for competence in basic programming theory? Clearly you and I do not consume the same content.

This is just a discourse based on "I need to churn out something, I need that fast and I didn't start in the web game when Backbone and E4X were solid corporate choices". If you are not in a hurry, work in a solid team and have a good attention span, a lot of clickbait idiocy around JS may not happen. It's just that the lone inexperienced guy is one of millions inexperienced guys who are taught the wrong ways everyda…

I don't really see the problem with the CRA docs.

Re: Micro-libraries should never be used

#168

Post by zahlman »

xg15 wrote: post #35

Micro libraries are worse than no libraries at all - but I maintain they are still better than gargantuan "frameworks" or everything-but-the-kitching-sink "util"/"commons" packages, where you end up only using a tiny fraction of the functionality but have to deal with the maintenance cost and attack surface of the whole thing. If you're particularly unlucky, the unused functionality pulls in transitive dependencies o…

> but I maintain they are still better than gargantuan "frameworks" or everything-but-the-kitching-sink "util"/"commons" packages, where you end up only using a tiny fraction of the functionality but have to deal with the maintenance cost and attack surface of the whole thing.

Indeed. Several toy projects I've done were blown up in size by four orders of magnitude because of Numpy.

I only want multi-dimensional arrays that support reshaping and basic element-wise arithmetic, maybe matrix multiplication; I'm not even that concerned about performance.

But I have to pay for countless numerical algorithms I've never even heard of provided by decades-old C and/or FORTRAN projects, plus even more higher-math concepts implemented in Python, Numpy's extensive (and fragmented - there's even compiled code for testing that's outside of any test folders) test suite that I'll never run myself, a bunch of backwards-compatibility hacks completely irrelevant to my use case, a python-to-fortran interface wrapper generator, a vendored copy of distutils even in the wheel, over 3MiB of .so files for random number generators, a bunch of C header files...

[Edit: ... and if I distribute an application, my users have to pay for all of that, too. They won't use those pieces either; and the likelihood that they can install my application into a venv that already includes NumPy is pretty low.]

I know it's fashionable to complain about dependency hell, but modularity really is a good thing. By my estimates, the total bandwidth used daily to download copies of NumPy from PyPI is on par with that used to stream the Baby Shark video from YouTube - assuming it's always viewed in 1080p. (Sources: yt-dlp info for file size; History for the Wikipedia article on most popular YouTube videos; pypistats.org for package download counts; the wheel I downloaded.)

Re: Micro-libraries should never be used

#169

Post by ivan_gammel »

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…

> Don't smash up your parents' piano simply because practicing scales is a chore :)

I witnessed evolution of UIs from Turbo Vision to modern web and mobile frameworks. My first commercial website went live in 1999. No, UI is not hard and doesn’t require any mastery. As a matter of fact, building decent UI for a client-server application is a simple task with the right tools and processes. Modern Web is not parents‘ piano - you can call it elegant only if you have seen nothing else. It’s a fridge with mostly expired cheap food, from which you have to cook a decent meal for a party. It is possible, no doubt. Without food we will die, so we have to cook it. Instead we could just go shopping.

Re: Micro-libraries should never be used

#170

Post by 5Qn8mNbc2FNCiVV »

GuB-42 wrote: post #150
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…

If these libraries are so small, self-contained and "completed", why not just copy-paste these functions? Submodules can work too, but do you really need these extra lines in your build scripts, extra files and directories, and the import lines just for a five line function? Copy-pasting is much simpler, with maybe a comment referring to the original source. Note: there may be some legal reasons for keeping "micro-li…

As soon as source code is in your repo it's way more probable to getting touched. I'd never open that box ever because I don't want to waste time with my team touching code that they shouldn't when reviewing.

If you want the same functionality, build it according to the conventions in the codebase and strip out everything else that isn't required for the exact use case (since it's not a library anymore)

Post reply on HN