I agree with alpha123, each point he said are exactly my opinion. So… what’s new ?

We could definitely use more contributions (pull requests) for 1.3.x and 1.2.x and 1.1x if bugs are found. At the moment, we try to trickle fixes to older versions, but it’s true it hasn’t been a disciplinary. I am aware, and I’ll bring it up so that we can be conscious about this when similar moments arise.

on the last question : basically since 1.2 came out, there had been a single update to 1.11 to 1.12 and it was to patch a breaking change deemed critical. is this the likely fate of 1.3 now?

Going from 1.3 to 2.0 will not be a picnic and that’s why we’ll continue to support 1.3. Besides, 2.x will not be that much different. I’ll post the comparison soon. It’s going through reviews right now.

Likewise, there’s a few of us in MooTools that would like to work with Joomla (and we’ve had before) and other applications to use upgrade scripts, compat layers, or simply to help them change the code. More on this later, but again I’ll reiterate that it’s not our intention to make your lives and work difficult.

I didn’t understand your last question.

So, is the 1.3 fork going to become redundant?

Of course, that may be a problem if an other lib is loaded before, extends a native and then mootools overwrites it, call uninstall and remove everything. But I guess this problem can be avoided by storing the function if it exists prior to mootools extension, and reset it when calling uninstall.

Uninstall seems preferable to install, though with a way to automatically install everything the difference wouldn’t be huge. I think cases where you have to play nice are less common than the cases where Moo is the only thing on the page, so it makes more sense to have them installed by default. Even if they aren’t installed by default an uninstall method seems like a necessary counterpart to an install method.

I plan to take part in the IRC Office Hour next week (I slept through it this time :P); I’ll look at the define-2 code in the meantime.

And yeah, that’s the reason. Although, Keeto has suggested that there might be a way to flip the burden on us rather than our users. He had mentioned an uninstall — similar to install — that would take out the native extensions if you want to be in a friendly environment. I’ll let him, however, write a more detailed explanation in code or an article.

We’re interested in your feedback and we’re glad that everyone has been passionate. We’re fortunate that our user base has strong developers that understand the importance towards style and ease. Hopefully, you’ll join us in the IRC Office Hour next week and/or start contributing with tickets, code comments (reviews, or your own pull requests in github.

What’s the reason behind not making native extensions the default?

If you notice, one of the most attractive things from the above is the power of choice. With 2.0 we’re giving you the developer even more choice to do with MooTools what you want. If you want MooTools to work anywhere, then you’re best to use generics (think plugins, or projects that have to play nice — ads, frameworks, tools, etc.). Otherwise, go nuts and install them so you can enjoy 1.3.x style.

Again more to come.

Yes those do give me some relief. Still, install()-ing everything I want to use doesn’t sound pleasant. Could there be some way to automatically install() everything? Like <script src="mootools.js" data-install="all"></script> or <script src="mootools.js" data-install="Array,Function"></script> or something like that.

I’m looking forward to reading the articles when they come around.

1.3x

new Element(‘div’).grab(new Element(‘p#theP’)).inject(document.id(‘myElem’))

2.0x

var Element = Node.Element; 
new Element('div').grab(new Element('p#theP')).inject(Node.select('myElem'));

2.0x with require (complete example)

require(['DOM/Node'], function(Node){

var Element = Node.Element; 
new Element('div').grab(new Element('p#theP')).inject(Node.select('myElem'));        

});

Pending Valerio or Arian correcting me, the above should illustrate how it’s not so much different than 1.3x.

First, please no panicking. As mentioned above and the previous post, we’re intentionally keeping this in the down low. It’s still very experimental, but it seems that we need to improve our communication on how awesome this is.

We’re working on two articles for the blog to help clarify this. First, I’m working on a side by side comparison between 1.3 code and 2.0 code. More to come.

Second, we’re working on an extensive article to explain the reasoning and how this is incredibly cool for 2.0.

At first I’ll clarify a few things, but please be patient and/or read the code: kamicane/mootools-core/tree/define-2. It’s the best way to understand.

1. You don’t have to do MooTools.Function.bind. If you so choose to you may do Function.bind(fn, context);. No namespacing.
2. You don’t have to do use generics (as above). As of right now we have an install method on the natives (e.g. Function). That when you call it: Function.install() you’ll be able to go back to 1.3.x use: (function(){}).bind(context);.
3. ES5 polyfills are there as generics. We’re considering adding a ES5.js, or similar, for those that want to add them to the natives by default (via install, for example).

I’m sure I missed something from your arguments/points. But, I hope the above gives you some relief. We’re not out to render your code useless or horrible. Remember, we’re MooTools. We make working on JavaScript fun™.