Here’s a trick I learned from Valerio (author of Mootools) on how to handle options for classes and functions. After refactoring a couple of legacy scripts I thought I’d share for those of you who might not know it already. This example below uses the Mootools syntax for class creation, but the rest of it can be used even on its own I think. Read the rest of this entry »

We’ve been working pretty hard on CNET’s new javascript global framework. It’s based on Mootools with a bunch of other things mixed in. Last week I took on the task of documenting the entire Mootools library, now online. I struck up a conversation with the author of that library, Valerio Proietti from mad4milk.net and have since been granted access to contribute to the source of that library (thanks Valerio!). Mostly my contributions have been focused on the docs, but I’ve also helped out with a few bugs and the like.

Anyway, one of the things that Mootools turned me on to was Dean Edward’s /packer/, which is an awesome javascript compression tool. This thing compresses our libraries dramatically, sometimes as much as halving their file size. We’ve actually put our new global libraries into production on news.com and I just got around to actually testing the efficiency of the compression algorythm. Read the rest of this entry »

Hi all,

It’s been a few days since I posted. I’ve been heads down on the project to create a global javascript framework for our sites (Redball, at least). I’ve finished this work (or at least gotten it to a releasable state) and I thought I’d share an update. I plan on documenting it extensively and providing a lot of examples (and teaching it) in the near future, but for those of you who are curious, you can peruse the library now. It’s mostly stable (we’re still tweaking and adding things) and you can just download them and read them if you want to see what’s in them.

They include a lot of functionality, are highly extendable, easily debuggable, and hopefully will be useful. The current framework file is about 30K, but Andy just turned me on to a more efficient javascript compressor that will bring that down to 19K. I can’t express how awesome it is to have this thing going out and it managing to pack in so much functionality in such a small package. Read the rest of this entry »

Huh. So this was eaiser than I thought.

In the Download.com Watch List profile page we use the Behaviour library to define a bunch of functionality (er, I mean “I use…” as I wrote all this over a year ago). We’re going to replace Prototype with our new framework (based mostly on Mootools). Behaviour will work in the environment, but it’s 8K that I don’t really want to keep around. So, what the hell, let’s try and rewrite it with Mootools. Well, here it is:

var BehaviourBaseClass = new Class({
	initialize: function(){
		this.behaviours = [];
		var bhvr = this;
		Event.onDOMReady(function(){bhvr.apply()});
	},
	register: function(actions){
		if(! this.behaviours.test(actions))
			this.behaviours.push(actions);
	},
	apply: function(actions) {
		if ($type(actions)!='array') {
			actions = this.behaviours;
		}
		actions.each(function(bhvrs){
			for (bhvr in bhvrs){
				try {
					if($type(bhvrs[bhvr])=='function') {
						$S(bhvr).each(function(el){
							bhvrs[bhvr](el);
						});
					}
				} catch(e){}
			}
		});
	}
});
var Behaviour = new BehaviourBaseClass();

…which compresses down to 425 703 Bytes. Not bad.

Update
Ok, so I rushed to press a little. This code didn’t work when I put it into place. I fixed it, but that brought the file size up to 703 Bytes instead. Still, it’s a 10X reduction…

So I’m working on a set of global javascript files for redball. I’ll post more on this when I’m finished (hopefully including documentation and examples, but that might take me a while), but here’s something I just whipped up that you might find useful.

I’m compressing all my javascript (so no extra spaces or comments) which means that debugging these things is going to be a pain. If you get an error on the live site and need to fix it, the debugging info you get out of your browser won’t be that helpful in fixing things. On top of that, I don’t want to have to edit a compressed file to debug it.

Previously, what I did was overwrote the compressed version with the non-compressed version to debug my stuff, but this is a pain if the code is on akami and you don’t want to do a bunch of work to change that.

So I wrote up a little script that goes along with my dbug console wrapper for firebug (note the update comment below the post for the most recent code). Here’s the function:

function dbugScripts(baseurl, libs){
	if(window.location.href.indexOf("debug=true")>0){
		for(i=0;i
");
		}
		return true;
	}
	return false;
}

Then, you go to your compressed libraries and you do this:

if(!dbugScripts("/the/location/of/my/scripts/",["script1.js","script2.js","etc"])){
	...all my compressed javascript goes here...
}

So what’s this do? If you put “debug=true” into the query string of the page you’re viewing (and wish to debug), then all the dbug.log statments (again, see my dbug console wrapper function) will go to the console.log AND all your compressed javascript files will be ignored, with the document instead using the non-compressed versions. Voila, easy debugging.

Have fun.