On Feb 17, 1:34 am, Peter Hewat <[email protected]> wrote: > ... Adding json.js separably or manually adding this > compatibility layer goes against Mootools philosophy (light is right, > elegant cross-browser, etc.)
To echo Peter: there are standards. Eventually we hope everyone will switch to the standards. If we write our code to the standards, not only is the learning curve reduced (both for us and for others reading our code years down the line), but when all browsers eventually follow the standards, the libraries can simply remove the patch code from the library and we'll all be using native methods. You think that MooTools will still have a JSON class when all browsers support JSON? I hope not. I'm not going to keep this argument going on forever, and I think it's clear what everyone's opinion is. But let me just say that I think I was naively over-enthusiastic about the MooTools "philosophy". My JavaScript Ajax library, which I started around 2005, has its own JSON class; it creates real native classes; and it patches events to meet the DOM standard. Except for one silly kludge I put in detecting "Safari" from a user agent string (to fix Safari 1.x), my code still works fine over five years later, except that now it automatically uses more native code. I was hoping to switch to a library that was community-maintained rather than me-maintained. But then I find out that MooTools prefers to have custom everything. It has to have custom names for JSON routines. I find out that the MooTools class system prevents you from using JavaScript instanceof. And I find out that MooTools creates an entirely separate event system rather than just patching the events if needed, which is what I was doing. I guess I was looking for something a little more lightweight, that would push the developer towards being standards-compliant (which in turn encourages browsers to be standards-compliant) instead of introducing yet another proprietary layer. A lot of talent has went into MooTools, but I think I'm leaning into bringing back my own code. Thanks, anyway. And again, the speed and friendliness of the responses here has been very nice.
