JQuery 1.4 and Malformed JSON(yehudakatz.com)
yehudakatz.com
JQuery 1.4 and Malformed JSON
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
5 comments
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
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).
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).
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.
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.
Test case: http://ejohn.org/files/json-parse/
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.
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
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.
Yeah saw some code yesterday it's a wonder a browser accepts
<LI><br>
<LI><br>
<LI><br>
It's stupid how a browser will parse just about anything.
It's stupid how a browser will parse just about anything.
Except that your example is valid HTML 4.01/5. Closing tags are optional.
Also, "Be conservative in what you emit, and liberal in what you accept" - Postel's Law: http://en.wikipedia.org/wiki/Robustness_principle
[edit]: I'm incorrect, some closing tags are optional, </li> being one of them. for HTML5: http://www.whatwg.org/specs/web-apps/current-work/#generate-...
Also, "Be conservative in what you emit, and liberal in what you accept" - Postel's Law: http://en.wikipedia.org/wiki/Robustness_principle
[edit]: I'm incorrect, some closing tags are optional, </li> being one of them. for HTML5: http://www.whatwg.org/specs/web-apps/current-work/#generate-...
[deleted]
mmm bad example then,
also according to the spec it's valid to have a <li> without a <ul> or related tag, didn't know that
It can also be wasteful to include unnecessary special cases. Eliminating them saves people's time at the machine's expense.
I completely disagree with this. JSON is a spec. Server-side code needs to support that spec. Adding extra eval() to support bad data formats hurts client performance and adds needless complexity. And extra quotes does not add a lot of data overhead. Especially compared to transmitting XML over the wire
he was mostly saying the specs (crockfords) decision was wrong, not jquerys to support it.
I dont really agree, naunces like reserved words causing bugs are major irritations and ill happily put up with a few extra bytes to never deal with them
I dont really agree, naunces like reserved words causing bugs are major irritations and ill happily put up with a few extra bytes to never deal with them
I don't like it. I should have a choice whether to use quotes or not, and let me suffer the consequences. I don't like API's forcing "best practices" on me. The quotes add crappy visual noise and extra bytes.
But it's not an API, it's a data format, very different things! Supporting both just means there's two ways to say the same thing and every single parsing library has to have that extra case and the spec is just that little bit longer. I'll take the extra couple of bytes thanks :)
>> "hurts client performance"
Please cite some numbers. JSON.parse is not faster than eval in my tests.
Please cite some numbers. JSON.parse is not faster than eval in my tests.
Came up at least once before, but no discussion there:
http://news.ycombinator.com/item?id=1054409
http://news.ycombinator.com/item?id=1054409
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.
[deleted]
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).
The malformed example given is:
{foo: "bar"}
{"foo": "bar"}
The object property is assigned with a name, not a (double-quoted) string. Well-formed JSON would look like this:
{"foo": "bar"}
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.