December 20th, 2006 by Aaron N.
So I’ve been very busy the last few weeks. I’m rewriting, well, pretty much all the javascript on Download.com. Fun! I’ve written a few new classes that I think will be helpful; more on those later.
In the mean time, here are two posts from Ajaxian that are worth a read. The first is on using CNAMES to allow your browser to serially download javascript and css, while the other is on compressing and concatenating files.
Note that Firebug 1 (beta) will let you actually see firefox download all your files and see the order and time each took.
Also note that our new framework environment does the compressing and concatenation stuff, but it’s still interesting to see the work that others are doing.
Aaron
Posted in Optimization | No Comments »
November 14th, 2006 by Aaron N.
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 »
Posted in Best Practices, CNET JS Standards, Code Snippets, Examples, MooTools, Optimization, Organizing Code, Reference | 4 Comments »
November 1st, 2006 by Aaron N.
via ajaxian (as usual):
Aaron Hopkins of Google has released an article on Optimizing Page Load Time which came out of his experience optimizing page load times for a high-profile Ajax application.
He starts off talking about “how much I could reduce latency due to external objects. Specifically, I looked into how the HTTP client implementation in common browsers and characteristics of common Internet connections affect page load time for pages with many small objects.” Read the rest of this entry »
Posted in Best Practices, Optimization, Reference | No Comments »
October 26th, 2006 by Aaron N.
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 »
Posted in CNET JS Standards, Optimization | 2 Comments »
October 3rd, 2006 by Aaron N.
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 »
Posted in CNET JS Standards, MooTools, Optimization, Organizing Code, Reference | No Comments »
September 26th, 2006 by Aaron N.
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…
Posted in CNET JS Standards, Event Scripting, Examples, MooTools, Optimization | 4 Comments »
September 25th, 2006 by Aaron N.
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.
Posted in CNET JS Standards, Code Snippets, Optimization, Tools | No Comments »
September 20th, 2006 by Aaron N.
Here’s a short little description of how to use labels, breaks, and continues to cut down on loop iterations and speed up your code.
Just a quick reminder that you can drastically cut down on loop iterations by using the break and continue commands, and that there is an option to label loops to allow nested loops to stop their parents from iterating.
Posted in Code Snippets, Examples, Optimization, Reference | No Comments »
September 20th, 2006 by Aaron N.
So I posted yesterday in my flurry of catch-up posts about the mad4milk.net guys new framework: MooTools. I’ve had a little time to dig into it and I must say that I’m blown away. In many ways, this is the framework that I’d say CNET should write for itself if it were to take on such a task. Read the rest of this entry »
Posted in 3rd Party Libraries, CNET JS Standards, MooTools, Optimization, Prototype, Scriptactulous, moo.fx | 2 Comments »
August 22nd, 2006 by Aaron N.
Unlike almost every other programming environment, javascript has one big drawback: you have to deliver it to the client. This can result in a big payload of code you’re dropping on your user and there isn’t a whole lot you can do about it.
You can lazy load the javascript so it’s only on demand. You can optimize your code as best you can so that functionality that’s not really needed isn’t present, and other functionality is written as succinctly as possible. You can set up your server to deliver the javascript g-zipped if the browser supports it.
But one simple thing you can do is just delint your code - remove all the tabs and comments and line breaks. It makes for unreadable files, but you just keep a marked up version and a compressed version. For example, Andy Lottmann took the prototype library and knocked it down from 55K to 35K or so. Read the rest of this entry »
Posted in Optimization, Reference | No Comments »
