> MooTools class system > prevents you from using JavaScript instanceof.
Says who? http://jsfiddle.net/rpflorence/MkqQQ/ On Feb 17, 2011, at 7:43 AM, Garret Wilson 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.
