> I'm just trying to think of ways to increase code reuse between projects > and libraries.
Does this really promote code reuse? I see this as a disadvantage rather then an advantage. JQuery is already having trouble with the redundancy and dependency on plugins. Its kinda like what happened to perl with CPAN. It just becomes a jungle of code making it harder to determine what is the right solution. > Think of the benefits if more people used a common api! This sounds like a different direction altogether. I believe we have been talking about a compatability layer on one framework for another. This does not mean a common api, you would still have 2 apis. > No need to port plugins from one library to another, no need to abandon > your favorite library because the situation calls for another. Again, you would still require 2 different apis. While it is possible it would ellimate work upfront. I believe it would create much larger headaches down the road. I can only imagine all the hidden bugs and gotchas because of syntax differences/similarities. This is assuming 100% compatibility, without that the problem becomes far worse. I may just be dreaming, but I think it would be awesome if I could use > the same code with different libraries. > The problem is, this compatability layer would mean the same code would be in the non native framework. I'm not trying to steal your thunder, honestly. I have rolled this idea around many times, I know others have as well. The inherient barrier is so large without a huge amount of benefit. I have spent a number of hours porting code from other frameworks into mootools. For the most part it isn't that hard. The class base structure mootools offers usually results in my code being smaller with more options. I think a wonderful example of this is lightbox. Look at all the different ports to the different frameworks. Mootool's slimbox uses quite a bit less code. I place where I see this project having a large benefit is for users using another framework that want to switch to mootools. It would be the equivelent of training wheels. This creates a couple of problems as well. The political aspect that we could be viewed as stealing users from other frameworks. The other is we would be attracting users that have a weaker set of javascript skills. In itself not bad, but it results in more questions and time. Mootools has a strong focus to be targeted for professional developers, this would dilute the focus. If anything, this conversation inspires me to shift focus a bit. We should create a "Most Wanted" list of plugins/features/scripts that other frameworks have that mootools currently does not. This way as a community we can work together to knock these out one by one and add them into our code base. This way when we are faced with the choice of replacing code from another framework we will have more tools in our arsenal to push towards a mootools implementation. > > 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 >
