JSON 3: A modern JSON polyfill compatible with nearly all JavaScript platforms. | Hacker News Reader

JSON 3: A modern JSON polyfill compatible with nearly all JavaScript platforms.

bestiejs.github.com

41 pointskitcambridge28 comments

If anyone else was confused, a "polyfill" is a pure javascript implementation of behavior the platform doesn't natively provide, and calling it "JSON 3" is not trying to claim that the JSON grammar has been revised (that's pretty much impossible); it's just the unfortunately generic name they chose for this implementation.

I understood the JSON3 name right away. Douglas Crockford's best-known implementation is called JSON2; this aims to be a successor to it.

I agree that it shouldn't be called a polyfill.

@prodigal_erik @benatkin

It is a JS polyfill/shim/fallback for older browsers like IE 6 and 7 but also fixes/fills in gaps in support/consistency with modern browsers that have buggy implementations.

The use of the word "modern" in the description is to suggest it is more up-to-date than Crockford's aging/stale json2.js.

Speaking of new JSON versions, is it impossible to create a backwards-compatible JSON spec that supports comments? I've been waiting for this for ages.

Please, yes. Two use cases where I constantly bemoan the lack of comment support in JSON are configuration files and test fixtures.

I, too, would love to see comments officially supported in the next iteration of the JSON standard...IIRC, Crockford removed them to make JSON a valid YAML subset.

For what it's worth, I've created a fork of Kyle Simpson's `JSON.minify` project that uses a variation of the character-based parsing process in JSON 3: https://github.com/kitcambridge/JSON.minify/blob/master/mini... It's somewhat cumbersome to use, though, as it needs to be called on a string before feeding it to `parse` (e.g., `JSON.parse(JSON.minify("/* Hello */ 123"))`).

Optional quotes and optional EOL commas would be nice too

While more human friendly, that would inhibit serialization.

Comments were removed for several reasons; one being that it adds the ability to add non-JSON data to the stream. In order to keep the spec simple and more interoperable, comments are gone. Don't expect them to return.

On issue 28, it says that when you do

   JSON.stringify(Object('hi'))

The issue reporter says it should return '"hi"' but returns '{"0":"h","1":"i"}'

In my JS console, if I do

   Object('hi')

It returns { '0': 'h', '1': 'i' }

So to me, it looks like JSON2 correctly serializes the result of Object('hi'). Am I missing something?

https://github.com/douglascrockford/JSON-js/issues/28

Make sure you're not on a page with external scripts that could be mucking it up.

If you're recent modern browser `JSON.stringify(Object('hi'))` should produce '"hi"'.

See http://cl.ly/2J3B0e1z1o3e0T3x2b0l.

Right,

   JSON.stringify(Object('hi'))

does that, but just plain Object('hi') without wrapping in stringify returns

   { '0': 'h', '1': 'i' }

Is it part of the JSON spec that you first call .toString() on array-like objects?

`Object('hi')` produces the equivalent of `new String('hi')`.

The stringify behavior is spec'ed here http://es5.github.com/#x15.12.3 [Step 4b of the abstract operation Str(key, holder) algorithm].

See http://cl.ly/2E1l2X3X3U1B2N1d3G1k.

Ahh that makes sense. I appreciate your research finding that part in the spec.

Thanks for the heads up. I’ve always thought JSON2’s approach of adding all kinds of stuff to built-in objects was a dumb idea for such an important piece of infrastructure code. I’ve been tempted on occasion to write my own JSON codec. I’m glad they tested to make sure it works on every browser of the last 6-7 years: it means JSON3 can pretty much be dropped in and forgotten about for any project.

Unrelated: their readme reveals a bug in github’s markdown implementation. The bold is not properly applied in the following example:

  - **`String.prototype` Methods**: `indexOf`, `charAt`, `slice`.

Fixed. Thanks for the heads-up!

Your git clone link seems to be outdated, it should be https://github.com/bestiejs/json3.git .

Fixed. Thank you!

I'd be slightly worried that overriding the native functions could lead to problems in certain situations that rely on the (wrong) existing behavior.

I don't think it's intended as a replacement for the native functions, rather an implementation to use where they're missing (which, AFAIK, is rare nowadays).

If you read the description on the page, it says that they fix certain broken aspects of some native implementations.

@spicyj I agree that recklessly paving natives is no good and can cause problems, but JSON3 is trying rather hard to not pave them (note that it doesn't even extend Date.prototype), and only paves parse/stringify when fixing broken implementations that are not cross-browser consistent or spec-compliant. With the fix in place it means the API will produce consistent output cross-browser which is a good thing.

That's correct. Currently, Firefox is the only browser that implements the JSON routines exactly as described in the spec (parsing since version 5.0, and serializing since 6.0)...others deviate in one or more ways. It's not so much of a concern if you're targeting multiple browsers, as Firefox will correctly throw a `SyntaxError` when given malformed input, but it can certainly become problematic if you're relying on non-standard extensions in only one or two browsers.

This is bike-shed, but `stringify`? What's wrong with `serialize` or `toJSON` or `toString'?

This is mainly for consistency with the previous JSON libraries developed by Douglas Crockford. In JavaScript, it's easy enough to "create your own API" by just aliasing JSON.stringify to JSON.serialize or even a local "serialize" function that it isn't too much of an issue.

As much as I agree that the naming convention isn't great, it's better to have consistency -- especially in a language as dynamic as JavaScript.

@polemic @shantanubala `stringify` and `parse` are the names specified by the ECMAScript language spec: http://es5.github.com/#x15.12.3

Ah, ok. Thanks!

unicode support?

damn you u+2028

Reply on news.ycombinator.com