the entire nodejs ecosystem needs to die. You all are just keeping it alive.
You can start by ignoring it
Micro-libraries should never be used
91–100 of 179 posts
Re: Micro-libraries should never be used
#92Earlier 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.
I think that it's ugly but okay-ish right now. What is very very bad is the tooling, and someone should remember people that Facebook and Google do things that serves Facebook and Google-scale needs (billions of users, thousands of devs working asynchronously, no time).
What I end up thinking (maybe i'm wrong) is that node.js must be nuked out of backend and on frontend maybe some of the devs should use either a number of libraries under 15 and write custom code for the rest, or use a language that transpiles to JS like TS, flutter, nim, Go or what have you.
Maybe JS should be nuked out of tooling too, sometimes it's actively damaging and sometimes dead slow. Use something else if wrangling asset files are a problem.
If you want a DX where backend is frontend, you must use the only three mantained languages that can do that without trying to actively damage you or users, which are a Smalltalk (like Pharo), a Lisp (like Clojure/Clojurescript) or Java.
Re: Micro-libraries should never be used
#93At no point does this article attempt to define the term "micro-library".
Perhaps we should start there.
Re: Micro-libraries should never be used
#94The bigger principle is that atomising everything into small parts separated from their context obfuscated them and the bigger picture.
Re: Micro-libraries should never be used
#95These arguments aren't very convincing IMHO.
Using SNS as an example when it's neither micro nor a library but a service (and a huge abstraction over native push notifications, whereas most micro-libraries provide simple utilities that aren't very abstract), saying that complex libraries are harder to audit and hence a security risk (which should be a point in favor of micro-libraries that are small enough to audit in minutes), saying libraries might have large footprints (which is surely another reason to go for micro-libraries over all-you-could-possibly-need-libraries), saying transitive dependencies are bad, (yet again, this points towards an advantage of micro-libraries, which are less likely to have many dependencies), ... I don't know.
Re: Micro-libraries should never be used
#96Earlier 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 HTTP-centrism is the worst.
QUIC is hilarious because they ended up fitting everything and the kitchen sink for any need in the proto, just because 15 years ago firewalls blocked this or that and the reimplementation with websockets of the thing that was blocked runs only in a browser.
Re: Micro-libraries should never be used
#97While 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 li…
> why does the JS ecosystem seem to have "more fear" than for example the Python ecosystem?
Perhaps it's because so many JS developers - quite rightfully - suffer from impostor syndrome?
It's the language with the largest proportion of people who didn't set out to be programmers but somehow got mission-crept into becoming one.
Re: Micro-libraries should never be used
#98Earlier quoted context omitted.
> all of those small composable units, that were once developed by random people, were turned into a meta-package at some point No they weren’t. Every UNIX I used in the 80s and 90s shipped with those little composable building blocks as part of the OS, and GNU bundled them in things like coreutils forever. It’s not like there was some past time when there were independent little things like cat and wc and so on writ…
They were developed by different authors...
Who often worked together, sometimes, gasp in the same building!
Definitely not random people on the internet not met or even emailed.
Re: Micro-libraries should never be used
#99Earlier quoted context omitted.
> 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 con…
> I would argue at least as much if not more often
The same. The frequency of checks is not dependent on the library size and depends on the risk profile of your application, so library size cannot be considered an advantage with regards to updates. In most cases upgrade to newer version can be done automatically, because it is unrealistic expectation that developers will review the code of every dependency and understand it. Breaking changes likely occur with the same frequency (rare), albeit for different reasons, and impact can be on the same scale for tiny and large depenencies.
Re: Micro-libraries should never be used
#100Earlier quoted context omitted.
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?)
Those are not the Problems, just common problems with known solutions (Migration Path and Let-It-Go).