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 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.
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 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
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:
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.
Final word: Gucci
- Disable JS in your browser
- Visit Gucci.com