Including multiple libraries still isn't a sure bet that they'll work together, even if they are prototype based and namespace based. For example, there's a conflict with jQuery and an older Scriptaculous. And wasn't there a conflict between MooTools and jQuery sometime back?
I agree that one single library should be used, and I believe Wordpress uses jQuery, but that doesn't stop plugin authors from including their own libraries. And consider the situation in which I'm creating a widget that people will include on their web pages. If I use MooTools to build it, that prevents everyone already using Prototype from using it and may cause unexpected conflicts down the road with other libraries. MooTools is fine if I'm building something I have full control over, but is it the best choice when building something I don't? On Oct 13, 10:00 am, Jan Kassens <[EMAIL PROTECTED]> wrote: > well, there are prototype based (in the sense that the native > prototypes are altered, prototypejs and mootools as two examples) and > non prototype based (for example: YUI, jQuery). > > The prototype approach yields to an easier to read api: [1, 2, 3].each > vs. $([1, 2, 3]).each, but also makes the library incompatible with > another library which also alters the native prototypes > (Array.prototype.each in the above example. > > In short: you can normally include multiple non prototype based > library, but only one prototype based. MooTools + jQuery + YUI for > example would work, but MooTools + Prototype.js wont. > > IMO, one page should pick one single framework anyway and dont > duplicate the file-size overhead, thats why i think the prototype way > is the cleaner/better one for most purposes. > > Jan > > On Oct 13, 2008, at 15:27, Chris J wrote: > > > > > > > I understand the argument for not trying to make MooTools compatible > > with other libraries and I agree with it. > > > My concern is when we as developers don't have any control over what > > other scripts are included, like writing a plugin for Wordpress for > > example. In situations like those, do I have to ditch MooTools for a > > more third-party-friendly library? It's not reasonable to push the > > compatibility problem onto the end-user. > > > What do you do? > > > I'm experimenting with adapters (similar to ExtJS) for other libraries > > to maintain a consistent api across all of them. That way, if another > > library is already included, I just include the adapter. I'm basing > > the api heavily on MooTools since it's so awesome. > > -- > my blog:http://blog.kassens.net
