However, the browser on my N810 doesn’t support CSS3, and due to the existence of the N900 (and Android, sigh), it is unlikely ever to do so.

There’s a performance penalty every time you have to look for a global variable / function / object, because JavaScript has to first search the local scope, then the bubble up through scopes / closures, then finally get to the global context for one last search.

Worse, though, is that it’s really easy to accidentally overwrite someone else’s code by using a variable or function name that another chunk of code needed. Think about namespaces in other languages, and the same basic principles of organization apply here.

To combat the problems, look at the JavaScript module pattern. I introduce this a little in my most recent post on composite JavaScript apps, and there’s a ton of other info out there that goes in to much more detail.

The gist of it, though, is that you can wrap up your code in a function (functions inside of functions…) and then provide a “public” API that is returned from the function, to kick off your app.

MyApp = (function(){
  var somePrivateVar = “foo”;
  var somePrivateFunction = function(){
  }

  // the public stuff
  var myApp = {};
  myApp.doStuff = function(){
  }
  // it’s “public” because it’s being returned, here
  return myApp;
})();

$(function(){
  MyApp.doStuff();
});

[1] Given that both the week and the day are one digit you could use a c25k[wd] indexing scheme, where w is the week and d is the day – so c25k[42] is the schedule for week 4, day 2