Date post: | 06-May-2015 |
Category: |
Technology |
Upload: | christian-heilmann |
View: | 11,794 times |
Download: | 3 times |
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/)