Shaving Bytes with MooTools

By  on  

With mobile web technology continuing to gain momentum, one of the major concerns facing JavaScript frameworks developers is file size.  Most of the frameworks, most notably MooTools and Dojo, are extremely modular and allow you to add functionality as needed.  Be that as it may, there are still some ways you can shave bytes from your MooTools code while keeping the code readable.  Let's take a look at a few ways we can do this.

Dollar Function

document.id was to introduced to avoid naming collision with other frameworks (jQuery, for example) but it's still good practice to use closures to abstract the document.id name:

(function($) {
	//now "$" is limited to just this code block
	//will save many, many bytes!
})(document.id);

document.id is great when you need it but most people don't use multiple frameworks on a given page;  thus the traditional "dollar function" will be fine.  document.id will save you 10 bytes with each usage.

Fade Value

MooTools' method names and argument values are meant to be common so that you may almost just guess the method name to accomplish something.  Many times the method name or argument value are exactly as you would speak them in English.  Thus is the case with the fade method, which you may pass "in" or out".  You may also, however, pass number values:

//myElement.fade("out");
myElement.fade(0);

Using a number will save you 3-4 bytes (including quotes) with each usage.  Better yet is that the code is stays readable.

Style Camel-casing

As you know, getting and setting element styles via JavaScript requires you camel-case style names.  MooTools has an internal method of converting 'margin-top' to 'marginTop' so that you can set styles the same way you would within a stylesheet.  For the sake of saving space, you could just skip the dash and camel-case your CSS properties:

//myElement.setStyle('background-color','#f00');
myElement.setStyle('backgroundColor','#f00');

A 1 byte saving (or more, depending on the property) on a single usage, but frequent usages will provide more savings.

Scoped Vars + Compression

This technique has been labeled "extreme" but I don't see anything wrong with it.  This technique basically entails creating variables to represent string literals so that a compressor can easily compress strings which otherwise wouldn't be compressed.  Check out the following before and after example:

//regular technique - before compression
(function() {
	myElement.setStyle('opacity',0);
	myElement.setStyle('opacity',1);
	myElement.setStyle('opacity',0);
	myElement.setStyle('opacity',1);
	myElement.setStyle('opacity',0);
	myElement.setStyle('opacity',1);
})();

//regular technique - after compression
(function(){myElement.setStyle("opacity",0);myElement.setStyle("opacity",1);myElement.setStyle("opacity",0);myElement.setStyle("opacity",1);myElement.setStyle("opacity",0);myElement.setStyle("opacity",1)})();
	
//my technique - before compression
(function() {
	var opacity = 'opacity';
	myElement.setStyle(opacity,0);
	myElement.setStyle(opacity,1);
	myElement.setStyle(opacity,0);
	myElement.setStyle(opacity,1);
	myElement.setStyle(opacity,0);
	myElement.setStyle(opacity,1);
})();

//my technique - after compression
(function(){var a="opacity";myElement.setStyle(a,0);myElement.setStyle(a,1);myElement.setStyle(a,0);myElement.setStyle(a,1);myElement.setStyle(a,0);myElement.setStyle(a,1)})();

//my technique - extreme - before compression
(function() {
	var opacity = 'opacity', el = myElement, setStyle = 'setStyle';
	el[setStyle](opacity,0);
	el[setStyle](opacity,1);
	el[setStyle](opacity,0);
	el[setStyle](opacity,1);
	el[setStyle](opacity,0);
	el[setStyle](opacity,1);
})();

//my technique - extreme - after compression
(function(){var a="opacity",b=myElement,c="setStyle";b[c](a,0);b[c](a,1);b[c](a,0);b[c](a,1);b[c](a,0);b[c](a,1)})();

I contend this code is very readable but some would argue with me.  If you use the same string often, however, this technique could save you a *TON* of space.

In the end...

None of these ideas are groundbreaking but when it comes to mobile technology, every byte helps.  Coupled with utilities like the YUI Compressor and likewise tools, you'll be able to shave KBs of load time with minimal code changes!

Recent Features

  • By
    Create Namespaced Classes with MooTools

    MooTools has always gotten a bit of grief for not inherently using and standardizing namespaced-based JavaScript classes like the Dojo Toolkit does.  Many developers create their classes as globals which is generally frowned up.  I mostly disagree with that stance, but each to their own.  In any event...

  • By
    5 HTML5 APIs You Didn’t Know Existed

    When you say or read "HTML5", you half expect exotic dancers and unicorns to walk into the room to the tune of "I'm Sexy and I Know It."  Can you blame us though?  We watched the fundamental APIs stagnate for so long that a basic feature...

Incredible Demos

Discussion

  1. kolin

    excellent, I always like to save, whether its money, lives or bytes. It’s all good.

  2. An even faster one would be (why else use a closure here?):

    (function(func,param){
    func(param,0);
    func(param,1);
    //.....
    })(el.setStyle,'opacity');
  3. Patrick

    I noticed that the Google Closure Compiler doesn’t seem to compress variable-names used in the “extreme”-method, as it assumes that such compressions would be done automatically by using GZIP-content-encoding. Only YUI really compresses the “extreme” variant.

    But somehow I don’t get the first tip – will the traditional $() call only work inside the functions body?

Wrap your code in <pre class="{language}"></pre> tags, link to a GitHub gist, JSFiddle fiddle, or CodePen pen to embed!