
JQuery 1.4 and Malformed JSON - ivey
http://yehudakatz.com/2010/01/15/jquery-1-4-and-malformed-json/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+KatzGotYourTongue+%28Katz+Got+Your+Tongue%3F%29
======
axod
>> "Again, though, you should probably be modifying your busted server-side
code to stop sending malformed JSON!"

I still think it was a silly mistake to impose a 'must be enclosed in quotes'
rule for JSON parsing in js.

Those quotes are just wasted extra bytes. Needless.

Yeah sure, you can argue that someone silly will use a reserved word, like
{new:"hello"}. But I don't think that's a good enough reason to waste more
bandwidth+time for those that know what they're doing.

~~~
daleharvey
either way I still think its great that libraries are taking the risk to not
support malformed dataformats, if browser developers had of made the same
decision I think the web would have been far ahead of where it is now

~~~
jeresig
In some way the browsers already have made the decision. The new JSON.parse
method available in Firefox, Safari, and IE 8 is capable of parsing a valid
JSON string and turning it into a JavaScript object. The exception is the one
provided by Chrome, as it accepts malformed JSON strings (such as {foo:1} and
{'foo':1}).

In jQuery we wanted to take advantage of this new JSON.parse method for speed
and security - but we couldn't have it throwing malformed JSON exceptions in
some browsers but not others, so we simply equalized the field (throwing an
exception in all browsers).

~~~
axod
For some reason, the performance doesn't seem that clear cut.

For instance, I get the following on Chrome, running it a few times: (Doing
100,000 parses of a small JSON string)

JSON: (1653ms) vs eval: (206ms)

Firefox the two are about even (650ms). Safari is also pretty much identical
(250ms).

Surprising that the Chrome JSON parse is so much slower than eval.

Do you have any performance figures for JSON parsing?

So you have JSON.parse which is the same, if not slower (Chrome) than using
eval. Having to include extra unnecessary characters costs you bandwidth, but
you do get the slightly better security from JSON, although that can be done
with a quick regexp beforehand.

{foo:1} _should_ be valid dammit. It tells us exactly all we need to know,
with 0 ambiguity.

just my 2c.

~~~
jeresig
Test case: <http://ejohn.org/files/json-parse/>

    
    
      Firefox 3.5: eval: 549 JSON.parse: 490
      Safari 4: eval: 246 JSON.parse: 215
      IE 8: eval: 1438 JSON.parse: 1031
      Chrome: eval: 241 JSON.parse: 656
    

So yeah, a bit faster in Firefox and Safari, much much faster in IE 8 (the one
that matters), and oddly slower in Chrome. I'll go out on a limb and blame
their lax parsing (they support malformed strings).

In the end though the parsing is a distant second to the improved security:
Guaranteeing that eval will never get touched in modern browsers is a huge win
from a framework perspective.

------
Semiapies
Came up at least once before, but no discussion there:

<http://news.ycombinator.com/item?id=1054409>

~~~
ivey
Ah, my URL had the utm_* params in it. I was surprised it wasn't already
posted. Oh well, at least more people are seeing/discussing.

~~~
Semiapies
It's all good. I almost didn't post the link, but I thought it'd salt the
discussion to have another comment in there.

------
rads
I had a problem with this today when upgrading from jQuery 1.3.2 to 1.4. The
AJAX functions worked fine in Firefox, were returning "parseerror" in Safari
because there was a non-UTF-8 character in the JSON response.

------
cellis
Could someone tell me why the example given is malformed? I rarely write JSON
anymore (except with json_encode in php and simplejson in python).

~~~
almost
The malformed example given is:

    
    
        {foo: "bar"}
    

which is missing the quotes around foo so it should be:

    
    
        {"foo": "bar"}
    

Since both of those would have had the same meaning the JSON spec sensibly
restricts things so that only one is valid. See <http://json.org/> for the
(very short and readable) spec.

~~~
bobbyi
The reason for outlawing the first syntax is that it isn't a legal javascript
literal in the case where the key is a javascript reserved word (if we change
'foo' to 'for' in this example).

