Added @ungap/raw-json Ponyfill

[WebReflection]

A 90LOC solution that reflects the current specs but it doesn't patch the global JSON can be found here: https://github.com/ungap/raw-json

Description

Motivation

Additional details

Related issues and pull requests

[github-actions]

Preview URLs

• /en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/isRawJSON

External URLs (1)

URL: /en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/isRawJSON
Title: JSON.isRawJSON()

• https://github.com/ungap/raw-json (1 time) (Note! This may be a new URL 👀)

[Josh-Cena]

Hello @WebReflection, nice project, however I don't think it fits our policy of external link inclusion:

1. We generally reject links to one's own work
2. We generally want some proof of popularity (downloads, stars...) before committing to suggesting it
3. We are particularly wary about links to polyfills, because (a) they will eventually be removed in favor of native solutions (b) they represent one of the most vulnerable attack vectors for supply chain attacks. Therefore, we have by convention decided that we will only include core-js polyfills.

For all these reasons, I'm going to close this. Thanks!

[WebReflection]

Therefore, we have by convention decided that we will only include core-js polyfills.

I've been writing JS polyfills since IE4 times, when no try/catch was even possible, to bring IE4, 5, 5.5, 6, 7, 8, Edge-legacy close to what FF offered in those days, and the entirety of @ungap project is to provide polyfills that work seamlessly everywhere, you can check the list in here.

This answer makes me feel like I won't contribute anymore to MDN, which I did plenty in the past, but as it doesn't respect my effort to push the Web forward, after 20 years of contribution in this very same field, I am not sure I should pay ever attention to it in the future.

We generally want some proof of popularity (downloads, stars...) before committing to suggesting it

What kind of metric is that? A 100% code-covered polyfill you can read and validate for something new nobody even knows existed before? Do you understand polyfills goal is to actually convince people they can use a new feature that has not landed yet in their browser so that popularity and something new can't possibly cope with each other as metric? Yeah, core-js has popularity in general, what's the metric around new polyfills there? None, same as mine!

I fully understand the vector attack concern, I just happen to produce tons of Open Source modules downloaded million times per months and I've thought I was kinda recognized in this Web field, this answer nuked everything I've done to date for the Web.

Thanks, and goodbye 👋

[Josh-Cena]

Again, we have a policy on external link inclusion (linked above), and one of the points, which we have constantly quoted for many link rejections, is we will nearly always reject links added by the author themselves, especially if the author does not disclose such relationship in case it's not apparent in the link. We only want community contributors to add links because that proves its popularity and credibility in the community. There are exceptions to this rule but for polyfills we want the rule to be even stricter. We once had a discussion and the general sentiment is we want to have as few references to polyfills as possible, because polyfills are really hard to get right and we should treat everything as insecure and wrong by default and not recommend any of them, but core-js is so front and central in the JS tooling world that we made an exception for it. I took a brief look at your code and I don't think it's spec-compliant enough to be advertised as a polyfill/ponyfill because it is prone to global pollution. At most it can be "a library that offers the same behavior as platform" but that would again not meet our criteria for usefulness. I'm not ignoring the work you have done in the JS ecosystem, and I understand your point about popularity metrics, but even looking org-wise, @ungap/promise-all-settled is the only JS polyfill with nontrivial download counts and it's dwarfed by core-js, so if we have to pick one player we will pick that (and if we have to pick a second it will be Jordan Harband's es-shims, but even that we haven't added, again per the decision above). Had it been something other than polyfills, such as links to libraries and frameworks that enable additional use cases, the decision may have come out differently.

[WebReflection]

We only want community contributors to add links because that proves its popularity and credibility in the community

As I've recently edited: what metric is that? popularity of what? This is an experimental feature, your same words, popularity makes no sense because it's new and experimental so you can't just get popularity from a single project that provides all polyfills to date, because that's anti-competition to start with as a concept.

If I publish a single polyfill, which is even a ponyfill in this case, and the wording was not casual because the module doesn't patch the global JSON, so it's even safer from that point of view, there's no way such project will ever have a popularity metric because it's ad-hoc and specific, for a single feature the Web is trying to land.

This is all broken from your side and you should consider trust metrics from people known in the field for "forever" and at the same time you are proposing an anti-competitive rule for your acceptance of PRs which leads to mafia related thinking.

Therefore, we have by convention decided that we will only include core-js polyfills.

Congrats, you are killing anyone else contribution to the Web by doing so.

[WebReflection]

Last thought:

We once had a discussion and the general sentiment is we want to have as few references to polyfills as possible, because polyfills are really hard to get right and we should treat everything as insecure and wrong by default and not recommend any of them

So review my ponyfill, test it against official tests, and tell me it's wrong, 'cause accepting core-js without passing through this validation doesn't make core-js polyfills any better, more reliable, more robust, or anything.

You either have a process to accept polyfills, or you don't ... "core-js is fine" is not an answer here and it will never be unless you have reasons to think so, and those reasons are public so that any other polyfill proposed that is 1/10th of the size can compete and be proposed, because in case anyone here forgot, size for polyfills matters too.

[Josh-Cena]

Trust and credibility can be built from past users. You are not new to the polyfill business, so if there's a stable user base of ungap projects then we would expect ungap users to contribute such links. I'm not comparing this new library with the whole core-js; I'm comparing the whole core-js with the whole ungap and I still see a disparity in popularity.

core-js also has a ponyfill mode by importing standalone packages without global pollution. As I pointed out, @ungap/raw-json cannot adequately claim 100% spec compliance because it is at least not robust to rewriting globals and native string checks (you did not override your polyfilled methods' toString). This is not to say it won't be useful at all, but again:

1. We don't want links to two projects that do the same thing because that creates paralysis of choice.
2. Most other polyfill libraries, as I have demonstrated above, are likely insecure and not 100% compliant. They get scrutinized and doubted by default.
3. This PR could have been rejected on the sole basis that it's a form of non-disclosed self-promotion, per our written policy, but we are lenient in general and would still accept it if the link is really useful, but again we question the usefulness here.

[WebReflection]

Really last:

Had it been something other than polyfills, such as links to libraries and frameworks that enable additional use cases, the decision may have come out differently.

it waas PONYFILL all along. It has no side-effects at all you are talking about, no security concerns about patching the world, nothing. It was a modern ECMAScript Module based alternative to the polyfill, because the polyfill you are proposing makes JSON slow by default so you are doing a disservice to the Web community by proposing a polyfill when dealing with BigInt primitive is an opt-in case in here, not the norm.

If it's not clear, you refused a ponyfill in the docs that would've made the thing an opt-in for projects interested into having BigInt serializable and unserializable, by rejecting my offer, you are making the entirety of the Web slower if such polyfill, instead of the alternative ponyfill, is adopted.

Again, congrats for how you are handling the Web these days.

[WebReflection]

As I pointed out, @ungap/raw-json cannot adequately claim 100% spec compliance because it is at least not robust to rewriting globals and native string checks (you did not override your polyfilled methods' toString)

this is not part of the specs .. there's no toString to override, present a case that fails and I'll fix it, that's how OSS works, in case you were not aware.

If that was the reason, state it so though, if "core-js or GTFO" is the reason, fire anyone that made that decision.

[WebReflection]

We don't want links to two projects that do the same thing because that creates paralysis of choice.

Again, you are missing the ponyfill word which is part of this (and the other) MR ... you are not listening what is the reason I am here, and the mistake you made ... there's an ocean of differences between polyfill and ponyfill out there, please update your knowledge around it.

[WebReflection]

a polyfill that needs 300 slow LOC to work and make everything slower on the Web

VS

a ponyfill that works in 90LOC all inclusive, whenever you want to disambiguate BigInt, no strings attached

This was the MR, and "core-js or nothing" was your answer.

Again, congrats!

[WebReflection]

P.S. @ungap is the least thing I've tried to create to make a pony/lifill place people can use and trust, before I wrote vice-versa and before that I wrote libraries that targeted really IE4, IE5, and all others to bring IE where FF was.

If you focus on @ungap popularity only in here, you are still disrespecting my entire career of polyfills.

The AMP team at Google sponsored my document.registerElement polyfill too, it's really not that I am new to provide solutions that work, and here all I read is anti-competitive, barely respectful, anwers.

This is sad, and the reason I'd say again goodbye. You won't see my contributions in here unless it's clear what the hell is going on behind the "promoting only one OSS project" curtains.

[WebReflection]

There about popularity: https://www.npmjs.com/package/@ungap/structured-clone

double down in here https://www.npmjs.com/package/flatted ... that's still me.

[Josh-Cena]

core-js also has a ponyfill mode. It's not a unique benefit offered by your library.

a polyfill that needs 300 slow LOC to work

core-js is 300LOC exactly because it needs to guard against all the compliance issues I mentioned above. If a demo is really needed:

1. Per https://tc39.es/ecma262/multipage/fundamental-objects.html#sec-function.prototype.tostring, all built-in functions must return function [name]() { [native code] } when stringified.

   import * as JSONUngap from "@ungap/raw-json";
   
   console.log(JSONUngap.rawJSON.toString());

2. You could claim that ponyfills are not native functions and do not need to behave exactly like so (though I would disagree if you want to maintain full interoperability with platform behavior). But your library is actually insecure. Need I demonstrate what happens if you do global.Map = () => "spooked" or RegExp.prototype.exec = () => "spooked"?

There about popularity: https://www.npmjs.com/package/@ungap/structured-clone

I mentioned "JS polyfill". Web API polyfills are a separate business and we already include this one.

https://www.npmjs.com/package/flatted

This is not imitating any platform API and is not relevant to the discussion. Again we will welcome libraries like this.

[WebReflection]

core-js is 300LOC exactly because it needs to guard against all the compliance issues I mentioned above. If a demo is really needed:

not quite, it's 250LOC on the parser the reason, toString() there has nothing to do with it, the fact console.log(JSONUngap.rawJSON.toString()) doesn't produce function [name]() { [native code] } is interesting to nobody needing bigint to be serializable and resurrected back so I am not sure what you are talking about, but I can add an extra single LOC to make you happy, if that's really what you need to accept this MR.

ponyfill are there to help migrate or use new landing specs, no irrelevant shenanigans attached.

[Josh-Cena]

If I have to restate our policy again, in case you still think it's a personal attack on this singular library:

1. First and foremost we reject non-disclosed self-promotions and it's a veto. We are willing to make exceptions but not in this case.
2. Your library is insecure and should not be advertised as a spec-compliant ponyfill.
3. We don't want links to multiple projects that do the same thing because it creates paralysis of choice. Our external links are not meant as a substitution for user research. We pick one solution proven to be popular and reliable enough, and if users are unsatisfied with that, the burden of finding alternatives is on them.

nobody needing bigint to be serializable and resurrected back so I am not sure what you are talking about, but I can add an extra single LOC to make you happy

I'm not sure what you are talking about either. I've never mentioned bigint in my responses and this proposal has nothing to do with bigint inherently.

[WebReflection]

Your library is insecure and should not be advertised as a spec-compliant ponyfill.

How is my library insecure? Are you allowed to spread FUD about contributions?

We don't want links to multiple projects that do the same thing

They don't: you linked a polyfill and I've added a smaller, faster, as secure as the other one, ponyfiill ... can we stop diverging this conversation into fully FUD mode, please?

[Josh-Cena]

How is my library insecure? Are you allowed to spread FUD about contributions?

See this:

2. Need I demonstrate what happens if you do global.Map = () => "spooked" or RegExp.prototype.exec = () => "spooked"?

And even if you don't rewrite globals.

console.log(JSONUngap.stringify({ a: 1, b: 2 }, {
  apply() {
    console.log('APPLY');
  },
  call() {
    console.log('CALL');
  }
}));

You cannot claim to reflect specs this way. It's probably not your fault but again this is why polyfills are hard.

[WebReflection]

this proposal has nothing to do with bigint inherently.

have you ever read the rawJSON proposal and intent? I start wondering if you are even aware about what this whole conversation is about ... rawJSON and isRawJSON were proposed to fix that BigInt can't be serialized and revived back, I wrote in my ponyfill an explainer I think you should read to do yourself a favor.

It'd be horrifying to discover I even wasted time to explain why my ponyfill alternative might help Web developers move forward around that proposal!

[WebReflection]

You cannot claim to reflect specs this way. It's probably not your fault but again this is why polyfills are hard.

Can you point me at a single polyfill you wrote to date? 'cause I have links to all others ... are you patronizing my understanding of how polyfills work?

This went from ugly to unbearable ... you should re-read, and re-think, almost everything you wrote in here.

One day, you'll get why I am still replying .. I do care about the Web, so should you.

[Josh-Cena]

BigInt is a motivation for the API. I wrote the documentation for it, including the section on "lossless number serialization", so of course I know the background. But I don't know why you are bringing it up when our whole discussion is around why we should include your ponyfill.

Can you point me at a single polyfill you wrote to date? 'cause I have links to all others ... are you patronizing my understanding of how polyfills work?

I don't need to write polyfills to point out that your polyfills aren't spec compliant, as I have already demonstrated. Again you are reducing my arguments to ad hominem attacks here.

[WebReflection]

Security on JS, here a reminder: https://javascript.plainenglish.io/about-trusting-javascript-execution-8c6b478d6021

your apply and call shenanigans is something I am aware since before 2011 and I wrote about it too: http://webreflection.blogspot.com/2011/10/bind-apply-and-call-trap.html

can we stop the "longer" competition and be back to explaining why my ponyfill is not welcome? 'cause if you want, I can write code that will mess up the entirety of core-js features, but I think that's not why we are here, right?

[WebReflection]

console.log(JSONUngap.stringify({ a: 1, b: 2 }, {
  apply() {
    console.log('APPLY');
  },
  call() {
    console.log('CALL');
  }
}));

what is this even about? is that how you write production code?

[Josh-Cena]

If you can demonstrate that core-js can be messed up, please do because that will be a bug to be reported to them.

You are aware that these pitfalls exist. For us to recommend something advertising as compliant, it has to produce the same output as the platform API when given the same input, which is not the case for your library.

My other reasons for the rejection have already been articulated in the list above.

[WebReflection]

no, honestly ... what is this about?

console.log(JSON.stringify({ a: 1, b: 2 }, {
  apply() {
    console.log('APPLY');
  },
  call() {
    console.log('CALL');
  }
}));

If your environment has poisoned call and apply it has nothing to do with my ponyfill so if you use the fact JS is insecure as argument, may I point you at the fact the whole crypto namespace, the one used to encrypt and/or decrypt can be poisoned too? Is this really about me using call and apply in my code?

It's a very weird argument when I've posted you already I know everything about it andI can mess up core-js any time as soon as my script runs before it, so what is really that you are trying to say in here? I want to understand, maybe you found an issue, but if that's about call and apply possibly poisoned, you found none because that's broken anyway on any website to date. Can you point me at a website that after global function prototype pollution would still work or are you just spreading FUD around my ponyfill for the sake of it?

[WebReflection]

If you can demonstrate that core-js can be messed up

it's deadly easy but it won't make any meaningful point in this discussion or about proposing core-js as polyfill: I have nothing against core-js as polyfill, in this particular case though, it does too much and it's too heavy and slow to deal with, hence my alternative. Can you understand that? It's for Web developers, not against them ,,, if they have clobbered global prototype in their project it's not me, neither you, nor core-js, helping them solving that issue which is my whole point about the absurdity of arguments you are presenting.

[Josh-Cena]

Secure websites either save all intrinsics upfront (there are packages for this, such as get-intrinsic) or freeze them (using SES). But userland being insecure is not an excuse for your library, which is a drop-in replacement for native solutions and thus held to high compliance requirements, to be insecure.

But even taking this whole side effect argument aside. I have demonstrated with code how your library will produce different output from what the spec mandates, in absence of any other side effects. This means it cannot be claimed as compliant.

[WebReflection]

Once again, if this was the reason for rejection I would've been way happier (it's 3LOC extra) to react to that reasoning, but I am fully sure right now even if I bring "secured" (it's a race condition in the real-world) call and apply to the ponyfill you'll find other awkward and antitrust conflicting arguments to nuke my link ... can you confirm? If yes is the answer, once again, me and you have very different meaning around working to push the Web forward (and it's sad you work for Mozilla, I don't), if no is the answer, I'll publish a fix ASAP and you should re-consider closing both PRs around this topic.

It's your call.

[Josh-Cena]

It will continue to be rejected because "your library has a bug" was only a minor point in my decision. The bigger ones are:

1. I quote yet again:

   If you have a business or personal relationship with the target of a link, you must disclose that relationship in your pull request. Failure to do so may imperil your continued participation with MDN Web Docs.

2. We'd rather not spread the practice of recommending multiple alternatives that do basically the same thing. core-js is a polyfill and a ponyfill so there's really no differentiation. We don't claim that our external links are comprehensive and represent the whole ecosystem, but they represent industry standards we've carefully vetted and endorsed. Yes it's anticompetitive to some degree, but there's a conflict between pro-competition and pro-stability/credibility and we go for the latter always.

Your initiative is admirable and I would encourage you to think more about security and resiliency to user code (not denying them as "no you would never write code like that"). I work for MDN (a collaborative project not solely governed by Mozilla), and my opinion reflects that of the maintainer body and our written policy. As much as we love diversity and competition in the OSS, we don't think MDN is the right place to demonstrate them. We will continue to welcome your contributions and links to other userland libraries, or even links to web API polyfills, but the decision to not include other polyfill/ponyfill of ECMA262 is final.

[WebReflection]

As much as we love diversity and competition in the OSS, we don't think MDN is the right place to demonstrate them.

I don’t think I need to add anything else.

Goodbye MDN 👋

[mindplay-dk]

Your initiative is admirable and I would encourage you to think more about security and resiliency to user code

@Josh-Cena does a ponyfill need to be secure against overrides? why? I mean, it doesn't affect anything globally. what's the risk?

I understand your argument about not wanting to list another alternative - since the currently listed package is also a ponyfill. I get your point about offering too many choices.

That said, presented with the option of a smaller and faster dedicated ponyfill, personally, I would always try that first.

Of course, I don't necessarily need to find it on MDN, and again, presented with choices, most developers might not have the easiest time understanding the choice they're making.

It might be better to educate them though? That's what MDN is for, so... idk. 🤔

[Josh-Cena]

You not overriding anything globally doesn't mean others are not overriding globally and affecting you. Being a ponyfill does not reduce your vulnerability to global pollution; it only means you don't pollute globals for others.

Put another way, in order for a ponyfill library to claim compliance, then for any JS program P, executing P natively must produce the same output as executing import * as JSON from "your-ponyfill"; P except for programs that make assumptions about how the JSON object itself is defined, such as Object.hasOwn(globalThis, "JSON") or Object.getOwnPropertyDescriptors(JSON). I think overriding Function.prototype.toString is also optional because these are not explicitly "built-in functions" per spec. But other than that, behavior-wise, programs that don't use any reflection API, including programs that mutate globals, must have the same observable behavior.

But again I don't want to argue too much about the correctness issues. Softwares have bugs and they can be fixed; that's not an error in principle. I only used that to illustrate that our wariness for polyfills is justified: because of the high standards polyfills are held to, it's very hard to make one that's robust and consistent. I could well have just quoted the policy without elaboration and closed this.

[aarjithn]

It’s obvious to have disagreements / conflicts of interest in OSS, just wanted to appreciate the detailed & thoughtful responses by @Josh-Cena

[WebReflection]

Softwares have bugs and they can be fixed

it's linked to this MR already, anything you found as issue has been fixed 2 days ago: ungap/raw-json#2

I could well have just quoted the policy without elaboration and closed this.

That's exactly what you did: #36294 (comment)

Moreover, you looked at my code (easy when it's just 90 LOC and not 300 with dozen external imports like in @core-js, isn't it? looks like a chance to also learn more about JS this way but what do I know), spot an API misusage potential gotcha and instead of filing an issue you went ahead full FUD about security.

I've been asked instead to:

• contribute to @core-js instead ... yeah, good luck with that + hooray for alternatives, like browsers alternatives, why are we even bothering with FF? Just fix Chromium and move on with promoted diversity but not really, right?
• talk about the fact JSON API is sloppy and doesn't throw on undesired parameters ... OK, I get you pass stuff by accident for no reason to stringify and parse API so I've fixed that too but please don't say @core-js is safer than others, a Function.prototype.call evil hack before core-js makes it as vulnerable as anything else ... if you want to spread security awareness it's not by blaming other people work that happens, we need to be a bit more serious about what are security concerns on the Web and I've provided links that talk deeper about that argument without shaming other libraries
• the current page is proposing a polyfill, not a ponyfill, the differnece is huge because one makes JSON slow by default for everyone due rawJSON required checks, the other one is an opt-in. In the name of "better for our users" you are cursing them if you provide huge polyfills without even explaining there are ponyfill alternatives
• compare @ungap/raw-json with core-js/proposals/json-parse-with-source, it's 1.6K VS 17K minified code. In my daily project we want to keep the size under 50K and even minified and compressed, we're talking 1.2K VS 7.3K for something we need only as transport protocol between Python and JS and where no foreign evil code is even ever allowed and we also know how to use JSON APIs without passing ad-hoc objects that are meaningless and have been created only to validate your security point that has been already fixed.

If there would've been a discussion about your concerns, instead of slamming the door on my face around 2 PRs which goal is not even to promote my libraries but to help users and developers experiment or try only when necessary this newly proposed API we would've both done a better service to the community you theoretically should care about because MDN is all about the Web development community ... or so I've believed for way too long.

Do you care about alternatives? No.
Do you allow discussions before slamming doors to explain and fix concerns and then eventually decide? No.
Do you participate to improve stuff you found buggy? No.

So thank you very much for all of that but you should, imho, rethink a bit what's your role as MDN contributor too.

[WebReflection]

I forgot performance argument ... not only in size but as result, you can test in here with Safari or Firefox, open your console and see results yourself: https://ungap.github.io/raw-json/test/

Firefox

WebKitGTK

But apparently nobody needs to learn there are smaller, simpler, faster, alternatives 🤷

[pransh15]

@WebReflection, please note that we have dozens of people watching this repository. For every comment posted, these people may receive a notification.

I’d like to acknowledge that some of the exchanges have become more personal while Josh was focused on the external links policy. I'm aware of your contributions and I would like to ensure that you know that we value our contributors and their expertise, but that does not mean we do not stick to the policies we have set up to ensure MDN remains safe and accurate as we scale with more information every day.

At MDN, we prioritize maintaining accurate and reliable information for our users. To achieve this, we limit the number of options we maintain, ideally to widely supported, de facto standards. While we aren't overly restrictive, items added to our resources need to have broad support and history to avoid becoming platforms for self-promotion. This policy helps us prevent situations where tools or libraries become outdated or irrelevant, a scenario we've encountered in the past.

Your PR has been closed as part of this approach. I can’t comment on your library specifically, but the concern is that many others might also want similar considerations, which leads to difficulties in maintaining the quality of resources. To get historical context, I would like to share that we have had plenty of conversations on polyfills over the years which should share more about what Josh mentioned:

1. https://github.com/orgs/mdn/discussions/475
2. https://github.com/orgs/mdn/discussions/568
3. https://github.com/orgs/mdn/discussions/604

Please be respectful of other people and their time and attention and avoid taking actions that might cause excessive notifications. Issues should describe a problem or propose an actionable solution. Please use the MDN Discussions if a discussion is needed.

Also, please remember that the Mozilla Community Participation Guidelines govern all participation in these open spaces. We enforce these to maintain a healthy and inviting community experience for everyone.

Thank you for understanding, and we hope to continue fostering a collaborative and respectful community. I have locked this issue.