> both started the argument with the terrible first reply and escalated the argument with this accusation.
Why was the first reply terrible? They stated the policy and closed the PR. They did so professionally and calmly, and the author immediately threw a fit. Then the MDN person dug into the project more and found specific flaws and pointed them out as further evidence for why the policy (which they already cited and which should have been enough) exists.
> The person from MDN was saying factually incorrect stuff
Do you have specific examples?
> Most of the issue seems to be a systemic problem at Mozilla though.
Frankly, reading through the thread it feels like you started with this as the assumption and had cast the MDN maintainer as the bad guy before the exchange had even started. Mozilla has lots of problems and I'm the first to point them out, but this exchange doesn't demonstrate any of them—it just demonstrates how hard it is in open source to deal with entitled aspiring contributors.
Repeatedly calling it insecure and not to spec when it’s secure and it does the exact same thing unless given unusual input, and is as a ponyfill to ensure the dev is aware of its source when calling it. He also said he has relevant experience when questioned and showed an irrelevant example to support that claim.
Being spec compliant means being compliant with the entire spec, not just a "reasonable subset of the spec", picked by the author of the ponyfill/polyfill. And being secure only in the presence of normal inputs is... pretty meaningless afaict? Anything is secure if the inputs are "nice to the implementation". That isn't a typical bar for "it's secure".
Whether every use case that just wants to roundtrip BigInt through JSON _needs_ a fully spec compliant & generally secure solution is a different question. But at that point it's about picking a solution for a related use case, not about actually standing in for the upcoming browser feature.
> calling it insecure and not to spec when it’s secure and it does the exact same thing unless given unusual input
See, the "unless given unusual input" thing is part of where MDN was in the right and OP is in the wrong.
A polyfill/ponyfill that isn't perfectly spec-compliant can be useful, but it's reasonable for MDN to refuse to endorse it, given that their pages describe the specs. And to try to argue that it still counts as spec compliant when it doesn't handle edge cases is nonsense—the edge cases are why we have specs! If we didn't have to standardize even the edge cases an informal description of the solution would do the trick.
Why was the first reply terrible? They stated the policy and closed the PR. They did so professionally and calmly, and the author immediately threw a fit. Then the MDN person dug into the project more and found specific flaws and pointed them out as further evidence for why the policy (which they already cited and which should have been enough) exists.
> The person from MDN was saying factually incorrect stuff
Do you have specific examples?
> Most of the issue seems to be a systemic problem at Mozilla though.
Frankly, reading through the thread it feels like you started with this as the assumption and had cast the MDN maintainer as the bad guy before the exchange had even started. Mozilla has lots of problems and I'm the first to point them out, but this exchange doesn't demonstrate any of them—it just demonstrates how hard it is in open source to deal with entitled aspiring contributors.