A great new test through javascript.ru (an incredible resource, even if in Russian). Dmitry Soshnikov has created a new fun javascript quiz you can test your knowledge against. The difference is that he’s tried to abstract real world problems, collected from various mailing lists or problems of his own doing. Worth 10 mins for sure.

Around Christmas we tend to get a LOT of web traffic at work, so much so that we exceed our agreed bandwith a allocation with RackSpace and end up having to pay huge excess fees. Not wanting to be caught out for a second year in a row, I had a look at various ways of conserving bandwith and alleviating from the CPU load on the webserver. This is when I noticed something odd–there was a lot of traffic we were being charged for that was not showing up through the Apache logs. After a lot of head scratching and many coffees later, it hit me: cookies. Consider this: an average user on our site has something between 300bytes and 1k in cookie data (a lot, I know). The cookies are being sent alongside with every resource that the client browser requests, be it a HTML file, an image, a CSS stylesheet or a .js file. I did some rough maths and it transpired we waste between 10 and 20GB of traffic each month in cookies alone!

Additionally, the CPU usage was abnormally high and no amount of MySQL tweaking was cutting the load times enough to make a sizeable difference. The sheer amount of files accessed and served was taking its toll and limited CSS spriting was just not going to fix that. The clincher came from Google who announced that site speed is to be playing a role in the search engine results pages from 2010–it was time to introduce a content delivery network (CDN) and fix things.

I had a look around at what CDN providers were around but since we are a relatively small and lean startup, we could not justify the expense of signing up for a enterprise scale solution just yet and yet we needed real-time updates. We elected to just get a cheap collocation server instead with no bandwith quota and setup a sub-domain cdn.ourdomain.com which was to remain cookieless. I then reconfigured the site templates to always reference images, css and js through the CDN URL instead and setup an rsync partnership with the new box. And boy, did that make a difference!

First thing you notice now is how much more responsive the site is, how quick it loads and how much faster the browser renders the content due to the increased threading capability. The CPU load times dropped from an average of 1.40 to 0.30. Out bandwith use subsided from well in excess of 200GB a month to a little over 100GB, well within our quota. And that’s through a ‘pseudo’ CDN, or should I call it a CDB (content delivery box). I imagine the user experience will improve even further when we can roll out a proper solution in the near future, one that will use CDN zoning to provide the fastest download speed to clients through geolocation.

In the meanwhile, I was approached by the folks at MaxCDN who kindly offered to sponsor my blog and provide it with a CDN. I thought, what better chance to test the experience and find out about what’s on offer than to try it for free…

I was uncertain as to how easy it would be to implement within WordPress but it turned out to be a walk in the park through the plug-in W3 Total Cache that they provide and support. The whole setup involved all of 5 minutes of work and no changes to my template files (so long as they all reference the native WP functions for URLs). The plugin takes care of sync and you really have nothing to do than to worry about caching. I am still getting to grips with the options here and weighing in what further bits can be exported to maxcdn in addition to my static content. Other than that, it’s been a breeze and has probably sped up my blog a fair bit too. It’s also surprisingly affordable, especially when you consider what Akamai, EdgeCast or Limelight tend to charge. Even cheaper than CacheFly for the basic package without rsync functionality. MaxCDN’s site, control panel and support are also nothing but excellent.

All-in-all, I am a happy chappy and would recommend CDN use as it’s become a lot more accessible (to my surprise).

A nice blog post that samples 35 great fonts free to download, some are actually rather good. Head to Instant Shift to check them out.

There are probably as many ways of looping an array in javascript as there are phrases that are synonymous for masturbation. So, what are they and how fast do they perform? Head over to this test @ a blog on Sun which sports no less than 17 different loops to get a fair indication of how fast things work in today’s browsers.

Disappointingly, the native array.forEach in my firefox 2.5 seems to be one of the worst results. while(length–) { … } ftw!

Only 2 weeks late, which by software development standards is ‘dead on’, mootools 1.2.4 and 1.1.2 are officially released.

Amongst the more-exciting changes for me (aside from the the many fixes and additions to -more), JSON.stringify and JSON.parse native methods and DomReady always firing before load event (this had been plaguing me for a while on IE).

And, last but not least, a Depender class for lazy-loading of required components that can get your class working. Brilliant – on-demand javascript. All-in-all, a very nice and worthwhile drop-in replacement and enhancement over the old 1.2s.

Just a word of mention, 1.1.2 is a fix in the mootools 1.11 branch that will enable IE8 and gecko (firefox) detection. Not bad…

This is not a tool you can rely on for customer-facing development, but I found it invaluable nevertheless. jsPrintSetup is a small fireFox add-on that hands you a controlling object in javascript. You get FULL access to any print-related function you could think of: list printers, select default printers, print silently, control spool, headers… There’s just too much to mention. Very useful when coding a CMS that needs to print specific things to specific printers (for example, invoices on printer #1 and labels on printer #2).

Here is an example that fetches a list of printers and remembers the user’s preference for future use:

// only do something if the plugin is live
if ($type(jsPrintSetup)) {
    var printers = jsPrintSetup.getPrintersList().split(","); // get a list of installed printers

    // no print dialogue boxes needed
    jsPrintSetup.setSilentPrint(true);

    // create a dropdown
    var printList = new Element("select", {
        id: "printerList",
        events: {
            change: function() {
                Cookie.write("defaultPrinter", this.get("value"), {
                    path: "/admin/",
                    duration: 365
                });

                // save the new printer selection
                jsPrintSetup.setPrinter(this.get("value"));
            }
        }
    }).injectTop($("printSetup"));

    // get default by preference if any
    var defaultPrinter = Cookie.read("defaultPrinter");

    printers.each(function(el) {
        new Element("option", {
            value: el,
            text: el,
            selected: (defaultPrinter == el) ? "selected" : false
        }).inject(printList);

    });

    // attach an event that prints from an element called goPrint
    $("goPrint").addEvents({
        click: function() {
            jsPrintSetup.print();
        }
    });
}

I was browsing around the internet and came across Iconza by turbomilk. As it seemed rather nice and my Framework Detector Firefox add-on sniffed out mootools, I had a look at the source.

It uses what looks like a colour picker plugin for mootools called mooRainbow. Nice to have in your toolkit, you never know. Iconza’s png trickery is not too shabby either, nice site (as you’d expect from Turnomilk anyway).

Nathan White announced the mootools 1.2.3 release today. This is to be the last version prior to bumping everything into mootools 2.0.

Although mootools 1.2.3 is mostly about bug fixing, it does introduce an important feature: “Element: MooTools compatibility mode: the $ function is only defined if no pre-existing $ function is found. If an existing $ function is found, you can use document.id()”

In reality this means that mootools will be able to co-exist with frameworks such as jQuery (or others). It will still not work alongside Prototype, for example – extending prototypes just cannot be namespaced. Also, even though you now CAN use more than one framework at a time, you probably shouldn’t do so on the same page, its a wasteful and needless practice.

Aaron Newton has written up what appears to be one of the most comprehensive and unbiased answers to the eternal question: jquery or mootools. I cannot recommend it enough to anyone that’s just starting with javascript or is looking at both frameworks from the “which is better for me and my project’s needs” angle. It’s worth mentioning before you begin, this is a comparison of the core functionality, provided by each framework – not what is possible should you decide to build on it.

The short summary: both frameworks are great but serve a different purpose, with jquery is more user and beginner-friendly, focused / optimised around DOM access and mootools, building and extending the javascript native prototypes and methods (not at the expense of the things that jquery can do).

Another way to look at it: mootools takes things further than jquery and makes javascript fun, introduces features that are coming in javascript 1.8 and provides a great layer for object orientated programming whereas jquery is staying where it’s at its best: shortcuts, chaining and styling, leaving anything else you may need to plugins and vanilla javascript.

http://jqueryvsmootools.com/

The comments are also well worth the read, some good points on the pro’s and con’s of each framework and a bit on why mootools does not try to be unobtrusive / conflict free with other frameworks.

Just a quick update, in case you missed it: mootools 1.2.2 is out, mostly a bug fixing release. Also, the new mootools-more is out. So… check them out.