I think I am going to start putting some community hours to promote mootools and make a great Mootools Plugin Repository.

I saw this asked, but I didn’t see the answer. Do you have any thoughts about hosting -more on google’s AJAX Libraries API? I know that means no “building” and people would wind up including more than they need. But I think the benefits are still worth it.

With regard to the nomenclature, for me this is extremely important as an API where you don’t have to read any docs is an API that I want to use. For example a plugin called FixPNG rather than Browser.FixPng troubles me :)

Re: -more; Perhaps there a plugin coding/nomenclature convention (in addition to that code style) should be considered before anything is added? Also it’d be great to have a drive for a community to manage the QA and cataloging of libraries…or would that be down to Clientcide?

Requiring the download of a second file to obtain “more” functionality is confusing, unintuitive, and tedious. Some developers will object to loading separate JS files for “core” and “more” from their HTML. Of course, they can merge the files into one, but that’s more work on their end.

To make the situation worse, the process for obtaining “more” functionality requires using the More Builder, which is cumbersome in itself. The More Builder does not have an easy “select all components” option and thus is much more tedious than it should be. (This applies to the Core Builder as well; building a “core” without one component should be “select all, then uncheck what’s not needed,” not “check each component except…”)

As a result, it is not easy for developers to jump in and play with everything that Mootools offers, and I believe that is impeding widespread adoption of the framework, compared to other frameworks that offer their power in a single ready-made package.

I think it’s a great idea for Mootools to offer customizable downloads; I just think it could be done much better. For one thing, I don’t see the point in having two separate files and two separate builders. It would be better to have a single builder including both “core” and “more” components, more like the 1.1, which some UI magic to make selecting groups easier, such as “Select All Core” and “Select All More” buttons.

Actually, it would be even better to follow the UI set by OS X custom installation boxes: a hierarchical set of checkboxes, where the user can click a triangle to drill down and select individual components, or just check the Core or More boxes to select all the respective contained components.

Either UI approach proposed above would enable the user to quickly select the big groups in a couple clicks and then add or remove individual components as desired. This builder would yield a single JS file, compressed as chosen by the user. It’s simpler, smarter, and less tedious than the current download tools, which is I think what Mootools aims to be. And it also encourages newcomers to try the “more” components and perhaps someday contribute their own.

I’d be happy to code this new builder, as I think it was make Mootools a lot easier to acquire and help grow the community.

@doomedlung, Hash moving to -more isn’t a bad thing. You can still download it and use it of course, it just won’t be in the core distribution. You’ll probably find a lot of new things in -more soon that you’ll want anyway.

@Scott, DOM manipulation is very fast, as fast a jQuery (see the blog post here on Sizzle). The comment about removing this.* references doesn’t make sense, as this is a huge aspect of writing OO based JavaScript. Having a lot of this references is a good sign of good JavaScript.

@Garrick, if you want to contribute to -more you just need to write good code and reach out to us. There are a lot of ways you can contribute from testing, writing demos or docs, writing code, or giving feedback. If this sounds interesting to you, drop into IRC or post to the mootools google group with the ways you’d like to get involved and we’ll get you started. You can also ping me (Aaron) personally.

@J3D, MooTools already supports Drag-n-Drop. Event delegation will be available in MooTools 1.3, but you can get a beta version on Clientcide.

The continued seperation of core and more is also a great idea and I think it will work out. I wish MT the best of luck and hope to be able to contribute to more!

One particular feature I’d love to see in the future is namespacing Moo. And something like jQuerys noConflict alongside. I’d never put my hands on jQuery (I swear!), but this one is really tempting and makes integration with other frameworks/scripts convenient.

However, keep up the good work!