Brian Rinaldi is a Developer Experience Engineer at LaunchDarkly with over 20 years experience as a developer for the web. Brian is active in the community running CFE.dev and Orlando Devs.
So the comment you cite is obnoxious and unnecessary for sure, but it's funny that you cite that comment rather than anything in the article, which makes a number of important points imo. Let's look at is-odd, for instance. Yes, the library does check for non-integers and non-number values and throws an error in both cases, but this added a whole 4 lines of code to the core library (and not much more to the tests). You'd never guess the solution was still so simple given the manner in which you've chosen to present it.
However, the bigger point the author of the article (rather than the comment) made was that there are potential risks that come with adding dependencies and that those risks may outweigh the value of code that is, in fact, trivial. His larger point was more about the lack of security in the npm ecosystem in that packages get removed and potentially replaced with malicious code since anyone could take the same package name. Here's the article (since you don't actually link to it).
So, even if you accept your argument that even trivial code isn't that trivial (which, fwiw, I don't), it doesn't even address his actual concern which was that trivial dependencies needlessly open your app up to potential security risks for minimal gain.
Yes, the library does check for non-integers and non-number values and throws an error in both cases, but this added a whole 4 lines of code to the core library (and not much more to the tests). You'd never guess the solution was still so simple given the manner if which you've chosen to present it.
4 lines of code can contain a lot of nuance and complexity. Without looking at the is-odd source, would you have known the best way to check if a floating point number is a whole number? Would you have known the appropriate built-in exception to be thrown in order to be semantically correct?
Here is a single line of code from the is-odd source:
return !!(~~i & 1);
Care to explain what this single line of code is doing, and why?
However, the bigger point the author of the article (rather than the comment) made was that there are potential risks that come with adding dependencies and that those risks may outweigh the value of code that is, in fact, trivial.
This was addressed as a result of the left-pad incident, specifically, the possibility of an unpublished package being replaced with a malicious package. Beyond this already addressed issue, your argument is applicable to literally all open-source development.
The kicker here is that trivial dependencies are far easier to audit, so even if you were going to take a hard-line paranoid approach, you seem to imply that bigger libraries are favorable because... well I'm not sure what your justification is. I'm pretty sure you're not either.
Brian Rinaldi is a Developer Experience Engineer at LaunchDarkly with over 20 years experience as a developer for the web. Brian is active in the community running CFE.dev and Orlando Devs.
you seem to imply that bigger libraries are favorable because... well I'm not sure what your justification is. I'm pretty sure you're not either.
Hmmm.. Was I in any way this condescending in my comment? I don't think so.
Moving past that though, I was stating that the argument you rebut does not actually make the case you are rebutting (i.e. that trivial packages are not of value simply because they are trivial). Personally, I think his security concern is slightly overblown. However, I also feel that developers tend to add libraries without being aware of what is in them (or what is in the dependencies of their dependencies and so forth) - in which case they do open themselves up to potential security risks. It might be trivial to audit a trivial dependency, but that doesn't mean most developers are actually doing the auditing. I do think the danger is there that developers unintentionally install something malicious simply out of a complete lack of awareness rather than as a patch to a trivial dependency (which is what he argues).
I also think the triviality of things like is-odd makes it a needless dependency. If you don't want to write it yourself, why not take the 4 lines of code (and tests) and pop it into a utility library of some sort? This isn't really a maintenance issue - the code for a function of this sort is unlikely to ever change. It's not like you're missing out on some important update to how odd numbers are determined. This removes both the risk of installing a trivial library that you probably aren't auditing while also removing the risk of breaking due to the dependency being removed. Are both those risks trivial? Perhaps, but so is the code.
Was I in any way this condescending in my comment? I don't think so.
I certainly perceived as much. This article was sparked by a comment I read, and you seemed to take issue with the fact that I wasn't addressing the the article that the comment was in response to. I happen to disagree with the article as well, but that's not what I was addressing.
Again, your issue seems to be with the inherent trust we as developers place in the open source libraries we consume. This is not specific to NPM, or trivial libraries, it's inherent to open-source development. If this particular issue is something you feel strongly about, I suggest you write a post about it.
Brian Rinaldi is a Developer Experience Engineer at LaunchDarkly with over 20 years experience as a developer for the web. Brian is active in the community running CFE.dev and Orlando Devs.
I didn't intend it to be condescending. So I apologize if you perceived it that way. I did think the context of the comment, especially given that it's author was being intentionally abrasive (he even admits to "going there") was important since it gave a potential misconception that the article it responded to made that sort of exclusionary argument (i.e. the "you're not a real developer unless..." type of argument) about trivial libraries.
Finally, I, in no way, made the case that developers should be broadly distrusting of open source. You generalize my argument. There is a risk/reward balance and the risk isn't just malicious code - it could also be that a removed or broken dependency breaks my build, which may or may not be a simple fix. In my view, the risk for a trivial dependency does not outweigh the reward. In your view, it does.
// , “It is not so important to be serious as it is to be serious about the important things. The monkey wears an expression of seriousness... but the monkey is serious because he itches."(No/No)
So the comment you cite is obnoxious and unnecessary for sure, but it's funny that you cite that comment rather than anything in the article, which makes a number of important points imo. Let's look at is-odd, for instance. Yes, the library does check for non-integers and non-number values and throws an error in both cases, but this added a whole 4 lines of code to the core library (and not much more to the tests). You'd never guess the solution was still so simple given the manner in which you've chosen to present it.
However, the bigger point the author of the article (rather than the comment) made was that there are potential risks that come with adding dependencies and that those risks may outweigh the value of code that is, in fact, trivial. His larger point was more about the lack of security in the npm ecosystem in that packages get removed and potentially replaced with malicious code since anyone could take the same package name. Here's the article (since you don't actually link to it).
So, even if you accept your argument that even trivial code isn't that trivial (which, fwiw, I don't), it doesn't even address his actual concern which was that trivial dependencies needlessly open your app up to potential security risks for minimal gain.
4 lines of code can contain a lot of nuance and complexity. Without looking at the
is-oddsource, would you have known the best way to check if a floating point number is a whole number? Would you have known the appropriate built-in exception to be thrown in order to be semantically correct?Here is a single line of code from the
is-oddsource:return !!(~~i & 1);Care to explain what this single line of code is doing, and why?
This was addressed as a result of the
left-padincident, specifically, the possibility of an unpublished package being replaced with a malicious package. Beyond this already addressed issue, your argument is applicable to literally all open-source development.The kicker here is that trivial dependencies are far easier to audit, so even if you were going to take a hard-line paranoid approach, you seem to imply that bigger libraries are favorable because... well I'm not sure what your justification is. I'm pretty sure you're not either.
Hmmm.. Was I in any way this condescending in my comment? I don't think so.
Moving past that though, I was stating that the argument you rebut does not actually make the case you are rebutting (i.e. that trivial packages are not of value simply because they are trivial). Personally, I think his security concern is slightly overblown. However, I also feel that developers tend to add libraries without being aware of what is in them (or what is in the dependencies of their dependencies and so forth) - in which case they do open themselves up to potential security risks. It might be trivial to audit a trivial dependency, but that doesn't mean most developers are actually doing the auditing. I do think the danger is there that developers unintentionally install something malicious simply out of a complete lack of awareness rather than as a patch to a trivial dependency (which is what he argues).
I also think the triviality of things like is-odd makes it a needless dependency. If you don't want to write it yourself, why not take the 4 lines of code (and tests) and pop it into a utility library of some sort? This isn't really a maintenance issue - the code for a function of this sort is unlikely to ever change. It's not like you're missing out on some important update to how odd numbers are determined. This removes both the risk of installing a trivial library that you probably aren't auditing while also removing the risk of breaking due to the dependency being removed. Are both those risks trivial? Perhaps, but so is the code.
I certainly perceived as much. This article was sparked by a comment I read, and you seemed to take issue with the fact that I wasn't addressing the the article that the comment was in response to. I happen to disagree with the article as well, but that's not what I was addressing.
Again, your issue seems to be with the inherent trust we as developers place in the open source libraries we consume. This is not specific to NPM, or trivial libraries, it's inherent to open-source development. If this particular issue is something you feel strongly about, I suggest you write a post about it.
I didn't intend it to be condescending. So I apologize if you perceived it that way. I did think the context of the comment, especially given that it's author was being intentionally abrasive (he even admits to "going there") was important since it gave a potential misconception that the article it responded to made that sort of exclusionary argument (i.e. the "you're not a real developer unless..." type of argument) about trivial libraries.
Finally, I, in no way, made the case that developers should be broadly distrusting of open source. You generalize my argument. There is a risk/reward balance and the risk isn't just malicious code - it could also be that a removed or broken dependency breaks my build, which may or may not be a simple fix. In my view, the risk for a trivial dependency does not outweigh the reward. In your view, it does.
No. No that is hideous and will haunt my dreams.
I am reminded of my many failed attempts to learn client-side javascript well enough to be productive.
"So, bruh... you've been figuring out how to get that date picker to work with left justification, for what, 2 weeks now?"
"Yes. Yes, for 2 weeks. At this point, I'm ready to publish an academic paper on it for Cornell."