There are a ton of hurdles with that approach. 1. Familiarity with the framework your building the compatibility layer for. 2. More brittle. Your code breaks with Mootool changes and with the other Framework changes. 3. Mootools still wouldn't be completely protected. The possibility of the prototype being destroyed or altered still exists.
I for one would be interested in such a solution, if nothing more then for academic reasons. The amount of time to get a decent layer built and then supporting the changes in both frameworks would be monumental. It is almost the equivalent of creating a new framework. This should not be a focus or a consideration for the Mootools developers as its way beyond the scope. It creates way too much work. This project would also have the side effect of creating a bunch of additional support, I can just hear all the questions. Nathan On Wed, Oct 15, 2008 at 10:03 AM, Chris J <[EMAIL PROTECTED]> wrote: > > I know this would be a lot work, but what if we wrote wrappers for > other libraries (non-prototype base) that made MooTools syntax valid, > using that library's core code. That would enable MooTools code and > plugins to be extremely portable, almost as much as regular > JavaScript. Has anyone tried something like this yet? > > On Oct 14, 10:30 pm, Eric <[EMAIL PROTECTED]> wrote: > > 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 >
