sweetnr

Using RequireJS with frontal

carl — Mon, 05 Jul 2010 08:30:34 +0000

RequireJS is a JavaScript loader and module manager. It’s great for loading scripts concurrently and without blocking the page from rendering.

Frontal now supports a simple plugin architecture. Using the .register method it’s possible to mix functionality directly into frontal.

After including RequireJS in my page I can mix it’s functionality into frontal with just one line of code:

$frn.register('require', require);

Now I can use frontal rules with RequireJS:

$frn.require('/path', ['include.js']);

A frontal plugin’s first argument is the path for the rule to match. Any subsequent arguments are passed directly to the function referenced in the call to .register and executed when the path matches the current location. Plugins will also work with the queuing functionality of frontal.

So now I can write frontal rules which automatically load my dependencies through RequireJS, triggering my callback when they have finished loading.

$frn.require('/path', ['include.js'], function(){
  // Do something with the loaded scripts when they're ready.
});

Frontal rules combined with the loading power of RequireJS are a great way to manage script dependencies while reducing request overhead.

The latest release of frontal with plugin support is available on github.

Pixel rot

carl — Mon, 21 Jun 2010 18:21:56 +0000

When a design has spent so long in photoshop that every pixel has been polished to perfection. When your design can’t be implemented without resorting to image maps it’s gone too far. When theres no real text on the page its not a web page anymore it’s a JPEG.

For crying out loud, get it into a browser quickly and iterate; work with the medium not around it.

Adding some jQuery sugar to frontal

carl — Sun, 11 Apr 2010 16:51:09 +0000

I’ve just pushed a new feature and some minor tweaks to the frontal project on github.

jQuery chaining

With the new jQuery module included (frontal.jquery.js) it’s now possible to use frontal rules with jQuery’s fluent interface.

$.frontal('/some/path').addClass('something');

If the frontal rule passed to $.frontal matches the page location a jQuery object containing the page element is returned; should the rule fail to match an empty jQuery object is returned.

.data() now accepts key value pairs

Instead of just getting and setting one big chuck of data it’s now possible to store values and retrieve them with keys.

Setting

$frn.data('key', 'value').data('this','that');

Getting

$frn.data('key'); // 'value'
$frn.data('this'); // 'that'

Domain is removed with .location()

When setting the page location with .location() any domain and protocol that might be preceding the path is automatically removed. This makes it easier to bind ajaxy functionality to links and handle the responses with frontal (particularly in IE which includes the domain when accessing the href attribute — dammit).

I’m getting to grips with how I think frontal can be used now so I’m going to start producing some proper API documentation.

Head over to the github repo for the funsies.

Typekit, slow hosted scripts and the Flash of Unset Text

carl — Sun, 28 Mar 2010 15:23:16 +0000

While working on the forthcoming redesign of the Beam website, FF DIN was made available for licensing with @font-face in WOFF format. It was also released on Typekit.

DIN is Beam’s corporate font and this news presented me with an opportunity to pursue Typekit as an alternative to font replacement techniques like sIFR and Cufón.

While it would appear that the perfect solution had just dropped into my lap; Typekit is a hosted service and this dependance on an external service concerned me.

What if the Typekit service was unavailable?

I started testing the effect of a prolonged delay on the rendering of the page. I created a PHP script that sleeps for 5 seconds and then returns the Typekit loader.

Loading typekit in the HEAD

First I initiated Typekit in the HEAD of the document. This breaks Rule 6 of high performance web sites; but i decided to include it for completeness.

Net panel output of my delayed Typekit loading in the document HEAD.

As I’d expected the page doesn’t render at all until Typekit has responded. This would be a pretty terrible situation.

Loading Typekit at the bottom of the page BODY

Including the SCRIPT at the foot of the page will allow the page to render while we’re still waiting for Typekit to download.

Net panel output of delayed Typekit loading in the document BODY

Much better! The page can render even while we’re still waiting for Typekit. But in that time while we’re waiting for Typekit our text is rendered in default system fonts and only rendered in our web font when it’s finished downloading. This isn’t exactly desirable.

Use a ‘best fit stack’ to soften the shock

In last years 24 ways Mark Boulton wrote ‘Designing for the switch’. In it he suggests specifying a set of system fonts that look similar to our desired web font. This will help us reduce the impact of our flash of unset text.

The best fit stack, in this case i used ‘Lucida Grande’, ‘Lucida Sans Unicode’ and ‘Lucida Sans’

That’s a good start.

Use some JavaScript and CSS to transition

The Typekit library adds a class of ‘tk-active’ to the page BODY after the fonts are loaded; we’ll use this as a hook for some styling to hide the content of the page until our fonts are available.

.tk-loading{
    opacity:0;
}
.tk-active{
    opacity:1;
    -moz-transition:0.2s opacity ease-in;
    -webkit-transition:0.2s opacity ease-in;
    transition:0.2s opacity ease-in;
}

We can use CSS transitions to add a slight opacity tween after our fonts have loaded.

<body class="tk-loading">
 
...
 
<script src="http://use.typekit.com/KIT_ID.js">script>
<script>
    try{
        Typekit.load();
    }catch(e){}
script>
body>

This will hide the contents of our page and show it once Typekit has loaded our fonts. But that brings us back to square one. If Typekit is taking a long time to load our page won't be displayed .

Add some magic with LABjs

LABjs is a great tool for managing JavaScript execution and dependencies.

The first thing we'll do is switch to using JavaScript to set our loading class. We'll do this so that users with JavaScript disabled won't be affected by our meddling.

<body>
<script>
document.body.className = 'tk-loading';
script>
...
body>

Next we'll load Typekit using LABjs.

<body>
 
...
 
<script>
$LAB.script('http://use.typekit.com/KIT_ID.js')
    .wait(function(){
        try{
            Typekit.load();
        }catch(e){}
    });
script>
body>

Net panel output with the delayed Typekit loading through LABjs.

Another advantage to loading Typekit with LABjs is that we can load other libraries asynchronously and execute them independently. This is great because should Typekit or any other externally loaded script take a while to load it won't block any other scripts.

We'll also add a timeout to our page to add our 'tk-active' class, just in case Typekit takes too long to load (we have to do everything we can to ensure the user isn't stuck with a blank page).

<body>
 
...
 
<script>
    setTimeout(function(){
        document.body.className = 'tk-active';
    }, 1000);
script>
body>

Putting it all together

DOCTYPE html>
<html>
<head>
    <style>
    .tk-loading{
        opacity:0;
    }
    .tk-active{
        opacity:1;
        -moz-transition:0.2s opacity ease-in;
        -webkit-transition:0.2s opacity ease-in;
        transition:0.2s opacity ease-in;
    }
    style>
head>
<body>
<script>
    document.body.className = 'tk-loading';
script>
 
...
 
<script>
setTimeout(function(){
    document.body.className = 'tk-active';
}, 1000);
 
$LAB.script('http://use.typekit.com/KIT_ID.js')
    .wait(function(){
        try{
            Typekit.load();
        }catch(e){}
    });
script>
body>
html>

Limit the weights and variants

By default a kit will contain all weights and variants of the fonts family. This can make the font download quite large (often in the region of 250KB+). Unchecking the flavours that aren't used can make a massive difference to download times.

Unchecking unused weights and variants will reduce the download time.

Hopefully someone will find this useful. I'm sure i'll be referring back to it the next time I use Typekit.

Scrappy prototype slides

carl — Wed, 24 Mar 2010 19:33:37 +0000

For posterity’s sake here are the slides from my talk today on scrappy prototypes. They likely make no sense out of context.

Scrappy Prototypes (PDF)

Say hi to frontal

carl — Tue, 23 Mar 2010 21:05:36 +0000

On and off for the past few months i’ve been playing with an idea for a lightweight JavaScript framework. I hate to use the term ‘framework’ but i can’t think of a better way to describe it. Perhaps this is a terrible approach to JavaScript development but it’s been fun to experiment.

It’s built to complement the MVC pattern on the server side. Put simply it can be used to attach code to file and folder paths. Rather than try to explain in clumsy words, here’s some sample code:

/* SIMPLE RULE */
$frn('/things', function(){
    //Execute this for all paths starting with '/things'
 
});
 
/* MATCH ON TWO FOLDER LEVELS */
$frn('/things/view', function(){
    //Execute this for all paths starting with '/things/view'
 
});
 
/* NESTED MATCH */
$frn('/things', function(){
    //Execute this for all paths starting with '/things'
 
    $frn('/view', function(){
        //Execute this for all paths starting with '/things/view'
 
  });
});
 
/* MULTIPLE MATCHES */
$frn('/stuff /things', function(){
    //Execute this for all paths starting with '/stuff' or '/things'
 
});
 
/* RegExp MATCH */
$frn(/.*\.js$/, function(){
    //Execute this for all files with a '.js' extension.
 
});
 
/* MULTIPLE RULES */
$frn([
    ['/some', function(){}],
    ['/things', functions(){}]
]);

The rules above will be executed immediately. This might not always be desirable. As such there’s a way to queue up rules and execute them later.

$frn.queue('xhr')
    .add(/.*\.js$/, function(){
        //Execute this later
    })
    .done();
 
$frn.dispatch('xhr');

This could be useful for handling Ajaxy requests. .dispatch() could be fired inside a callback.

$(window).ajaxSuccess(function(r, xhr, s){
    $frn.location(s.url).dispatch('xhr');
});

As a convenience an arbitrary JavaScript object can be passed directly into the rule function. This could be useful for handling JSON.

$frn.queue('json')
    .add(/.*\.json$/, function(data){
        //Yay! we got some JSON
        alert(data.prop);
    })
    .done();
 
$frn.location('/getsome.json');
 
$(window).ajaxSuccess(function(r, xhr, s){
    $frn.location(s.url).data(r.responseText.parseJSON())
        .dispatch('json');
});

It’s all up on github. Feedback is welcome.

The southby experience.

carl — Wed, 17 Mar 2010 18:09:50 +0000

I’m sitting by my gate ready to fly home from Austin after one absolutely fantastic week at SXSWi. Coming out here i wasn’t sure what to expect.

Geek Camp

I’ve been to a whole slew of conferences in the past. But this was an experience like no other. So much so that it’s prompted me to write my first blog post for months (curse you twitter!).

On the first day i popped into How to Rawk SXSW where Min Jung Kim, Ben Huh (the cheezburger guy); Denise Jacobs and Jeremy Keith tried to prepare us southby n00bs for the week ahead. They explained that it wasn’t just about the panels — to which i was a little sceptical — and that it was a good thing to miss a few; concentrating on “only one or two must sees”. This was great advice; it mean’t there was no need to be rushing to panels and gave you ample opportunity to mingle. The random conversations i struck up with strangers in the convention centre corridors formed some of the highlights of the whole experience for me.

The parties are a huge part of the southby experience. Every night there were no less than five parties sponsored by the latest start-ups vying for your attention (or location). Enticed by free alcohol and t-shirts we queued around the block to get inside. Once inside we’d head straight for the heaving bar, where we’d snag a few scoops of Shiner Bock the local beer of choice (It’s really good). Beer in hand you’d try to find someone to talk to. This was the source of some great conversation and connections. Sooner or later you find yourself on a crawl with a group of total strangers from Greenpeace, and being scolded for buying a KitKat earlier in the day. This process repeated nightly (though not with Greenpeace each night; those guys can drink!), resulting in the perpetual hang over i’ve yet to fully recover from. Despite all the drinking i managed (to my credit) to make it to the 9:30 sessions every morning.

At southby, I learn’t how to not be British (though Texans love the accent!).

I’ll be back next year; that’s a given.

I’m going to write up my notes over the next day or two and should hopefully have some more technical posts to deliver.

Tweet like a Pirate!

carl — Thu, 17 Sep 2009 19:47:35 +0000

Its International Talk Like a Pirate Day tomorrow (September 19th) so to celebrate here’s a quick bookmarklet I put together.

Built on top of the awesome Talk like a Pirate translation ARRPI.

Drag the following link to your bookmarks and enjoy: TweetARRR!

HTML5 primer

carl — Wed, 09 Sep 2009 21:37:19 +0000

Today i had the joy of presenting a run down of the exciting new features in HTML5 to the entire team.

Here are the slides in a PDF html5-primer.pdf.

People cards

carl — Sat, 04 Jul 2009 21:04:54 +0000

“People cards” is a little side project I’m working on at the moment. Essentially they’re MOO mini cards with the URL’s of your social networking profiles printed on them.

The idea being that you can give them people you meet while you’re out and about, at meetups, conferences etc.

I’m using the Twitter API (using OAuth) and Google’s Social Graph API to fetch related profiles on sites that support FOAF and XFN.

Once I’ve gathered all the user data i need i make a request to the MOO API and then push the user onto the MOO customiser and checkout.

Just need to add a design then i can put this baby live.