ghost
commented
11 years ago Yep—there is, indeed, a bug in the feature tests that causes JSON 3 to return false negatives when using the compressed version. It's been fixed in the v3.2.5 branch; I just need to finish testing and benchmarking before releasing. For what it's worth, IE does add non-standard extensions to the JSON grammar (for instance, it's more tolerant of whitespace patterns that would otherwise be syntax errors), so the tests will still fail.
I'm sure I can relax the stringent parse tests, though—syntactic extensions shouldn't be problematic; I'm much more interested in valid constructs that fail to parse correctly. Presumably, if you're writing JSON that's only parseable by Trident (WebKit implements similar lenient extensions), you know what you're doing. Otherwise, you shouldn't need to pay a performance penalty for the common case of valid JSON. Does that sound like a good approach to you?
(That said, you should be fine with JSON 2 if you don't want the overhead of the feature tests. There aren't any significant drawbacks to using the native implementation in IE >= 9; the more tolerant grammar only presents itself in a few edge cases).
mathiasbynens
bnjmnt4n
Hi,
I am using JSON3 and in Internet Explorer the Parse method fails the feature tests (as discussed in other posts here), I am just wondering if someone could explain what impact it could have if I use JSON2, which would use the native parsing in IE?
I assume that it could cause some issue at some point, I just don't know what it would be? Ideally I want to use the native IE parse method because the performance improvement is fairly significant, I just don't want to run into problems down the road.
Thanks,
Iain