The abridged history of webdev pain
Pre-2000 we had similar issues with the internet at large: requiring a particular browser. Around the same time we also had several other phases; all equally drastic:
- DHTML to the RESCUE!
The time that time forgot. Nobody on the internet could move in fear of pop-up windows and layers flying around inside their browser. It was scary. - Java Applets, you say?
We can program things to run like real applications inside our users’ browsers?! We better make lots of ‘ripple’ effects and plaster them all over our sites - Flash is here to save the day!
Just as with Java, Flash was used for navigation elements and data display because people thought it looked “cool”
You might wonder what is wrong with the prerequisite of scripting and plug-ins. The problem is not everybody wants to use them. There is always the possibility that you might get hacked or have a virus dropped on your computer if you allow sites to script at you. The more anally-secure amongst us will disable all scripting until they trust that site.
You should remember that not all people are stubborn like this. Some people have no choice because they can only go with what a screen-reader supports. People with disabilities are often forgotten when you cannot see them directly.
Web designers should see scripting to their users as a privilege, not a right.
Frameworks
The current fashion in scripting is JavaScript frameworks. There are a few big ones, all coming about from Prototype. script.aculo.us , mootools and jQuery are the popular ones (in my opinion) but shop around. mootools is my favourite.
Frameworks save you time not having to go over the same code over and over again. Most give you a simplified syntax that you can use and most come with lashings of DHTML effects and AJAX tools.
The downside is you’re pushing somewhere between 10k and 600k of JavaScript on your users and we’re still nowhere near everybody having access to good enough broadband.
But there are a great many more problems than people lumping their pages up with heavy framework files.
Features MUST degrade
A common design technique these days seems to be, lets forget the lessons of the past few years and jump straight into designing our latest webapp with the “newest” technologies, namely AJAX.
What the end up with is something that can only be used by people with JavaScript enabled. If they’re a business, this means they have to then fork out for programmers to build a non-JS, accessible version.
What they should be doing is making the non-JS version first. JS can then be used as a layer to add dynamic functionality back into the application. I shall revisit this concept of layering later on.
Separate your code and content
As we have seen over the previous two years, external CSS is the way forward. You save bandwidth and your HTML becomes semantic document in that the design does not define the content. Your JavaScripting should also have nothing to do with the actual content, so why should it be there?
People might start saying “I need in-line code for handling onClick events etc”. This is a fallacy. Events can be added programmatically from a code-behind file. Where you might have done something like this in the past:
<a id="link" href="#" onClick="doSomething(this);">link</a>Using mootools, just for illustration, you will find you can actually do it a lot cleaner and further-reaching:
$('link').addEvent('click', doSomething);That code would make an alert box pop up for the same link as in the first example.
Keep your file count and size down
One of the reasons some webapps have such a bad reputation for being slow is they take months to load. With some versions of script.aculo.us your users might find themselves downloading 20 different (large) files. Each of these requests take a set amount of time and also a chunk of your server’s resources.
For example, Digg has 26 framework and JS script files. All this code could be rolled into one file. On the assumption Digg gets about 1.3million unique visits per month, concatenating their files would save their servers 28.5million requests! 11 requests per second fewer.
You can also compress JavaScript, dramatically reducing it’s filesize. If Digg moved to a more code-efficient framework (like mootools) and employed compression too, they could save 285gigs of data per month.
Whereas I realise that 285gigs is considerably less than $300 to Digg, it’s the users that bear the brunt of their JavaScript. And just imagine how much healthier their servers would be if they had 11 fewer requests coming in per second.
Final word: Gucci
As much a fashion company as they might be, if you really want to see one of the worst uses of JavaScript follow my two step plan:
- Disable JS in your browser
- Visit Gucci.com
And on that happy note, I’ll wish you the best with your JavaScript applications. As long as you consider all your users, you’ll be fine.