Modularize MooTools

[IvanGuardado]

Hi everybody!

I work in a project that uses MooTools as library to manipulate DOM and I'm trying to organise the whole code using webpack to manage de code dependencies. I found some issues that I fixed in #2722, however I talked with @SergioCrisostomo about how to improve the MooTools modularization and I leave you here my thoughts:

Why is important to make MooTools more modular?
I don't want to open a discussion about the module benefits, but I think is important to clarify it to developers who never used it:

1. Helps you to track your code dependencies and makes your code more robust and easier to refactor.
2. For the client side code, it adds the capacity to load modules on demand asynchronously.

What's the problem with MooTools?
The nature of the MooTools is to extend the native types to add polyfills and useful methods. This isn't a good pattern to work with modules because of once you load a module like Element, you have extended the native Element prototype so you can use it in any other module without requiring it.

file1.js

var Element = require('mootools-core/Element');
var foo = require('file2');

file2.js

var element = new Element('div');
// You can use the MooTools method here because 
// the prototype has been extended previously.
element.inject(document.body);

For me, as developer, this doesn't give me any benefit on tracking my module dependencies... In fact I think that is very messy and could reach to errors.

Proposal

• To package all native prototype extensions and polyfill into a base module, which would be required once in your application (in the application entry point).
• The other modules that publish global variables (Class, Browser, Fx, Request, etc...) could be loaded following the commonjs pattern without problems...

main.js

//This would load all the native extensions, now I can be sure to use them on any part of my application. 
//This is not a good module pattern but it's the MooTools nature...
require('mootools-core'); //mootools-core/index.js 
require('file1');

file1.js

var Request = require('mootools-core/Request');
var foo = require('file2');
//do somthing with Request...

file2.js

//This will break due to not to load the module first
Request.JSON(...);

This is basically what I talked with Sergio so I hope this feedback to be useful and can open a debate about the steps to follow to improve the library.

Regards

---

Additional resources that could be interesting:
https://github.com/umdjs/umd/
https://github.com/bebraw/grunt-umd

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[timwienk]

Firstly, thanks for wanting to participate and trying to improve MooTools.

However, you make it sound as if you think these things have never been discussed, considered or tried within MooTools or for MooTools Core specifically. The fact is, though, that MooTools Core has been a modular framework since before there was any (de-facto or otherwise) standard for modularisation in JavaScript. And later on, work was just never completed to actually support a standard that had arised since then. (See #2102).

After that, you establish that extending natives is "not a good pattern", while you call it "the nature of MooTools", that is quite a conflict. It is indeed the nature of MooTools Core 1.x, and because it is its nature, it would be very awkward to change. It's fully understandable (and, I guess true) that the approach is not suitable for your projects designed according to currently accepted/popular principles, but that just means that MooTools Core 1.x is not suitable for these projects, which isn't weird for a project library developed in 2006. MooTools Core 1.x is a library of which the structure and design were developed in a time when the Javascript and browser landscapes were entirely different.

As has been said before, for a possible MooTools Core 2.x, this design would obviously be reconsidered (likely it would be an optional feature, for those who control their environment and would like these things globally present), and obviously one of the current standards for modularisation would be used. On top of that, a very big part of MooTools Core 1.x is no longer relevant (and hasn't been for a while), because of how JavaScript itself and the engines/browsers have developed.

All-in-all, in my opinion, if there is to be a MooTools Core 2.x, for it to be credible and reliable (or even relevant), it would have to be a complete revisit/rewrite. For MooTools Core 1.x, only the commonjs-style modularisation part could be relevant, but changing how natives are handled should not be part of that.

[SergioCrisostomo]

@IvanGuardado I am really happy you took the time to share your ideas. Nice that @timwienk pointed to a important related thread so ideas from the past can be used and be a source of inspiration.

[IvanGuardado]

It was only my thought about improving the current way to use modules in the library. It makes sense for me to separate the modules that extend native prototypes from which don't do it.

I've never talked about changing the MooTools nature at all but about the way of loading the library. I know the problems of changing the libraries API, but I think (IMHO) there is chance to do it better :)