Why do JSON, Date, and Math exist?
JS1 in 1995 needed some batteries included: Date, Math functions. I chose java.util.Date (implementation, this was the one piece I had help on from Ken Smith of Netscape, was a port from Java to C) and java.lang.Math.
JSON is more recent but again we want some batteries included, especially for the browser JS embedding. Downloading requires provisioning and hurts page load performance (pay for what you use but it's still a big-enough cost). JSON is based on Doug Crockford's json2.js which people were in fact downloading.
You could argue JSON didn't need to be in the core language. We did it, it's not worth revisiting. But the ES6 module system should help us avoid yet more such global namespace-object additions.
On Fri, Feb 17, 2012 at 3:39 PM, Brendan Eich <brendan at mozilla.org> wrote:
JS1 in 1995 needed some batteries included: Date, Math functions. I chose java.util.Date (implementation, this was the one piece I had help on from Ken Smith of Netscape, was a port from Java to C) and java.lang.Math.
JSON is more recent but again we want some batteries included, especially for the browser JS embedding. Downloading requires provisioning and hurts page load performance (pay for what you use but it's still a big-enough cost). JSON is based on Doug Crockford's json2.js which people were in fact downloading.
And json2.js was a complex set of RegExps guarding an eval. These RegExps were too complicated for anyone, including Crock, to have confidence that the result was secure. This was a security emergency waiting to happen.
On Feb 17, 2012, at 4:35 PM, Mark S. Miller wrote:
On Fri, Feb 17, 2012 at 3:39 PM, Brendan Eich <brendan at mozilla.org> wrote: JS1 in 1995 needed some batteries included: Date, Math functions. I chose java.util.Date (implementation, this was the one piece I had help on from Ken Smith of Netscape, was a port from Java to C) and java.lang.Math.
JSON is more recent but again we want some batteries included, especially for the browser JS embedding. Downloading requires provisioning and hurts page load performance (pay for what you use but it's still a big-enough cost). JSON is based on Doug Crockford's json2.js which people were in fact downloading.
And json2.js was a complex set of RegExps guarding an eval. These RegExps were too complicated for anyone, including Crock, to have confidence that the result was secure. This was a security emergency waiting to happen.
And my recollection is that the w3c had already declined to specify JSON encoding/decoding functions as part of html5.
On 17 February 2012 20:22, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
And my recollection is that the w3c had already declined to specify JSON encoding/decoding functions as part of html5.
I'm sure glad it worked out that way -- it's really handy having "native" JSON on the receiving end when doing server-side JavaScript. I can't think of the number of times I've bumped into serialization bugs in other languages, especially between languages, over the last 20 years. Having it right in the language eliminates all kinds of problems.
On Fri, Feb 17, 2012 at 8:22 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
And my recollection is that the w3c had already declined to specify JSON encoding/decoding functions as part of html5.
I don't believe that this was ever brought before the HTML WG, and I don't see any recorded decision on the matter. That being said, I personally believe that ECMA TC39 is a fine place to have standardized this function.
- Sam Ruby
They seem rather out-of-place in a language that includes no standard library. I would include RegExp in that list but there is literal syntax for that in the language.
Are the reasons purely historical/for convenience of standardization in JavaScript? They seem like something the host environment should provide, not a native object.