[JS] Ship ArrayBuffer.prototype.transfer proposal

[Rumyra]

Acceptance Criteria

• The listed features are documented sufficiently on MDN
• BCD is updated
• Interactive example and data repos are updated if appropriate
• The content has been reviewed as needed

For folks helping with Firefox related documentation

• Set bugs to dev-doc-complete
• Add entry to Firefox release notes if feature is enabled in release
• Add entry to Firefox experimental features page if feature is not yet enabled in release

Related Gecko bugs

https://bugzilla.mozilla.org/show_bug.cgi?id=1865103

Other

• Check content open issues to see if any pertain to the subject matter. If there are any that can be closed because of the work, do so. If there are any that can be fixed relatively quickly because of the knowledge from completing this issue and you have time, feel free to go ahead and fix them.
• Check if glossary updates are required for the feature you're documenting - whether an existing term needs to be updated or a new term should be added.
• Check if BCD update means that content pages need to have experimental markup removed or deprecated markup added (front matter tags and macros).

[hamishwillee]

This ships the ArrayBuffer.transfer() and friends. That was documented in 117 so really this is just release note/expr features plus a BCD update.

Status

• BCD FF122 ArrayBuffer.transfer() et al browser-compat-data#21714
• Docs - FF122 ArrayBuffer.transfer() and friends - remove experimental tagging #31213 (nothing else appears to be needed)
• Release note/Experimental features FF122 Relnote: ArrayBuffer transfer() and friends #31212
• dev-doc-complete

[ljharb]

Does MDN link to polyfills on npm for production use? If so, I'd love to see https://npmjs.com/arraybuffer.prototype.transfer, https://www.npmjs.com/package/arraybuffer.prototype.transfertofixedlength, and https://www.npmjs.com/package/arraybuffer.prototype.detached listed.

[Josh-Cena]

Does MDN link to polyfills on npm for production use?

Yes, but we typically only link to core-js because that one is integrated with Babel by default and thus most widely used. Unless other polyfills have significant advantages I don't think we want to have multiple links since it isn't our main goal to be exhaustive about polyfills. I see that we are lacking core-js links here so maybe I would check that later.

[Josh-Cena]

Ah, I see @zloirock already pointed that out in #31213 (comment); all good :)

[teoli2003]

Also, we are cautious with linking to external polyfills as they are a security risk: the owner of the external link can change the code. That's another reason why we link mainly to core-js or w3c polyfills. (The risk is not 0, but lower: if one of the two becomes problematic, the word will spread quickly, and we can monitor the situation.)

[ljharb]

Fair, but only linking to core-js is “picking a winner”, and i think my es-shims packages are a bit less of a security risk (or at least, no more) for a number of reasons.

In other words, i think it’s reasonable to ask that you list zero everywhere, or more than one everywhere.

[Josh-Cena]

I trust you and es-shims, but there's no reason to not trust core-js, and after all, core-js is used by default in Babel, which means more people unconsciously rely on it. After all, it is my opinion that one should never explicitly care about environment compatibility—configure the target and let toolings handle the rest.

[ljharb]

@Josh-Cena thats a fine reason to have included it so far, but i don’t think it’s a reason to only include it.

[hamishwillee]

I am not spot adding es-shims as part of this work.

Listing a single defacto standard option is how MDN avoids maintaining lists of things that regularly go out of date. I agree selecting corejs or any other option for this is self-reinforcing and that is a bit unfair. Just having one option is better for both users and for the MDN team though. Otherwise where do we draw the line?

If you want to continue this discussion then please create a discussion https://github.com/orgs/mdn/discussions with reasons why it would be better for users to have this option and why it is worth the maintenance cost to MDN. I expect you would need to add the links if agreed they are permitted. Note that the MDN does maintain the links in that we remove them once there is full/near full support across browsers, even if there is no great historical depth.

[ljharb]

@hamishwillee sure, that's fair, altho prior to the reorg, when it was a wiki, there were a number of es-shims links, because i put them there years ago - so someone must have removed them.

[ljharb]

@hamishwillee filed https://github.com/orgs/mdn/discussions/475, in which I reject your logical fallacy argument and point out that it is more choices that is better for users, which is why Mozilla and Firefox themselves exist.

[hamishwillee]

@ljharb Thanks. My argument is misrepresented - from MDN point of view it's more about whether we can maintain having multiple choices, and whether the benefit of offering those choices is worth the cost of that maintenance to MDN - and to users if we fail and the information rots. I've responded to that effect in your linked item. I'm hoping @Josh-Cena, @teoli2003 and others will weigh in on the technical merits there. Josh's view in particular "counts" since he is doing most of the maintenance in the JavaScript area.

[bsmth]

All of the linked tasks for this issue are resolved, so I'm closing this as done now. Thank you!