13 ms·

I mean, that isArray example is exactly the kind of code that 99% of developers wouldn't come up with on their own, since it's not intuitive at all to check whe

I mean, that isArray example is exactly the kind of code that 99% of developers wouldn't come up with on their own, since it's not intuitive at all to check whether or not the value is an array in that way. If anything I would just be in favor of a name for the package that made it clear that it's intended for legacy compatibility.

m0lecules 5y ago
There's tons of little utility features like this that are IMO the core of why people use libraries in javascript, but could easily be replaced by a common library offered by the browser. Base64/hex/binary conversion, type checking, DOM access shortcuts, etc. etc.
progval 5y ago
They could find it on StackOverflow and copy-paste it. Searching for "Javascript is array" on DDG or Google even returns the SO answer before the NPM package.
19h 5y ago
It’s also wrong because the representation wasn’t exactly always deterministic in 2013 across all js engines. The right way to check for an array is value.constructor === Array, which also doesn’t really make any sense because an array in JS really is just an object with a length key and respective keys names 0…n.
- l0b0 5y ago
  I've been using JS on and off in various incarnations, and this sort of blows my mind. First because I don't think I've ever seen that approach used anywhere, and second because it would probably take me upwards of an hour (possibly a day) to work out whether that would actually work.
- zirak 5y ago
  The constructor check would unfortunately not work for cross-frame arrays. Each frame has its own global object, with its own Array constructor. So: var iframe = document.createElement('frame'); document.body.appendChild(iframe); var value = iframe.contentWindow.Array(); value.constructor === Array // false value instanceof Array // false value instanceof iframe.contentWindow.Array // true Stringifying the constructor works even for cross-frame values: value.constructor.toString() === Array.toString() // true These days though, `Array.isArray` is the right thing to do, available since roughly 2010.
l0b0 5y ago
That points to the underlying problem: a crap standard library. If extremely common functionality has to be outsourced to (short but) completely non-obvious third party modules, the standard library has failed at its core task.
- maccolgan 5y ago
  JavaScript is in a situation different than most other languages. Any addition to the standard library has to be implemented by every browser on earth, and that's already unsustainable. Any imperfections or mistakes in the standard library (we are still distraught with the Referer bs) can't ever be fixed as all code has to be perpetually working.
  - l0b0 5y ago
    ECMAScript has gone through many revisions since its inception, so it is clearly possible to modify the language.
  - throwaway19937 5y ago
    That's just an excuse and a poor one at that. Many languages (C, Fortran, C++) have multiple implementations and don't get to fix design flaws in the standard library; JavaScript is not unique in these requirements. The only special thing about JavaScript is that after 25+ years the standard library is still grossly inadequate.

m0lecules 5y ago

There's tons of little utility features like this that are IMO the core of why people use libraries in javascript, but could easily be replaced by a common library offered by the browser. Base64/hex/binary conversion, type checking, DOM access shortcuts, etc. etc.

progval 5y ago

They could find it on StackOverflow and copy-paste it. Searching for "Javascript is array" on DDG or Google even returns the SO answer before the NPM package.

19h 5y ago

It’s also wrong because the representation wasn’t exactly always deterministic in 2013 across all js engines. The right way to check for an array is value.constructor === Array, which also doesn’t really make any sense because an array in JS really is just an object with a length key and respective keys names 0…n.

l0b0 5y ago
I've been using JS on and off in various incarnations, and this sort of blows my mind. First because I don't think I've ever seen that approach used anywhere, and second because it would probably take me upwards of an hour (possibly a day) to work out whether that would actually work.
zirak 5y ago
The constructor check would unfortunately not work for cross-frame arrays. Each frame has its own global object, with its own Array constructor. So: var iframe = document.createElement('frame'); document.body.appendChild(iframe); var value = iframe.contentWindow.Array(); value.constructor === Array // false value instanceof Array // false value instanceof iframe.contentWindow.Array // true Stringifying the constructor works even for cross-frame values: value.constructor.toString() === Array.toString() // true These days though, `Array.isArray` is the right thing to do, available since roughly 2010.

l0b0 5y ago

That points to the underlying problem: a crap standard library. If extremely common functionality has to be outsourced to (short but) completely non-obvious third party modules, the standard library has failed at its core task.

maccolgan 5y ago
JavaScript is in a situation different than most other languages. Any addition to the standard library has to be implemented by every browser on earth, and that's already unsustainable. Any imperfections or mistakes in the standard library (we are still distraught with the Referer bs) can't ever be fixed as all code has to be perpetually working.
- l0b0 5y ago
  ECMAScript has gone through many revisions since its inception, so it is clearly possible to modify the language.
- throwaway19937 5y ago
  That's just an excuse and a poor one at that. Many languages (C, Fortran, C++) have multiple implementations and don't get to fix design flaws in the standard library; JavaScript is not unique in these requirements. The only special thing about JavaScript is that after 25+ years the standard library is still grossly inadequate.