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

81–90 of 179 posts

Re: Micro-libraries should never be used

#81

Post by crabmusket »

While I mainly agree with the author's substantive point, though I find some of the ways it's presented in this post not entirely convincing or fair, I am interested that someone else has identified this:

> I have talked a lot about the costs of libraries, and I do hope people are more cautious about them. But there’s one factor I left out from my previous discussion. I think there’s one more reason why people use libraries: fear.

> Programmers are afraid of causing bugs. Afraid of making mistakes. Afraid of missing edge cases. Afraid that they won’t be able to understand how things work. In their fear they fall back on libraries. “Thank goodness someone else has solved the problem; surely I never would have been able to.”

I think this is true, but why does the JS ecosystem seem to have "more fear" than for example the Python ecosystem?

I wrote about this a while ago. I think that actually JS does (or did) cause more fear in its developers than other programming languages. I described it as paranoia, a more insidious uncertainty.

Quoting myself[1]:

> There are probably many contributing factors that have shaped NPM into what it is today. However, I assert that the underlying reason for the bizarre profusion of tiny, absurd-seeming one-liner packages on NPM is paranoia, caused by a unique combination of factors.

> Three factors have caused a widespread cultural paranoia among JavaScript developers. This has been inculcated over years. These factors are: JavaScript's weak dynamic type system; the diversity of runtimes JavaScript targets; and the physics of deploying software on the web.

...

> Over the years there has been rapid evolution in both frontend frameworks and backend JavaScript, high turnover in bundlers and best-practises. This has metastasized into a culture of uncertainty, an air of paranoia, and an extreme profusion of small packages. Reinventing the wheel can sometimes be good - but would you really bother doing it if you had to learn all the arcane bullshit of browser evolution, IE8 compatibility, implementation bugs, etc. ad infinitum?

> And it's not just that you don't understand how things work now, or how they used to work - but that they'll change in the future!

[1] https://listed.to/@crabmusket/14061/javascript-s-ecosystem-i...

Re: Micro-libraries should never be used

#82

Post by syncsynchalt »

porcoda wrote: post #42
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 being a bit abused for this argument. Most systems that fall under the UNIX category are more or less like a large batteries-included standard library: lots of little composable units that ship together . UNIX in practice is not about getting a bare system and randomly downloading things from a bunch of disjointed places like tee and cat and head and so on, and then gluing them together and per…

> randomly downloading things from a bunch of disjointed places like tee and cat and head and so on, and then gluing them together and perpetually having to keep them updated independently.

I have distressing news about my experience using Linux in the '90s

Re: Micro-libraries should never be used

#83

Post by conradludgate »

DonHopkins wrote: post #56
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…

Sometimes importing zombie "undead code" libraries can be beneficial! I just refactored a bunch of python computer vision code that used detectron2 and yolo (both of which indirectly use OpenCV and PyTorch and lots of other stuff), and in the process of cleaning up unused code, I threw out the old imports of the yolo modules that we weren't using any more. The yololess refactored code, which really didn't have any ch…

This is mortifying. This should not be acceptable implicit behaviour for imports to implicitly run code by simply existing

Re: Micro-libraries should never be used

#85

Post by DonHopkins »

conradludgate wrote: post #83
DonHopkins wrote: post #56

Earlier quoted context omitted.

Sometimes importing zombie "undead code" libraries can be beneficial! I just refactored a bunch of python computer vision code that used detectron2 and yolo (both of which indirectly use OpenCV and PyTorch and lots of other stuff), and in the process of cleaning up unused code, I threw out the old imports of the yolo modules that we weren't using any more. The yololess refactored code, which really didn't have any ch…

This is mortifying. This should not be acceptable implicit behaviour for imports to implicitly run code by simply existing

I know, right??! I was alternating between hitting my head up against the wall in despair, and jumping for joy I accidentally found a way to speed up detectron2 by 10%. I'll take the win.

YOLO: You Only Load Once

Re: Micro-libraries should never be used

#86

Post by foul »

orhmeh09 wrote: post #67
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…

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 everyday.

I'm presenting you one of countless examples: a lot of coding bootcamps teach React, maybe with TS, maybe with JS.

Enter react-create-app.

https://github.com/facebook/create-react-app

The docs are a link, while the commands you can copy and paste are laid out at 9th row in the README. That will become a habit for a junior.

Re: Micro-libraries should never be used

#87

Post by oftenwrong »

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 in software engineering to ensure dependencies are stored in and made available from first-party sources. For example, this could mean maintaining an internal registry mirror that permanently stores any dependencies that are fetched. It could also be done by vendoring dependencies. The main point is to take proactive steps to ensure your dependencies will always be there when you need them, and to not blindly trust a third-party to always be there to give your dependencies to you.

Re: Micro-libraries should never be used

#89

Post by smitty1e »

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.

The four abstraction layers reflect the reality of technological drift over time.

Even stipulating a Wand of Internet Technology (WIT) that could produce the One True Stack (OTS), two things remains undone:

- fixing all the old stuff (or does OTS emulate it all?)

- precluding further drift (or does OTS end all that?)

Post reply on HN