There's nothing especially wrong with small libraries if you carefully manage them and don't allow for supply chain attacks. I don't think updates are a serious concern compared to not using a library, because your own code could easily have vulnerabilities too. It is harder to update lots of small libraries versus one big library, but you pick your battle.
Micro-libraries should never be used
101–110 of 179 posts
Re: Micro-libraries should never be used
#102Earlier quoted context omitted.
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 numb…
I‘d prefer to see a completely new renderer backed by containerized JVM with some DSL for UI as a replacement of modern browsers and application-first encrypted by default binary protocol replacing HTTP (one reference implementation for debugging it would fe fine).
Re: Micro-libraries should never be used
#103Micro-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…
This has nothing in common with the UNIX approach. Awk, grep, sort, less and the like are perhaps small, but not that small and not that trivial.
Unix has yes, tr, cut, true, false, uniq, nl, id, fold, sort, sleep, head, tail, touch, wc, date, cal, echo, cat...
These are tiny programs.
I mean, sort has put on some weight over the years, sure. But if it were packaged up for npm people would call it a micro-library and tell you to just copy it into your own code.
Re: Micro-libraries should never be used
#104While 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.
My instinct would have been that this applies to Python! I'm only working from an anecdotal dataset of 1, a friend who works in insurance and is becoming necessarily more and more familiar with Python for data processing.
Re: Micro-libraries should never be used
#105I suspect this might be seen as trolling, but why isn't there a standard lib of stuff like this? surely it can't be beyond the wit of programming kind to have a standard lib, or even layers of standard lib for Node? What is the argument for not having a standard lib, apart from download speed?
Why isn't there some kind of 'compiler/linker/stripper' that would collect the functions actually used and compile them into an application specific library? Yes I know that dynamic dispatch makes that difficult but the programmer does surely know which functions he wants to call. I sometimes hanker for a return to Fortran IV where every routine was separately compiled and the linker only put into the object code tho…
Zig handles this with lazy compilation: code is parsed, but not even type checked, until the compiler reaches it.
This can lead to the occasional rude surprise when finally reaching code I've been working on for awhile, but haven't yet connected to the rest of the project. But it means there's no need for tree shaking, because nothing gets in until it gets used. One of my favorite things about the language.
Re: Micro-libraries should never be used
#106Partially disagree, JS has unique features that require small libraries: https://bower.sh/my-love-letter-to-front-end-web-development However, if I can inline a small function, I will, so in that sense I agree.
> Javascript has a very unique set of challenges that differentiates itself from the rest of the programming world. The primary driving factor for its unique position is javascript is downloaded on the client's browser. Languages that run on the server, for example, don't need to send code that it runs onto client machines, they merely respond to requests made from the browser.
This is profoundly true. JavaScript written for the frontend has different "physics" to backend code.
It's not only code size that is significant. It's the fact that when you ship code over the wire to a client, you don't know what browser or even JS engine version will be interpreting it. Platform incompatibility has been a huge driver of issues in the JS/NPM ecosystem and has caused JS's culture to develop the way it has.
I wrote more about this, link in a top level comment.
Re: Micro-libraries should never be used
#107the entire nodejs ecosystem needs to die. You all are just keeping it alive.
Have fun convincing all major browser vendors to no longer support JS scripts :)
(At this point Nodejs is the defacto tooling ecosystem for even JS destined to run in a browser. You can't separate the two.)
Re: Micro-libraries should never be used
#108> 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…
This library is a hilarious example of a huge problem with this kind of package. "Number" is in the eye of the beholder. A string containing numeric characters is, in my view, in no useful way "a number". A package that treats it as such just perpetuates weakly-typed nonsense.*
But the broader point is, you can't outsource understanding to a package. There will be places in your code where NaN is a perfectly valid number, or Infinity. And other places where you absolutely need to be sure neither of the above make their way in.
By pretending that a package can capture the universal essence of "numberless", and that this will broadly apply across the entire JS ecosystem (see reported benefits like "different libraries can all rely on is-number instead of rewriting duplicated helper functions!") is naive.
I wrote more about this in a post linked in a top level comment. The is-promise library is another great example.
* Personal pet theory is that the package author would have been embarrassed to publish a 1-line package, so included "numeric strings are numbers" as a fig leaf to justify the package's existence. They should have instead created two new packages, is-actual-number and is-numeric-string, so the implementation of is-number could be nice and clean:
module.exports = function(n) { return require('is-actual-number')(n) || require('is-numeric-string')(n); }
Re: Micro-libraries should never be used
#109"The library may be a bad fit for your problem."
How is this the fault of the library? You chose the wrong one!
"This often cancels out the primary benefit of libraries. No, you don’t have to write the code, but you do have to adapt your problem to fit the library"
You evaluated the library, found is unsuitable and yet, it is somehow their fault.
Why on earth would you project your own failures on to someone else's code? You do you!
Re: Micro-libraries should never be used
#110I would argue that "They should either be copy-pasted into your codebase" would cause more code liabilities and maintenance required further down the line. I've personally seen codebases with a ton of custom code, copy-pasted code, inspired implementations before and it was horrible to get them up to speed with the latest functionality / best practices. I agree that having too many micro-libraries might not be benefi…
You don't even have to talk about hypotheticals when it comes to this "vendor everything instead" philosophy. This is basically how the C world works, a lot of which is driven by a general allergy to dependencies by embedded developers - partially out of necessity (space and overhead are MUCH more important constraints in embedded land) - but also partially out of cargo culting.
I guess the opinion I'll share here is that I don't hear too many people arguing that the way embedded developers manage C libraries is at the forefront of how we should be handling and distributing code.