4 ms·

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

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 17y ago
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 17y ago
  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 17y ago
    Test case: http://ejohn.org/files/json-parse/ 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.
robryan 17y ago
Yeah saw some code yesterday it's a wonder a browser accepts <LI> <LI> <LI> It's stupid how a browser will parse just about anything.
- bodhi 17y ago
 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 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-implied-end-tags http://www.whatwg.org/specs/web-apps/current-work/#generate-...
 - deleted 17y ago
 [deleted]
 - robryan 17y ago
 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

jeresig 17y ago

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 17y ago
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 17y ago
  Test case: http://ejohn.org/files/json-parse/ 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.

robryan 17y ago

Yeah saw some code yesterday it's a wonder a browser accepts <LI> <LI> <LI> It's stupid how a browser will parse just about anything.

bodhi 17y ago
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 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-implied-end-tags http://www.whatwg.org/specs/web-apps/current-work/#generate-...
- deleted 17y ago
 [deleted]
- robryan 17y ago
 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