One of the great things about Mootools is that you can extend the core functionality at your will. Quite literally, you have the force. But one thing I’ve seen recently, and more often than you would think, is that people come up with a simple single method extension of something that should be added to the core but then it’s rejected.
One such example is this neat code that togglesEvent(s). Does Mootools have toggleClass? Why not add them in? It’s fair, right?
I think it’s fair (not to add it). The toggle events methods presented above is an example where the user has a need to speed-up a repetitive task or an idea to help others but instead of bloating the core library, you could easily make a simple Addon-library for Mootools. There is a library like that already. It’s a library for a library. It’s Moo.rd! It adds tons of things to Mootools functionality. I don’t know what kind of coverage Moo.rd has across the web of Mootoolers but I certainly think that if you had added Moo.rd with Mootools as either Core/More, Mootools would’ve exploded.
I’m not promoting or talking about showing off neat ideas I’ve seen in the invalid lighthouse tickets though. I’m talking about Mootools in general. If the developers were to add all of the syntax, shortcuts, new ideas, wasteful optimizations and other obscure things, it wouldn’t be the Mootools way. It would be My Objectified Usable Tools. (Bad joke?) I’ve always wanted a quick method for attaching domready to window. Why didn’t Mootools have an equivalent to jQuery’s .ready method? It’s not needed, it’s bloating and if you do need it, simply make your own library for a library solution. If it becomes very popular, it could be apart of the Mootools Core someday.
And not to mention, one day soon (…), we’ll have the Mootools Forge for plugins. I imagine that plugins will be concatenated together and compressed automatically. At that time, plugins for developer usability be easy. If we group usability plugins together, call it mooUser and get it on a CDN, we’ll be in heaven.