Website Updates pt3

The final member of the web trilogy is JavaScript and this too has undergone quite a few changes over the years. Many of the changes have really been in the way that Javascript is viewed rather than any changes to the language itself. With libraries like jQuery for the browser and node.js for the server it has gone from being viewed as a "toy" language to one considered industrial strength in just a few years. There are also now tools available to help avoid common coding errors.

Initially any Javascript I wrote for the site was in a "C style" since I use that language in my work and superficially the two have similar syntax. It's a bit like English and French using (mainly) the same characters but the resulting language being totally different. Similarly under the hood JavaScript is a totally different beast and what's good, efficient code in C isn't necessarily so in JavaScript. Thus as my knowledge of the latter has increased and newer ways of working in it have emerged I've revisited much of the code to make it neater and less likely to cause problems with other blocks of code. (Note that a lot of the code to be found on the web on scripting sites is of a similar naive level - you need to know what you are looking at! As a rule of thumb, the older the code, the less likely it is to be what is now considered to be decent standard.)

Some of the code was nearly eight years old, virtually as old as the site itself, and was in need of good overhaul - yes it worked but had the appearance of being a hack (well it was a hack!) as basically as soon as I'd got it to work then I'd left it and moved on. Other blocks of the code had been changed over the years but the underlying faults had remained. In some instances a simple tweek or two was all that was needed but for many the changes are a complete reworking to bring the code up to standard. There's the advantage of a working version to refer to and to fall back on but equally having an existing solution can colour how you view the problem (and therefore the solution) so it's possible to end up with something that still has the existing faults without realising it.

An example would be the slideshow code. I'd rewritten it a couple of years ago to be more in line with modern thinking but there were still one or two subtle bugs in there that I hadn't managed to get to the bottom of and fix. I needed to add touch functionality for use on mobile devices so was modifying the code anyway so, rather than simply bolting on the new code, I went for the full rewrite.

By doing things like taking advantage of how browsers handle user actions such as mouse clicks I was able to simplify the workings of the code used to switch between slides which meant that the bugs disappeared! I also took the opportunity to add image caching so that when the user is looking at an image, that time is used to download the next image as a background task so it is immediately ready for viewing. Even with the extra code to deal with touch events and caching, the resulting code is cleaner and smaller by about 25% than what had gone before - I might even understand it when I come back to it in another eight years' time!

The above is typical of work behind the scenes that's led to both fewer and smaller JavaScript files being required for the site. This in turn leads to pages that are faster to load and feel more responsive to user input. I'm still revising the use of JavaScript on the site: many pages no longer require it though equally some pages use more, but I can do this on a page by page basis.

After all this techie stuff - it's time to get back to more active things!