With Microsoft & Nokia on board with jQuery, I'd recommend finally introducing a NoConflict mode for Mootools, also. jQuery simply aliases "$" to "jQuery", so the two are interchangeable. Unfortunately, this isn't available for Mootools based on the fundamental principle of its design, which is to "extend" Javascript to do things it should have done natively. JQuery, YUI, and others simply "wrap" objects and create an interface to work with them. Mootools gains a lot of performance since there's no "middle-man" or translation when working with objects.
Also, to Mootools' & Prototype's disadvantage, there are several framework elements in the global namespace ($H, $A, $, $pick, $each, $type, etc.). There has been 1 person on this board that I know that successfully (?) namespaced Mootools. What I'm curious to see is if we took a middle of the road approach: can we continue to modify the native objects AND name space properly? Jan's rule of "Only 1 prototypal language + any number of namespaced ones" still applies, but at least Mootools can then have a NoConflict option, just in case Microsoft's code generation uses the $ function. In interest of full disclosure, I've been actively developing with Mootools since 0.83 ( or 0.86?) and use primarily Dojo, jQuery, followed by YUI in day-to-day activities. While sticking with 1 framework is ideal, IMO, as long as that "always included" framework is small enough in size (there was an article today on keeping Dojo @ 5.5k, then using smart lazy-loading), including other frameworks to achieve business objectives is just fine. -Eric (looking forward to our.mootools.net) P.S. It seems that Mocha UI suite is coming along quite nicely! On Oct 13, 10:55 am, nwhite <[EMAIL PROTECTED]> wrote: > In short yes. That is why I opened a ticket with Wordpress to push towards > compatibility mode with JQuery. I believe that this change will be adopted > in the near future, once it does, you should not have an issue using > Mootools. > > On Mon, Oct 13, 2008 at 11:47 AM, Chris J <[EMAIL PROTECTED]> wrote: > > > 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
