use JSON.stringify() natively or with json2.js

#7599 is a duplicate of this ticket.

Stupid question: why? Adding a jQuery alias to JSON.stringify would take 2 minutes and 3 lines of code, and it would save tons of developers who are ignorant of JSON.stringify a bunch of time. Plus, you already have a JSON parser (despite the existence of the built-in eval), so it seems like a no-brainer to have a companion method.

1. Not all browsers have a native JSON object. The size of a non-native implementation is not trivial.

2. There is no point to just alias a normal browser function. This is like saying we should have a jQuery.math alias to the Math object because some people don’t want to use it directly.

The Math object is part of the JS language; if you get the O'Reilly pocket reference, or look at W3Schools, or check any other JS reference, it will include Math. This is not true for the JSON object; it's more like (for instance) the map function because, as you pointed out, JSON doesn't exist for all browsers (but jQuery DOES include a map implementation). And isn't the whole idea (or at least one of the core ideas) of jQuery to eliminate cross-browser issues? The map function is certainly not the only feature jQuery implements to make up for a lack of browser implementation (mouseenter, mouseleave, and the onready events are some other examples, and I'm sure there are more).

The goal of jQuery is not to "eliminate cross-browser issues" by providing a safe alias for every single thing someone could ever possibly want to do.

jQuery regular parses JSON as part of dealing with AJAX responses, as well as parsing JSON-encoded data from data attributes. jQuery *never* needs to stringify objects internally

"Adding a jQuery alias to JSON.stringify would take 2 minutes and 3 lines of code"

Except for the part where you have to write an entire JSON serializer for places where native JSON doesn't exist.

"and it would save tons of developers who are ignorant of JSON.stringify a bunch of time."

If someone comes into the jQuery support channel and does not know how to serialize to JSON, we direct them to JSON.stringify. A lot of jQuery developers are ignorant of a lot of parts of JavaScript, it is not jQuery's purpose to provide them with a magic, comfy jQuery wrapper in order to familiarise them with those aspects.

Many people start off with jQuery wondering, for instance, what the "jQuery equivalent" of parseInt is. There isn't one. You just use the browser's native parseInt method. The best practise in JS circles for sometime has been to use native JSON, and include Douglas Crockford's json2.js, which provides a fallback in the event there is no JSON object (which is only ie7 and below). I do believe this should continue to be the case.

Ok, but map *IS* a core part of JS (as of v1.6; https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Array/map). It's even more core than the JSON module, in the sense that it's part of the JS spec (vs. JSON, which you won't find here https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects).

So, you've got a map function, which exists built-in in some browsers and not in others. Because it's a useful thing to have, jQuery provides an implementation of it (presumably that implementation is just an alias to the real map function on browsers with map support? I haven't actually checked the source). Same thing for those events I mentioned (mouseenter/mouseleave/ondomready).

Then you've got JSON.stringify, which ... exists built-in in some browsers and not in others, and is a useful thing to have, but ... jQuery doesn't provide an implementation of it. What I'm not understanding is, what criteria are you using to decide that useful things A/B/C/D which only some browsers implement DOES go in to jQuery, but useful thing E that only some browsers implement doesn't? Is there (for instance) a 50 line cut-off for features implemented in some browsers, and the mouseenter implementation only take 50 lines, but JSON.stringify takes 51?

"(presumably that implementation is just an alias to the real map function on browsers with map support? I haven't actually checked the source)."

There's an old adage about assuming that applies just as well to presuming in this case. jQuery.map *does not* fall back to Array.prototype.map (indeed, many people's complaint about it is that it is not consistent with the Array.prototype.map spec), but is a custom implementation.

Again, jQuery uses .map internally in a number of places (both the $.fn.map (which falls back to $.map) and $.map itself) , which it never does for JSON.stringify. jQuery constantly is working with arrays of elements and using those arrays to generate other arrays.

FURTHERMORE, people *constantly* complain about the fact that jQuery's size is growing over time, AND that jQuery has code in it only for IE. Providing a JSON.stringify fallback would ONLY be used for IE, and would add considerable bloat (3.5% of the entire library size).

FURTHER-ERMORE, jQuery is a DOM/events/AJAX library. Standardising events across browsers is pretty much its bread and butter. "jQuery does a document ready handler , therefore it should provide a JSON stringifier" is a rationale that does not hold much water.

(FYI: There is no hard-and-fast rule in terms of LOC count per feature.)