21–30 of 54 posts
I read two paragraphs of this and was already sure this article is AI generated. Read more, and "This isn’t just about..." there we go
I was surprised to see such obviously low quality slop here on HN.
- https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- Array.prototype.values https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
This addresses a few criticisms here, and the main criticisms I had.
It feels pretty clear that the chains in that example (filter/map) are meant for operating on collections. And that if you're searching for a single item then chaining isn't the way to go?
Personally, if I knew I wanted only a single item I wouldn't feel more "nudged" towards appending a [0] on the end of a long chain rather than doing a refactor to the find().
As to:
data
.transform()
.normalize()
.validate()
.save();
As apples-to-apples unchained equivalent isn't really any better
const transformedData = transform(data);
const normalisedData = normalise(transformedData);
const validatedData = validate(normlisedData);
save(validatedData);
The point of chaining is generally to avoid making intermediate objects.
the intermediate objects are still created, they just aren't given names/saved to a specific memory location somewhere do you mean like streaming APIs where intermediate data structures aren't created? Is that what javascript does w/map() etc?
Yeah; this is what the new iterator methods were intended to solve
I actually think the first code block is easier to read. It's a familiar (to me) and simple pattern that is quick to read. I don't get how it would require more "decoding" than the second example which is more disjointed and needs more "parsing" for such a trivial case. Maybe it's about what you're used to?
I agree there are downsides to chaining. With more complex operations it can complicate debugging, and readability can suffer, so chaining is not a good fit there.
> Chaining nudges you toward “process everything,” even when that’s not what you meant to do. It feels pretty clear that the chains in that example (filter/map) are meant for operating on collections. And that if you're searching for a single item then chaining isn't the way to go? Personally, if I knew I wanted only a single item I wouldn't feel more "nudged" towards appending a [0] on the end of a long chain rather…
Nothing earth-shattering, but who never had to debug something someone saw in production once and never again, then any additional useful info is weighted in gold.
Earlier quoted context omitted.
the intermediate objects are still created, they just aren't given names/saved to a specific memory location somewhere do you mean like streaming APIs where intermediate data structures aren't created? Is that what javascript does w/map() etc?
> the intermediate objects are still created Yeah; this is what the new iterator methods were intended to solve https://x.com/MozDevNet/status/2029527411424219254
// This type of usage creates intermediates
array.map().filter()
// But these would not?
array.values().map().filter().toArray()
array.values().reduce()Earlier quoted context omitted.
the intermediate objects are still created, they just aren't given names/saved to a specific memory location somewhere do you mean like streaming APIs where intermediate data structures aren't created? Is that what javascript does w/map() etc?
> the intermediate objects are still created Yeah; this is what the new iterator methods were intended to solve https://x.com/MozDevNet/status/2029527411424219254