Hacker News Reader

Comment by presentation | Hacker News Reader

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.

View on HN

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.

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.

ECMAScript has gone through many revisions since its inception, so it is clearly possible to modify the language.

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.

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.

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.

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.

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.

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.

Reply on news.ycombinator.com