NPM + MooTools + Ender = <3

By Ryan Florence, published 2011-05-12

Part of the issue JavaScript Micro Libraries.

The recent micro-library push has the JavaScript community split. Some folks hate it immediately and say “looks like 2003 all over again”, while others, like myself, instantly love the idea of ender, a client-side library “shell” plus a package builder.

There are also other projects like Browserify and Stitch that go as far as to bring the modular require and exports paradigm to the browser–which is quite awesome. However, these require even further mind-shifts to write your client code like server code, so I’m going to just table them for now and focus on ender.

What is Ender

Ender is a simple thing. If you’re coming from MooTools it’s simply Packager + Element.implement; from jQuery it’s a bundler + $.fn.foo = fn. I’m only going to talk about the bundling part in this article (though the client-side API gets me equally excited).

MooTools is ripe for the picking!

MooTools is already a bundle of micro-libraries, if you don’t think so, get a clue d00d. MooTools has been following this paradigm of modularity from the beginning, but it’s been limited to it’s own clique and conventions and has yet to implement CommonJS specs to define each package.

So … in a couple of hours I split up the MooTools Core repository by file, and created a package and package.json for each file in MooTools Core and published it on NPM.

I hope your ready for teh awsomz.

Getting MooTools class

$ npm install mootools-class

And there you have it, Class with its dependencies. Ah, but how can one package it up?

$ ender build mootools-class mootools-element --noop --output mootools

And just like that, a file containing MooTools Class and all its dependencies. You can do this right now, actually. And you should. How about Fx?

$ npm install mootools-fx-morph mootools-fx-transitions

Or better yet, in the root of your project create a package.json file like this:

{
	"name": "MyProject",
	"version": "1.0.0",
	"dependencies": {
		"mootools-fx": "1.3.2",
		"mootools-fx-morph": "1.3.2",
		"mootools-fx-transitions": "1.3.2",
		"mootools-cookie": "1.3.2"
	}
}

And then simply:

$ npm install .

You can find what’s available with search

$ npm search mootools

Preset Builds

We’ve been talking a lot about a “browser build” and a “server side” build in MooTools for a while. Creating these builds are simple npm modules with nothing more than a package.json with this setup.

$ npm install mootools-client
$ npm install mootools-server

Yes, these also work, right now. Try it.

Whatchoo think?

Let me know. This is the start of something new, and awesome, and I hope and pray that MooTools 2.0 or 1.3.4 or whatever breaks everything into separate modules like I’ve done to publish them on npm.

If we all implement CommonJS for our stuff, then we can do more with it now and in the future. Imagine an environment where you could use and build different versions of each module. Or how easy it will be to release new code when each module is on its own release cycle. Or a mix of MooTools / Dojo / and some micro libs. I love it.

Point is, this isn’t for micros only, this is for everybody.

Hi, I'm Ryan!

Location:
South Jordan, UT
Github:
rpflorence
Twitter:
ryanflorence
Freenode:
rpflo

About Me

I'm a front-end web developer from Salt Lake City, Utah and have been creating websites since the early 90's. I like making awesome user experiences and leaving behind maintainable code. I'm active in the JavaScript community writing plugins, contributing to popular JavaScript libraries, speaking at conferences & meet-ups, and writing about it on the web. I work as the JavaScript guy at Instructure.