Yeah, I know it would be a huge task and would require constant maintenance. It really is a separate project. But I'm just trying to think of ways to increase code reuse between projects and libraries. Think of the benefits if more people used a common api! No need to port plugins from one library to another, no need to abandon your favorite library because the situation calls for another.
Like I said in my first post, I have been experimenting with it and I did get some simple code working in both jQuery and MooTools by modifying each library a little, but I think it's beyond my skills to do it right. I may just be dreaming, but I think it would be awesome if I could use the same code with different libraries. On Oct 15, 11:36 am, nwhite <[EMAIL PROTECTED]> wrote: > 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
