Creating Happy Little

Web Sites

Maintainability,Performance and

Predictability

Christian Heilmann, Guardian Brown Bag , London, June 2008

Happy Web Sites are working web sites.

The definition of a working web site is out of your hands.

You have no clue who uses your web sites with what and

in which state.

This is 100% fact.

Deal with it.

How can you deal with it?

Keeping the damage as low as possible.

Don’t rely on anything.

Let those who care about a certain technology deal with

it.

Without caring for the technologies we have to use to create web sites we will build unhappy web sites.

These will lead to unhappy users, unhappy bosses and

you will lose your job and end up dancing half-naked for tourists in Covent Garden*

*YMMV

The technologies:

HTML

CSS

JavaScript

This is what will come out at the end of any development

framework.

This is also what gets rendered and executed in the

unknown.

HTML

Your foundation and structure

HTML is markup and you need to tell the user agents what it

is and what to do with it.

Therefore you need a valid DOCTYPE, a language

definition and encoding instructions.

You also need to follow the rules of HTML.

This ensures that user agents *should* do what you tell

them.

More importantly it also removes one more source of problems and you can hand over to the next developer without having to explain

what naughty things you’ve done to the markup.

HTML provides hooks for the other technologies:

Element names and nesting structure.

Use the right element for the right job, do not re-invent

HTML as you’d also need to re-invent the UA support!

Nest as much as needed to provide enough hooks, but don’t nest for the sake of it.

IDs and classes are there to define special elements and provide hooks for the other

technologies.

ID = unique to the documenta very special case that carries a lot of CSS weight and is darn easy to access in JavaScript.

class = defining difference or grouping

the odd one out in a group of elements or defining a collection of elements that are scattered around the document without being nested in the same parent.

Use both sparingly, if you understand CSS, you don’t

need many.

CSS does one thing terribly well:

It cascades down the document tree.

Use this: define from the common down to the specific.

body{}p{}#content p{}#content p.about{}

More of this sort of thing

Less of this sort of thing

This will keep your CSS lean and mean and easy to

maintain.

If you don’t structure your CSS, maintainers will simply tack on more selectors at the

bottom.

They’ll also pad the selectors until the specificity is enough, or – even worse – add another

DIV with an ID to make it work.

That sort of thing makes web sites very unhappy.

Naming conventions:• Say what it is, not what it will look

like.

• Keep it short and understandable.

• Abvtns dnt wrk wll wv maintnrs.

CSS defines the look and feel - not the behaviour.

Roll-overs are OK, menu systems and clever

interaction are not clever “CSS only”.

This is what JavaScript can do for you.

Rules about JavaScript:• Avoid if possible.

• Use when it benefits the end user – and only then.

• Expect it to fail on every step of the process.

• Play it to its strengths, do not expect it to work like Java/Ruby/Python...

Happy web sites come from mature development

processes and methodologies.

Progressive Enhancement

stuffthatworks.build();

enhancements = [‘a’,’b’,’c’];

var c = 0;

while(environment.supports(enhancement[c]){

stuffthatworks.apply(enhancements[c]);

c++;

}

Accessibility is not a nice-to-have or something to add on

to the end.

Build with accessibility in mind from the start and everybody will benefit.

Don’t make things appear like interactive elements – use interactive elements that

work across all input devices.

Build processes

Validation, Collation and Documentation are not nice-

to-haves.

Validation ensures that code is very likely to work.

More importantly it means that the next developer can

also use the code without knowing your hacks.

If you make a distinct differentiation between development code and

deployment code you will build much happier web sites.

development code is for humans:

Readable, documented, well-structured and following defined code standards.

deployment code is for machines.

collated, minified, without comments, possibly optimised for the environment.

Happy web sites are separated from the backend

and the business logic.

Do not mix them, it will mean unhappy front-end code and a high possibility for security

holes.

If you can, build with APIs internally, this allows for

parallel development and you can release them for the outside world in the future.

Happy web sites are well performing web sites.

Performance on the web is not a small subject.

But there are some easy rules:

CSS in the head – as few as possible.

JavaScript if possible collated into a single include at the

end of the body (browsers stop rendering and smell the flowers for every

script node they find).

Cut down on the amount of images you use – every HTTP

request slows down your page.

Use CSS sprites.

Avoid interaction with the DOM in JavaScript until it is

absolutely necessary.

For example, instead of looping over a document and changing a lot of settings of every element matched by your criteria add a class to the parent element and let

CSS do the work!

When it comes to event handling, use event

delegation, don’t apply a handler to each element.

Make the site available as fast as possible – then get the

nice-to-haves.

Lazy loading of scripts and images has a massive impact on perceived availability of

the web site.

Lazy loading

=

load scripts when and if they are needed by generating

script nodes using the DOM.

Lazy loading of images

=

load a placeholder image and replace it with the real one

when it comes into the viewport of the browser.

The final and most important tip:

Build on what others have done well.

For example the Yahoo User Interface Library.

http://developer.yahoo.com/yui/

• CSS framework (predictable layouts and typography)

• JavaScript framework (make all browsers work the same)

• Graded Browser support (give those who can support what they support)

• Developer tools (logger, profiler, test-framework)

• Validation and deployment tools (JSLint / YUI packer)

• Modularized with a lazy module and image loading module option.

• Widget framework

• Open Source

• Massive Community and documentation.

Performance Resources:http://developer.yahoo.com/performance/

http://stevesouders.com/

http://www.csssprites.com/

http://www.ejeliot.com/blog/129

http://www.wait-till-i.com/2007/07/10/return-of-the-http-overhead-delay-this-time-without-a-server-side-component/

JavaScript Resources:http://24ways.org/2007/keeping-javascriptdependencies-at-bayhttp://icant.co.uk/sandbox/eventdelegation/http://www.wait-till-i.com/2006/03/14/tip-using-css-and-dynamic-classes-to-avoid-loops/

Questions?Christian Heilmann | http://wait-till-i.com | twitter: codepo8

Thanks to: Apelad (http://www.flickr.com/photos/apelad/2048858745/)