The biggest insight in that thread is how big of a jerk "PublicByte" is. I sure hope I never have th misfortune of working with that person or anyone like him.
Yeah that person really dialed things up to 11 there. But I think it's a tone that stems from a legitimacy thing with javascript having a super low barrier to entry.
Did you actually read the function in this library. While yes it's a single line I'm convinced that anyone who thinks this is an "obvious" implementation hasn't actually read the code.
ES5 is a low requirement. I'd rather use a lib that did a better job than one that returns true for the string '[object Array]' or have the app decide for itself what its own types are.
It’s completely stupid that this kind of module gets used in the JavaScript ecosystem, but as the author points out, it’s not his fault, it’s downstream modules’ fault for actually using something so trivial.
It’s deeply unfortunate that the lack of a standard library in JavaScript combined with the constraint of wanting to minimize shipped code size in a language that resisted dead code elimination for a long time led to... whatever this is, instead of a comprehensive stdlib.
first commit is from 2013 [0], first Node that had Array.isArray was 0.1.15 from 2009 [1], thus making is as Node module was pointless, but polyfill for browsers might have some sense.
People keep saying this is "so trivial", denigrating anyone who would use this, but I am convinced they haven't even looked at the "one line of code" they are denigrating.
I've been a JS/Node dev for years now (granted, post a time when Array.isArray was part of the standard), and if someone asked me to write isArray, I wouldn't have done it like this, and I'm assuming there is a reason it was done like this.
What I really see is a bunch of typical "I'm a cooler dev than you" posturing for people who haven't even actually looked at the code. That's a shame because there is a valid discussion to be had around how lots of teeny dependencies can make the npm ecosystem brittle, but bullshit posturing around how any dev should be able to write this one line is just false.
Sure, ok. I can buy that this is not actually completely trivial, and that it's worth bringing code to solve this problem in from some other source.
Still, it's a shame that the specifics of the way the JavaScript ecosystem has evolved mean that it's commonplace to bring in a <10 line dependency to mitigate an extremely core lack of functionality, rather than have a first-party—or be able to sensibly import a third-party—standard library. I can't think of any other language ecosystem where this is normal.
Again, did you even read the package? This is part of the JS standard, and has been for years. This is basically just a polyfill for people that need to support very (very) old browsers.
I don't understand the mindset of "you did it wrong once, so you can't do it anymore, you must let me do it for you."
Why is the fact that some devs sometimes screw up one-liners of any material importance to the existence of this library?
Some devs write code with bugs, does that mean they shouldn't write code any more? Is it either you write pristine, bug-free code on the first try for everything, or else you should be relegated to the back room gluing things together built by the _real_ devs? This is such snooty behavior that I'm not surprised at all by a response like the angry dude in there. He's an asshole for sure, but he's not totally wrong in my view.
I’m with you. Some people occasionally forget semicolons, should we have a library for that too? “Wrap all your statements in this pre-processor function call (it’s just another line in your build pipeline) and we’ll take care of the semicolons for you.”
1. This stems from JS having literally no stdlib or convenience functions to speak of.
2. Array.isArray was added to browsers in 2009-2011. The time when IE 6 was still alive and kicking. No idea when it was added to node
3. This package plugged a hole in the stdlib, so obviously people started using it
4. It does on thing, and does it well. Unix-way!
5. How is using it any different than having the same code in a 20000-line utils.js file that any project inevitably grows to have to plug holes in JS's libs?
Native Array.isArray was added to IE9 and Chrome 5, meaning totally obsolete node v0.8 supports it. Hard to imagine who really needs the library in 2020.
Array.isArray has been implemented in 1.3.16 of V8 [0] which was used in node 0.1.15! [1] doubt that someone even is using that old node.js this to me looks like 3rd-party packages that were added very long ago and the code was never updated.
For the betterment of the npm ecosystem the company should step in and depreciate all these simple packages. Or take over the responsibility over them for security reasons.
Which company? Npm Inc? Github? Microsoft? Google? Mozilla?
Each of those would cause an outroar, and it would be near-universally agreed that having a decentralized ecosystem is better than being beholden to the whims of $company. (it doesn't help that 3/5 of the companies I mentioned are Microsoft, famous for embrace-extend-extuinish)
In regards to his reply in issue 27...The bummer is you often don't know whether you use it or not. If I want to use react and react is using package x which depends on package y which depends on package z. Of course you could check your packages, but how many of us are really looking through all those minor dependencies.
If you don't like that a package you're using depends on this via a dependency chain then you're free to PR into the respective upstream package to either inline this code or (in this case) to drop the support for an older version of Node (within a breaking change, if necessary).
In general, you can always avoid picking packages with deep dependency chains. That seems like a good idea to me.
Also, I think `isarray` is quite dated, but I can understand why people used to use it, since it is basically an explicit polyfill for non-browser environments.
You can think of these NPM micropackages as Github Gist snippets that you can programmatically link to your code.
The first advantage to just copy-pasting is that the snippet author might update it (e.g. if he finds a faster/safer way to do the one thing his package does), and you don't have to do anything.
Imagine finding a solution on Stackoverflow and just being able to import foo from stackoverflow/a/12345, and when the community finds a better way to do it, your software is automatically using the new version!
The second advantage is that it's basically built-in refactoring: Code from these micropackages will not litter your code, there is a clean separation between what is your business logic vs where you just need some generic functionality.
> The first advantage to just copy-pasting is that the snippet author might update it
The first disadvantage of “micro packages” over copy-pasting is that the author might update it to do something completely different - either because the author is malicious, or because of a transfer in maintainership of the package to someone who is malicious, or because of a compromise.
> Imagine finding a solution on Stackoverflow and just being able to import foo from stackoverflow/a/12345, and when the community finds a better way to do it, your software is automatically using the new version!
The downside is, your code and your heavier libraries now have their dependencies changing constantly, which can lead to things breaking if either depend on specific behavior, or if the micro package author does something wrong.
It's a trade off, although personally I've been bit by that enough to keep strict version numbers in my dependencies.
> Imagine finding a solution on Stackoverflow and just being able to import foo from stackoverflow/a/12345, and when the community finds a better way to do it, your software is automatically using the new version!
That sounds like a security nightmare, and broken functionality waiting to happen.
There are issues with micropackaging functions and code, and the fact that they didn't exist as a concept when the JavaScript language was being designed may contribute to that - but I don't think that it's clear whether micropackaging will turn out to be a good or bad trend overall.
Hundreds of thousands of untested, unaudited implementations of a roughly-similar function _could_ be far worse in terms of overall ecosystem stability and security than a small number of frequently-used (albeit yes, potentially flawed and vulnerable) micropackage dependencies.
The outcome for each micropackage may depend on how much scrutiny and test coverage is available when updates occur, and how well-defined the package's API is.
In a sense, that's not hugely different to version upgrades for other, larger library dependencies. Incremental library changes tend to be easier for developers to audit and integrate, so perhaps eventually this is a better approach?
In my opinion Microsoft (via GitHub and NPM) are likely best-placed to make significant progress on evaluating and improving the situation.
When a micropackage is updated, they're in a position where they could run continuous integration tests not just for the package itself, but also for dependent packages, to gain an early sense for the correctness and disruption potential of the change.
That kind of information would be useful to make a micropackaging ecosystem more viable and healthy, although it would also increase the ecosystem's long-term dependence on Microsoft.
There is a middle ground between hundreds of thousands of untested, unaudited implementations of a roughly-similar functions, and packages which auto update without the developer doing anything at all.
At the least you want some oversight when a dependency changes under you.
As someone studying programming languages I used to be shocked by such practice as well — but later on I realized that, for people doing this, they really don’t have any practical motivation to care much beyond getting it to work first for immediate business needs.
Similarly, many more “principled” programmers don’t really understand many parts of our computing stack either and it did bring troubles to even the most experienced veterans in the industry.
It is always a trade-off between risk, cost, and benefit.
That would be true if it was "the community". But it's not. It's one person. So you're literally giving Julian Gruber commit access to your production environment in the hope that he finds a better way of doing something that is a polyfill for something that browsers now do better.
I don't understand how that is a rational decision that people are making. Can anyone explain?
> The first advantage to just copy-pasting is that the snippet author might update it (e.g. if he finds a faster/safer way to do the one thing his package does), and you don't have to do anything.
First, please don't copy paste solutions. Understand them and implement correctly. Stackoverflow is not a magic library you should take books from without understanding.
> Imagine finding a solution on Stackoverflow and just being able to import foo from stackoverflow/a/12345, and when the community finds a better way to do it, your software is automatically using the new version!
Wow, I've just imagined it. Props for the great horror story, but... it's a security nightmare. You basically surrender all control over your project for almost nothing.
> The second advantage is that it's basically built-in refactoring: Code from these micropackages will not litter your code, there is a clean separation between what is your business logic vs where you just need some generic functionality.
Writing this utility in a separate code unit (namespace, project, whatever) gives exactly the same advantage.
And micropackages will litter my building process / dependency tree.
Small packages like this are key to easily/quickly building polyfill, backport, backcompat bundles for deployment in environments that are quite a bit behind in terms of language support. They still exist and they are still making people money. Having a stdlib in JavaScript would not preclude packages like this due to the afore mentioned legacy environments.
NPM bashing is increasingly popular, and for folks that haven't had to utilize these tiny packages they probably do rightly seem superfluous. Are people abusing it? Probably. Is it being used where it doesn't need to be? Probably. Are there long-stable, rarely changed NPM packages created before `Array.isArray` was a thing, which have this as a transitive dependency? Definitely.
This argument makes a ton of sense to me. Why is this not how most people explain it, rather than "all developers are stupid and they mess up one-liners so we should write their software for them"?
How it normally goes:
A: why does this exist it's one line?
B: people mess up one-liners all the time.
A: those people are dumb and shouldn't be programmers
How it should go:
A: why does this exist, it's one line?
B: it's not about that, it's used to easily/quickly compose with other similar functions into more complicated things like polyfill, backport, and backcompat bundles for deployment in environments that are quite a bit behind in terms of language support.
No, I'd maybe run them once just to check it covers the corner-cases. The code is never going to change, because it's a polyfill for old browsers, and only needed for legacy environments that won't change. So if the tests pass once, they'll pass forever. There is literally no point in adding those tests to my test suite - there is no combination of changes that will ever make this fail if it passes once.
I've wondered this too. I've seen someone make a COVID data library but I thought about how much more difficult it would be to learn the library instead of just importing and manipulating the data.
My best thought is that it saves time to import, it saves visual lines which may make it easier to understand what is code ripe for modification and code that shouldn't be changed.
My response to that is, "Is your company really OK with copy-pasting from Stack Overflow into their production system?" Do you know what license the Stack Overflow content is released under [1]? Is that license compatible with your company's software? Are you complying with the terms of that license, including providing any required attribution? Who gets sued or fired if that copy-pasted code doesn't work? What goes into the post-mortem?
Similarly, is your company really OK with you just pulling in a dependency and coding onward? Do you review each external dependency's license for compatibility with your company's software? Do you audit each dependency for security issues, backdoors, and other bugs? What dependencies do your dependencies rely on, and have you reviewed them, too? How do you know the dependency works as you think it should work? What is the maintenance plan for this dependency? How often do you plan to update the dependency, and when you do, do you plan to re-audit it?
As someone who has worked on safety-critical marine and aerospace applications, this casual attitude about pulling in dependencies and copy-pasting code is so foreign to me! Is this yolo attitude really how it works in the move-fast-and-break-things universe? No large company I ever worked for would allow any of this without proper vetting and reviewing--even on non-safety-critical programs. Really interesting and scary how best practices are defined in various areas of the software development world!
It's 5 lines of code. Yes I'm fine with copy-pasting that into a production system. Yes I just reviewed it, by reading the 5 lines of code and deciding that they were OK to deploy to a production system.
I totally get your point, though, and completely agree with you on more complex examples. I would not feel comfortable copy-pasting code into my system that I didn't understand or hadn't read through completely. And I avoid dependencies as much as possible.
JavaScript has had isArray a long time--even IE 9 has it. I'm surprised that there is enough active development going on for browsers that don't have it to lead to 40 M downloads a week.
I'd have expected most things that have to support browsers that old would be mature projects that do not get much active development.
I'm always glad when there's an npm package for something, no matter how small, and I don't have to sift through stackoverflow answers, particularly when something is hard to test, like browser support. 40 million people using a package is far better evidence then a few hundred people upvoting an answer.
Until the micropackage has a security vulnerability, and the secure version is a breaking change, and the vulnerable version is locked in deep in your dependency tree.
What does this tell us about the energy efficieny about the whole Javascript ecosystem?
I am not in the position to make realistic estimates, but it sounds pretty wasteful. I have worked in mobile devices space and there you need to think about about energy efficiency to have your battery last. Shouldn't the server and Web guys need to do the same to save the planet?
Not pointing to isarray in particular, but this looks like a tremendous overhead to get minimal functionality. Is isarray an exception we can ignore or a pattern that repeats in scale?
Does browserlist not help with packages like this in any way? Ie if you aren’t supporting IE6 or whatever, doesn’t something throw up a warning like “you probably don’t need this package”.
> ...the following four lines of code will glide right through even the strictest content security policy.
> (In an earlier iteration of this post I said that a solid content security policy would keep you (and I quote) “100% safe”. Unfortunately 130k people read that before I learned the above trick. So I guess the lesson there is that you can’t trust any thing or any one on the internet.)
Though the approach only applied to Chrome, and the post is two years old so I don't know if it still works today?
Ok, this is crazy, somewhat I can understand guy making this just as joke, but who are those 40 million who download it each week?!
What is next each line on GitHub will become npm module?
76 comments
[ 4.1 ms ] story [ 145 ms ] threadhttps://github.com/juliangruber/isarray/blob/master/index.js
https://news.ycombinator.com/newsguidelines.html
It’s deeply unfortunate that the lack of a standard library in JavaScript combined with the constraint of wanting to minimize shipped code size in a language that resisted dead code elimination for a long time led to... whatever this is, instead of a comprehensive stdlib.
- [0] https://github.com/juliangruber/isarray/commit/c8601522e3136...
- [1] https://github.com/nodejs/node-v0.x-archive/blob/v0.1.15/Cha...
I've been a JS/Node dev for years now (granted, post a time when Array.isArray was part of the standard), and if someone asked me to write isArray, I wouldn't have done it like this, and I'm assuming there is a reason it was done like this.
What I really see is a bunch of typical "I'm a cooler dev than you" posturing for people who haven't even actually looked at the code. That's a shame because there is a valid discussion to be had around how lots of teeny dependencies can make the npm ecosystem brittle, but bullshit posturing around how any dev should be able to write this one line is just false.
Still, it's a shame that the specifics of the way the JavaScript ecosystem has evolved mean that it's commonplace to bring in a <10 line dependency to mitigate an extremely core lack of functionality, rather than have a first-party—or be able to sensibly import a third-party—standard library. I can't think of any other language ecosystem where this is normal.
Why is the fact that some devs sometimes screw up one-liners of any material importance to the existence of this library?
Some devs write code with bugs, does that mean they shouldn't write code any more? Is it either you write pristine, bug-free code on the first try for everything, or else you should be relegated to the back room gluing things together built by the _real_ devs? This is such snooty behavior that I'm not surprised at all by a response like the angry dude in there. He's an asshole for sure, but he's not totally wrong in my view.
2. Array.isArray was added to browsers in 2009-2011. The time when IE 6 was still alive and kicking. No idea when it was added to node
3. This package plugged a hole in the stdlib, so obviously people started using it
4. It does on thing, and does it well. Unix-way!
5. How is using it any different than having the same code in a 20000-line utils.js file that any project inevitably grows to have to plug holes in JS's libs?
https://caniuse.com/?search=isArray
- [0] https://chromium.googlesource.com/v8/v8/+/refs/tags/1.3.16
- [1] https://github.com/nodejs/node-v0.x-archive/blob/v0.1.15/Cha...
Each of those would cause an outroar, and it would be near-universally agreed that having a decentralized ecosystem is better than being beholden to the whims of $company. (it doesn't help that 3/5 of the companies I mentioned are Microsoft, famous for embrace-extend-extuinish)
In general, you can always avoid picking packages with deep dependency chains. That seems like a good idea to me.
Also, I think `isarray` is quite dated, but I can understand why people used to use it, since it is basically an explicit polyfill for non-browser environments.
The first advantage to just copy-pasting is that the snippet author might update it (e.g. if he finds a faster/safer way to do the one thing his package does), and you don't have to do anything.
Imagine finding a solution on Stackoverflow and just being able to import foo from stackoverflow/a/12345, and when the community finds a better way to do it, your software is automatically using the new version!
The second advantage is that it's basically built-in refactoring: Code from these micropackages will not litter your code, there is a clean separation between what is your business logic vs where you just need some generic functionality.
The first disadvantage of “micro packages” over copy-pasting is that the author might update it to do something completely different - either because the author is malicious, or because of a transfer in maintainership of the package to someone who is malicious, or because of a compromise.
What a nightmare!
It's a trade off, although personally I've been bit by that enough to keep strict version numbers in my dependencies.
That sounds like a security nightmare, and broken functionality waiting to happen.
How on earth have we got here?
Hundreds of thousands of untested, unaudited implementations of a roughly-similar function _could_ be far worse in terms of overall ecosystem stability and security than a small number of frequently-used (albeit yes, potentially flawed and vulnerable) micropackage dependencies.
The outcome for each micropackage may depend on how much scrutiny and test coverage is available when updates occur, and how well-defined the package's API is.
In a sense, that's not hugely different to version upgrades for other, larger library dependencies. Incremental library changes tend to be easier for developers to audit and integrate, so perhaps eventually this is a better approach?
In my opinion Microsoft (via GitHub and NPM) are likely best-placed to make significant progress on evaluating and improving the situation.
When a micropackage is updated, they're in a position where they could run continuous integration tests not just for the package itself, but also for dependent packages, to gain an early sense for the correctness and disruption potential of the change.
That kind of information would be useful to make a micropackaging ecosystem more viable and healthy, although it would also increase the ecosystem's long-term dependence on Microsoft.
At the least you want some oversight when a dependency changes under you.
Otherwise you can (and should) review the update manually or using automated tools.
Similarly, many more “principled” programmers don’t really understand many parts of our computing stack either and it did bring troubles to even the most experienced veterans in the industry.
It is always a trade-off between risk, cost, and benefit.
That seems to have happened here, though who knows across X number of browsers and whatever JS engine updates happen.
https://github.com/juliangruber/isarray/commit/1052c9d94dc87...
I don't understand how that is a rational decision that people are making. Can anyone explain?
First, please don't copy paste solutions. Understand them and implement correctly. Stackoverflow is not a magic library you should take books from without understanding.
> Imagine finding a solution on Stackoverflow and just being able to import foo from stackoverflow/a/12345, and when the community finds a better way to do it, your software is automatically using the new version!
Wow, I've just imagined it. Props for the great horror story, but... it's a security nightmare. You basically surrender all control over your project for almost nothing.
> The second advantage is that it's basically built-in refactoring: Code from these micropackages will not litter your code, there is a clean separation between what is your business logic vs where you just need some generic functionality.
Writing this utility in a separate code unit (namespace, project, whatever) gives exactly the same advantage. And micropackages will litter my building process / dependency tree.
NPM bashing is increasingly popular, and for folks that haven't had to utilize these tiny packages they probably do rightly seem superfluous. Are people abusing it? Probably. Is it being used where it doesn't need to be? Probably. Are there long-stable, rarely changed NPM packages created before `Array.isArray` was a thing, which have this as a transitive dependency? Definitely.
How it normally goes:
A: why does this exist it's one line?
B: people mess up one-liners all the time.
A: those people are dumb and shouldn't be programmers
How it should go:
A: why does this exist, it's one line?
B: it's not about that, it's used to easily/quickly compose with other similar functions into more complicated things like polyfill, backport, and backcompat bundles for deployment in environments that are quite a bit behind in terms of language support.
A: oh, neat, thanks!
For anyone who imported this as a dependency, why didn't you copy-paste the five lines into your code? I'm genuinely curious.
My best thought is that it saves time to import, it saves visual lines which may make it easier to understand what is code ripe for modification and code that shouldn't be changed.
Similarly, is your company really OK with you just pulling in a dependency and coding onward? Do you review each external dependency's license for compatibility with your company's software? Do you audit each dependency for security issues, backdoors, and other bugs? What dependencies do your dependencies rely on, and have you reviewed them, too? How do you know the dependency works as you think it should work? What is the maintenance plan for this dependency? How often do you plan to update the dependency, and when you do, do you plan to re-audit it?
As someone who has worked on safety-critical marine and aerospace applications, this casual attitude about pulling in dependencies and copy-pasting code is so foreign to me! Is this yolo attitude really how it works in the move-fast-and-break-things universe? No large company I ever worked for would allow any of this without proper vetting and reviewing--even on non-safety-critical programs. Really interesting and scary how best practices are defined in various areas of the software development world!
1: https://stackoverflow.com/help/licensing
I totally get your point, though, and completely agree with you on more complex examples. I would not feel comfortable copy-pasting code into my system that I didn't understand or hadn't read through completely. And I avoid dependencies as much as possible.
Isn't this what babel is for?
I'd have expected most things that have to support browsers that old would be mature projects that do not get much active development.
I am not in the position to make realistic estimates, but it sounds pretty wasteful. I have worked in mobile devices space and there you need to think about about energy efficiency to have your battery last. Shouldn't the server and Web guys need to do the same to save the planet?
Not pointing to isarray in particular, but this looks like a tremendous overhead to get minimal functionality. Is isarray an exception we can ignore or a pattern that repeats in scale?
Not to mention the exclusiveness: more than 3 billion people on this planet
- have old computer and phones with limited RAM
- ...and limited storage
- ...and slow CPUs
- have slow Internet access (even in "developed" countries if you are in low-density areas)
- have traffic caps (same)
- sometimes have intermittent Internet access
- have unreliable or expensive electricity
Reminder: this is not an inevitable problem. A lot of Linux distros run just fine on old hardware, and websites without cruft are still usable.
1. https://medium.com/hackernoon/im-harvesting-credit-card-numb...
> (In an earlier iteration of this post I said that a solid content security policy would keep you (and I quote) “100% safe”. Unfortunately 130k people read that before I learned the above trick. So I guess the lesson there is that you can’t trust any thing or any one on the internet.)
Though the approach only applied to Chrome, and the post is two years old so I don't know if it still works today?
https://github.com/zlatinejc/isnotarray