X Close

Digital Presence Blog



Archive for the 'javascript' Category


NickDawe12 August 2010

I’ve been really inspired by the ongoing competition at JS1k challenging developers to build a JavaScript demo in under 1kb (and if possible, to fit inside a Tweet!). Many of the demos use the ‘canvas’ element, allowing for more intricate visualisations, while others are demoing fascinating techniques which I’ll be sure to investigate further.

Anyway, here are some of my favourites:

The Future of JavaScript?

NickDawe3 February 2009

Just to briefly mention a recent post in John Resig’s blog about some impressive scripts developed that could challenge how we consider JavaScript’s capabilities. We’re still quite used to thinking of JavaScript in terms of how it can do basic page manipulations, so the idea of building such complex systems as neural networks with it is fascinating.

I won’t bother explaining the scripts here as Resig describes them with more detail and clarity than I’m capable of… However it’s incredible to think that such complex programs are able to be run in web browsers, and presumably without users even having to download any kind of extra plug-ins to run them. And although developments in programming techniques (e.g. new frameworks, AJAX, etc.) have surprised many in the last few years, this is a sign that there’s a lot more to come.

Anyway, if you need some programming inspiration, take a read of:

[Test link]

Debugging CSS and JavaScript in Internet Explorer 6

NickDawe14 October 2008

I’ve always preferred developing sites in Firefox because a) it’s a standards based browser, and b) it has a vast array of helpful web developer add-ons*.

Sadly, the reality is that many users will still be viewing your site in Internet Explorer 6. This is particularly true for sites aimed at UCL staff, as StaffWTS is currently using this browser.

I’ve recently been trying to build a Javascript application that works on all browsers, and unsurprisingly had a nightmare trying to get the thing to work in IE6: not only does this browser treat HTML/CSS standards with disdain, but its implementation of JavaScript is of course slightly different.

However, there are a small number of very, very useful tools now available, which really do help when developing for IE6.

MS IE Developer Toolbar screenshot

1. Microsoft’s Internet Explorer Developer Toolbar (pictured above)- Similar to Firebug’s Inspect Mode. View the DOM tree of a page; select page elements; view elements’ CSS properties

2. DebugBar – A web developer toolbar for IE. As well as being able to analyse the DOM tree, you can check javascript functions, validate HTML code, find screen color codes, resize the window to different screen sizes, and much more.

3. Companion.JS – A reasonably detailed JavaScript debugger for IE. IE’s JavaScript error messages are normally quite intelligible, so this is invaluable.

4.  Position Is Everything’s primer on IE vs Standards – Not a tool as such, but just a helpful few pages on CSS problems in IE. To be honest, as helpful as all the tools above are, the most useful thing seems to be to try understand how IE works with JS and CSS, and hopefully avoid even getting as far as having to rip hair out while debugging…
*If you don’t know what I’m talking about, at least see Firebug, the Web Developer Toolbar, and  ColorZilla


NickDawe21 August 2008

Just thought this could be use to any UCL JavaScript developers out there. If you’re like me, and tend to write sloppy, unintelligible code, before having to endure various browser error consoles (apart from FF’s helpful add-ons), try out JSLint.

JSlint screenshot

JSLint verifies any code you paste into it according to a set of standards (some of which are customisable). This isn’t just for debugging syntax errors, etc. but also ‘style conventions and structural problems’. I’m aware that most of the time the look of my code isn’t too important (as long as it works) because I’m the only person who’s ever going to be editing it. However for those times when I’m contributing to a bigger application that others are going to be playing with, or when there are particular objects that I want to make reusable, it’s a great help to have a ‘second opinion’ on whether my code is indeed clean, or just nastily sloppy.

See JSLint for more information

What are Javascript framework libraries?

NickDawe30 June 2008

Javascript framework libraries have become almost omnipresent over the web in recent years, and it’s no real surprise. Used carefully, they can cut the time it takes to develop both basic and advanced Javascript applications, as well as giving the developer tools to do things that would have previously been thought too difficult.

Currently, the most popular libraries seem to be jQuery, prototype, script.aculo.us, MooTools, and Dojo. All of these enable you to develop javascript apps in far quicker times than using DOM methods, although each library also has its own particular way of doing this. We’ve been working with jQuery and MooTools in the last few months, and are also striving to include small jQuery applications into Silva’s Kupu editor*.

jQuery home page screenshot

But how do they actually cut out development time? One quick example is the way that you can usually select an element in your page. E.g. to select an element with a particular ID in Javascript, and then affect its CSS properties, you’d have to do something like the following:


… whereas in jQuery, this can be shortened to:


This may not seem so impressive at first, but the $() function above can also select any element in the page, including all elements using a certain class (which for most current browsers, would require far, far more scripting):


Anyway, if you have a UCL web account on the Apache server, you can easily try these out for yourself. For instance, we’d recommend the ‘Getting started with jQuery‘ tutorial to get an idea of some of the other immense capabilities of jQuery.

One criticism of javascript framework libraries has been the length of time it takes for them to load into a page. It’s fine if you’re working on a large application like an AJAX email system that’ll massively rely on the library to do a multitude of tasks, but if you just want to load a library to help script a form validation facility, the extra library scripts can make page loading time seem excessive. What’s also worse is if you keep on having to load the same library scripts on different sites over and over again (e.g. browsing on the BBC home page which uses jQuery, then to a personal home page which uses the same jQuery scripts, and then to Digg.com, which also uses it. Overall, the browser has had to load the same library scripts three times – a completely unnecessary duplication and waste of bandwidth).

A solution for this has been suggested by Google, and we’d recommend users to try implementing it. When loading a framework into your page, rather than store the scripts on your own site, refer them to Google. If a user goes to a site that uses this Google stored script, their browser will hopefully cache the script. If the user then goes to another site that refers to the Google stored script, they won’t have to download it again, because the script will already be cached in the browser. This will obviously cut out unnecessary duplication, and generally make things faster for browsers.

To load the Google stored libraries, include the following code in your page header:

<script type=”text/javascript”
<script type=”text/javascript”>
google.load(“jquery”, “1.2.3”);

The ‘google.load()’ function contains two arguments. The first is for the framework, the second for the version. For full details, see Google’s AJAX Libraries API documentation.

While we’re still experimenting with these frameworks, they are ultimately cutting a lot of javascript development time out, as well as taking away some of the (occasionally) frustrating limits of working with the DOM API.

*… And if anyone has good idea for a particular javascript effect or widget they’d like to see available in Kupu, please do contact us with suggestions!