Depending on your needs (i.e. how you would otherwise use your output jspn), using the reviver can have a significant impact on performance. JSON.parse itself is hyper-optimized. At the company I work we used the reviver for almost exactly this, but profiling showed that using the reviver had enormous impact on performance. We cut it out, and won in the seconds of performance for some large json's.

Instead of using the reviver you can deserialize as a plain string, then later reassign the property as the type you want. E.g.:

  const myObject = JSON.parse(text);
  myObject.date = new Date(myObject.date);

I've been doing this for so long and never knew there was a reviver param, thanks - that is super useful.

Having to provide a complete schema of your json everywhere your json gets parsed negates the advantages of json.

The main advantage of json is that it’s human readable and writable. Beyond that, it has no notion of user created data types so anyone using it has to do custom unmarshalling to get a type apart from sting, number, dict and list.

Even if you don't explicitly provide a schema, you implicitly still have one. The recipient needs to know what you're sending them. Unless maybe you want to start parsing JSON payloads with an LLM.

Most JSON libraries in typed languages require this for data binding to complex types though.

Which is why many developers only use JavaScript Object Notation for JavaScript objects, and only JavaScript objects that can losslessly be written as JSON. Which this proposal explicitly does not support.

{"$temporal_type":"PlainYearMonth","$data":"........"}