Garret, it's clear you're a little turned off by the coding philosophy of MooTools. The JSON implementation isn't really that big of an issue, but the broader philosophy of what MooTools does is in line with it. We don't implement addEventListener for browsers that don't have it, choosing instead a third, "proprietary" method called addEvent. As Christoph points out, there are a lot of parts of JavaScript that are just plain aweful. Go look at the Date object; it's not just awful, it's god-awful. MooTools implements it's own Date object giving you the ability to parse strings and format dates into strings, compare dates easily and mutate their state (add a month, subtract a year) etc. This is present throughout the language. By abstracting away from ill defined standards we make a better development environment. In places where the emerging standard has it right, we implement for browsers that don't have them (all the Array methods, for instance), but we don't shy away from following our own style when attempting to improve the language. MooTools' goal is not to get you writing standards-based JavaScript. It is to make JavaScript more pleasant and easy to write, read, maintain, and use.
Thanks for your thoughtful input here though. Best of luck to you. On Thu, Feb 17, 2011 at 6:43 AM, Garret Wilson <[email protected]>wrote: > 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. >
