The road to
professional web
development
Christian Heilmann | http://icant.co.uk | http://wait-till-i.com
Taipeh, Taiwan, April 2009

Hello and thank you for being
here.

I am Chris...

...and today I will talk about
the road to professional web
development.

You cannot look forward
without learning from the
mistakes of the past.

Otherwise you are very likely
to repeat them.

So let’s take a look at the past
of web development.

The Dark Ages
http://www.flickr.com/photos/25725360@N05/2929959881

In the beginning there was
HTML.

It structured text into
headings, lists and
paragraphs and linked
documents with each other
using anchors.

This was good, and quite a
revolution...

...but also very, very boring.

People wanted colours,
different types of text,
borders and images.

Which lead to the next step.

The first
mistake:
Presentational
Markup

Adding bgcolor, color,
<font>, border, hspace,
vspace,float and all other
presentational HTML allowed
us to style the document.

It doesn’t allow you to style a
whole site though.

If the design of the site
changes, you needed to
change each document of it.

However, as sites were small
this was not a problem – yet.

Design was still limited to a
single column.

Until people realised that you
can use the <table> element
to create multi-column
layouts.

And it was *so* easy.

..if you knew all the problems
that different browsers have
with showing the table
properly.

<table width=\"500\" border=\"0\">
<tr>
<td width=\"1\" bgcolor=\"black\"><img src=\"spacer.gif\" width=\"1\" height=\"1\" alt=\"\"></td>
<td width=\"10\" bgcolor=\"black\"><img src=\"spacer.gif\" width=\"10\" height=\"1\" alt=\"\"></td>
<td width=\"118\" bgcolor=\"black\"><img src=\"spacer.gif\" width=\"118\" height=\"1\" alt=\"\"></td>
<td width=\"10\" bgcolor=\"black\"><img src=\"spacer.gif\" width=\"10\" height=\"1\" alt=\"\"></td>
<td width=\"300\" bgcolor=\"black\"><img src=\"spacer.gif\" width=\"350\" height=\"1\" alt=\"\"></td>
<td width=\"10\" bgcolor=\"black\"><img src=\"spacer.gif\" width=\"10\" height=\"1\" alt=\"\"></td>
<td width=\"1\" bgcolor=\"black\"><img src=\"spacer.gif\" width=\"1\" height=\"1\" alt=\"\"></td>
</tr>
<tr>
<td width=\"1\" rowspan=\"3\" bgcolor=\"black\"><img src=\"spacer.gif\" width=\"1\" height=\"1\" alt=\"\"></td>
<td width=\"1\" rowspan=\"2\"><img src=\"spacer.gif\" width=\"10\" height=\"10\"
alt=\"\"></td>
<td width=\"1\" colspan=\"3\"><img src=\"spacer.gif\" width=\"1\" height=\"10\" alt=\"\"></td>
<td width=\"1\" rowspan=\"2\"><img src=\"spacer.gif\" width=\"10\" Navigation Content
height=\"10\"
alt=\"\"></td>
<td width=\"1\" rowspan=\"3\" bgcolor=\"black\"><img src=\"spacer.gif\" width=\"1\" height=\"1\" alt=\"\"></td>
</tr>
<tr>
<td>Navigation</td>
<td></td>
<td>Content</td>
</tr>
<tr>
<td colspan=\"5\"><img src=\"spacer.gif\" width=\"1\" height=\"10\" alt=\"\"></td>
</tr>
<tr>
<td rowspan=\"7\"><img src=\"spacer.gif\" width=\"1\" height=\"1\" alt=\"\"></td>
</tr>
</table>

Also: what do you need to do
when the navigation has to
move to the right?

The solution was to separate
the presentation from the
structure.

CSS

CSS allowed you to define the
look and feel in a much more
detailed manner.

CSS is defined once and
applied to as many
documents as you want.

So moving a navigation
meant changing a single file.

However, the problem was
that developers wanted more
and more and the standards
took too long to agree on.

Browser Wars
http://www.flickr.com/photos/7189565@N07/3279178176

As browser makers were in
fierce competition this lead to
non-standard extensions to
both HTML and CSS.

This, together with more and
more support for JavaScript
in browsers lead to another
dark period of web
development.

DHTML Hell
http://www.flickr.com/photos/19703909@N00/3411843177

Using DHTML (JavaScript
controlling visual changes in
the document) we went nuts.

Moving and scrolling and
JavaScript dependent
navigations.

Blink, Flicker, Crash.

The biggest issue was that we
tried to support every
browser the same way.

Which is why one group stood
up and put a stake in the
ground.

WaSP – to hell with bad browsers.

The work of the WaSP and
many individual trainers,
writers and developers made
web standards a good idea to
follow and understand.

Which made a lot of sense.

As the first .com bubble
collapsed people spent much
less money on silly web sites.

Instead, they wanted easy to
maintain, extend and change
web sites.

This meant also that people
didn’t want JavaScript
solutions any more.

We did our best to make
people understand that –
used the right way –
JavaScript is not evil.

Unobtrusive JavaScript

http://icant.co.uk/articles/seven-rules-of-
unobtrusive-javascript/
http://www.zhuoqun.net/html/y2008/1103.html

However, the painful
memories of DHTML hell were
still hard to forget.

Until the next revolution
came.

var request;
try{
request = new XMLHttpRequest();
AJAX }catch(error){
try{
request = new ActiveXObject(\"Microsoft.XMLHTTP\");
}catch(error){
return true;
}
}
request.open('get',this.href,true);
request.onreadystatechange=function(){
if(request.readyState == 1){
output.innerHTML='loading...';
}
if(request.readyState == 4){
if (request.status && /200|304/.test(request.status))
{
retrieved(request);
} else{
failed(request);
}
}
}

Ajax meant that web sites are
fast, easy to use and highly
interactive.

And it works by using
JavaScript.

The new interest in JavaScript
helped us go out to the world
and tell it how you can use
JavaScript together with web
standards and create
amazing experiences.

To make this work, we
needed a buzzword for “new
JavaScript”

DOM Scripting

However, the idea of
unobtrusive scripting and
web standards development
became a bit forgotten
because of yet another
revolution.

WEB 2.0
http://www.flickr.com/photos/brownpau/198591442/

WEB 2.0 meant that users are
creating the web they use.

Everything had to be highly
interactive and Ajax is not
even a nice-to-have but a
main goal.

So this is where we are.

The mess we have to deal with.
http://www.flickr.com/photos/28114609@N05/3433642297

The Ajax revolution and the
Web 2.0 move set high
expectations.

Users expect web sites to be
highly responsive and
working like real
applications.

However, we are still working
in browsers and on the web.

Ajax driven web sites do not
reload the whole document.

This breaks a lot of things.

No bookmarking.
No back button.
No interaction with
assistive technology.

To make our products work,
we need to know a lot of
things:

the technologies
how browsers fail
supporting them
how users interact with
systems
what people use

The problem is that most
likely you won’t have the
time to do all that.

The other problem is that as
individuals we are likely to
find solutions for our
problems but not for all of the
possible ones.

For this, we need to
collaborate and compare our
findings.

We also need to be careful
not to repeat the mistakes of
the past.

Working on a solid base

It is not about technology.

You do not work to satisfy
browsers.

Standards only make sense
when they offer an easier
way of achieving a goal and if
they have support in the real
world.

As a developer, you should
work first and foremost for
the user of your products.

The second most important
person to work for is the
developer that takes over
from you.

The easier the
interface, the
more people will
use it.

In order to make web
development a professional
choice we need to act like
professionals.

This means that instead of
getting excited about hacks
and quick solutions we should
concentrate on other goals.

Does it work for everybody?
Is it easy to change?
Is it a smooth experience?
Does it make it easier for
users to do what they want
to do?

Here’s the good news: we are
almost there.

Web development libraries
like jQuery, prototype,
mootools, Dojo, YUI... are
there to help you do your job.

These libraries are all open
for you to feed back problems
and contribute solutions.

They are a much sturdier base
to build on than browsers and
their current documentation.

One base to work from is YUI:

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

The Yahoo User Interface
library was build to make it
easier for Yahoo developers
to build our products.

Working with as many
locations, products and
people as Yahoo does it is the
only way to keep a constant
high quality.

With that many developers at
hand we were able to build a
great library based on solid
principles.

When we build products, we
test them with users and see
what they want.

Analyzing this we came up
with usage patterns, which
are available to you.

http://developer.yahoo.com/ypatterns

They even come with stencils
for your designers.

http://developer.yahoo.com/ypatterns/wireframes/

One thing we needed to do is
to define what browsers to
support and what “support”
means.

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

Support is not giving every
browser the same
experience.

It means using what the
browser can reliably do and
not making it reach what it
cannot do.

This is the main principle of
progressive enhancement.

We must build products that
work, and only work more
smoothly when the browser
in use allows for it.

Without JavaScript With JavaScript
http://developer.yahoo.com/yui/examples/autocomplete/ac_basic_array_clean.html

Without JavaScript
With JavaScript
http://developer.yahoo.com/yui/examples/datatable/dt_enhanced.html

We used the design pattern
information and built widgets
that work this way.

We test them across the
supported browsers to make
sure they work.

http://ui.jquery.com/
http://ui.jquery.com

Using these, you can build
applications that work across
all the browsers supported by
the GBS.

We provide the bricks,
you build the product.
http://www.flickr.com/photos/seven13avenue/2080281038/

All of the widgets can be
extended and styled the way
you want them to.

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

You can extend the widgets
by listening for events that
happen to them.

http://developer.yahoo.com/yui/examples/autocomplete/
ac_basic_xhr_log.html

If you don’t want to use the
widgets, you can use the
helper libraries that we use to
build the widgets.

These do the same thing, but
on a code level. They make
web standards work across
browsers (DOM support,
event handling).

If all you need is creating CSS
layouts that work across
browser land, there’s that,
too.

Even for *very* lazy developers:
http://developer.yahoo.com/yui/grids/builder/

One other thing we do is
make web development less
random by providing testing
tools.

All of this is open source, fully
documented and you can
either host it yourself or get it
from a high speed distributed
network (even Google’s).

Practices we follow:
Progressive enhancement
Standards compliance
Code validation (JSLint)
Extensibility
Modularisation
Documentation

Even if you don’t want to use
anything we offer, these are
good ideas to use in your
work.

Don’t become a part of the
group of developers that
leave behind unmaintainable
products.

Another thing to consider is
how your products perform.

Fast and smooth products
make users happy.

There’s a lot of good
information available at the
exceptional performance site.

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

All of which can be tested
using YSlow.
http://developer.yahoo.com/yslow/

One final thing we’re working
on a lot is accessibility.
http://yuiblog.com/blog/category/accessibility/

This is all I have time for
today, so thanks again.
Check out the bookmarks on
the last page for lots of good
tutorials and documents.

Two of mine were even translated:
http://www.cn-cuckoo.com/2007/08/14/unobtrusive-javascript-progressive-
enhancement-gracefully-degrade-82.html

Two of mine were even translated:
http://www.zhuoqun.net/html/y2008/1103.html

THANKS!
Christian Heilmann
http://icant.co.uk
http://wait-till-i.com
http://scriptingenabled.org
http://twitter.com/codepo8
http://delicious.com/codepo8/taiwantrip