Why just on iterators and not on arrays?

[ljharb]

I have this need on Arrays just as often as on non-array iterators; any reason not to add it to both?

[tophf]

The general principle here is "performance footgun", where browsers especially (I represent V8/Chrome) don't want the slow thing to be too easy to reach for.

Sounds like this approach may turn JS into Java with its super verbosity that's still not preventing the apps from being very slow. Anything can be a performance footgun in any language, JS included, even the best practices can be applied incorrectly.

[towerofnix]

I think ^ what @tophf says is true in a strict sense... but I also totally understand where the reasoning comes from. I wouldn't want to make the assumption that this sort of API surface (let's say as a decision by ECMAScript, affecting a basic interface in the language, not a more specialized web API) truly has an impact on the observed performance of apps or the broad experience of devs writing those apps wrt performance.

But, the reasoning is sound: reach for the easiest API, and Iterator.zip().toArray() is indeed the easiest; write that enough times and you may start asking yourself just what the deal is with this fancy little Iterator namespace. It's as simple as a teeny-tiny Tinker Bell voice saying "think about me! think about me!", which does add up eventually, though it's no major bother to swat away in the meanwhile!

I think it's very likely there is a general precedence for, like, making one operation easier than another, by making the latter operation composed out of two smaller parts (e.g. Iterator and toArray), because you want people to be thinking about the parts individually & considering, maybe reconsidering, why they are composing them like this. There's always an inherent benefit to that (as discussed!).

I think it'd be worth finding/sharing cases of that in general (for calls ECMAScript has made), but also to do with performance in specific. IMO performance being one of the weakest points of products made for the web (which feels like "basically all products", to us people who are always surrounded by the web, LOL)—the impact that ECMAScript decisions has on that should be assessed more closely, more rigorously. Best not to assume that your reasoning, despite being sound, actually has the impact you are going for, especially in a crucial area.

I don't say any of this to suggest anyone is making these assumptions, just sharing my angle! I don't want to come across with an aggressive tone, "examples or it didn't happen", but I do think identifying the impact ECMAScript decisions have practically had on performance would be pretty crucial to strengthening or weakening this argument, and a worthwhile effort.

I'm also OK with giving this more weight than I initially did, like, I do think aiding developers to write more performant code for the web - a context where no one writes performant code in part because it's so easy not to - is a valid concern. (The question is "how much 'in part', and how much can ECMAScript have an impact on this?")

I think this is a good angle to figure out in more detail and that, uh, it may require a significant amount of effort and discussion both outside and inside committee, that would be best suited on a proposal which is maybe pivotally affected by this angle. Not treated as something that blocks progress on Iterator.zip w/o Array.zip, because Array.zip can always be added later once it's decided if the performance-through-language-surface concern is best to drop or approach differently.

Oh right, and obviously you can't go back on adding Array.zip. If you don't add it now and you do watch how developers start interacting with Iterator.zip, then of course that's setting our own precedence on exactly this subject. It's a study worth paying attention to just as much as looking at examples in previous additions to the language.

[michaelficarra]

The committee decided to move forward with this proposal without the Array variants at the June plenary. Closing.