0
The road to
professional web
development




     Christian Heilmann | http://icant.co.uk | http://wait-till-i.com
       ...
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 docu...
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=quot;500quot; border=quot;0quot;>
  <tr>
    <td width=quot;1quot; bgcolor=quot;blackquot;><img src=quot;spac...
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...
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.h...
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...
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
stan...
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
rev...
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 ...
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 t...
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...
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
n...
Practices we follow:
  Progressive enhancement
  Standards compliance
  Code validation (JSLint)
  Extensibility
  Modular...
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 an...
Two of mine were even translated:




http://www.cn-cuckoo.com/2007/08/14/unobtrusive-javascript-progressive-
enhancement-...
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/c...
The road to professional web development
The road to professional web development
Upcoming SlideShare
Loading in...5
×

The road to professional web development

5,684

Published on

My presentation in Taiwan about the history of web development and what practices make sense and got followed in the YUI.

Published in: News & Politics, Technology
0 Comments
30 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
5,684
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
541
Comments
0
Likes
30
Embeds 0
No embeds

No notes for slide

Transcript of "The road to professional web development"

  1. 1. The road to professional web development Christian Heilmann | http://icant.co.uk | http://wait-till-i.com Taipeh, Taiwan, April 2009
  2. 2. Hello and thank you for being here.
  3. 3. I am Chris...
  4. 4. ...and today I will talk about the road to professional web development.
  5. 5. You cannot look forward without learning from the mistakes of the past.
  6. 6. Otherwise you are very likely to repeat them.
  7. 7. So let’s take a look at the past of web development.
  8. 8. The Dark Ages http://www.flickr.com/photos/25725360@N05/2929959881
  9. 9. In the beginning there was HTML.
  10. 10. It structured text into headings, lists and paragraphs and linked documents with each other using anchors.
  11. 11. This was good, and quite a revolution...
  12. 12. ...but also very, very boring.
  13. 13. People wanted colours, different types of text, borders and images.
  14. 14. Which lead to the next step.
  15. 15. The first mistake: Presentational Markup
  16. 16. Adding bgcolor, color, <font>, border, hspace, vspace,float and all other presentational HTML allowed us to style the document.
  17. 17. It doesn’t allow you to style a whole site though.
  18. 18. If the design of the site changes, you needed to change each document of it.
  19. 19. However, as sites were small this was not a problem – yet.
  20. 20. Design was still limited to a single column.
  21. 21. Until people realised that you can use the <table> element to create multi-column layouts.
  22. 22. And it was *so* easy.
  23. 23. ..if you knew all the problems that different browsers have with showing the table properly.
  24. 24. <table width=quot;500quot; border=quot;0quot;> <tr> <td width=quot;1quot; bgcolor=quot;blackquot;><img src=quot;spacer.gifquot; width=quot;1quot; height=quot;1quot; alt=quot;quot;></td> <td width=quot;10quot; bgcolor=quot;blackquot;><img src=quot;spacer.gifquot; width=quot;10quot; height=quot;1quot; alt=quot;quot;></td> <td width=quot;118quot; bgcolor=quot;blackquot;><img src=quot;spacer.gifquot; width=quot;118quot; height=quot;1quot; alt=quot;quot;></td> <td width=quot;10quot; bgcolor=quot;blackquot;><img src=quot;spacer.gifquot; width=quot;10quot; height=quot;1quot; alt=quot;quot;></td> <td width=quot;300quot; bgcolor=quot;blackquot;><img src=quot;spacer.gifquot; width=quot;350quot; height=quot;1quot; alt=quot;quot;></td> <td width=quot;10quot; bgcolor=quot;blackquot;><img src=quot;spacer.gifquot; width=quot;10quot; height=quot;1quot; alt=quot;quot;></td> <td width=quot;1quot; bgcolor=quot;blackquot;><img src=quot;spacer.gifquot; width=quot;1quot; height=quot;1quot; alt=quot;quot;></td> </tr> <tr> <td width=quot;1quot; rowspan=quot;3quot; bgcolor=quot;blackquot;><img src=quot;spacer.gifquot; width=quot;1quot; height=quot;1quot; alt=quot;quot;></td> <td width=quot;1quot; rowspan=quot;2quot;><img src=quot;spacer.gifquot; width=quot;10quot; height=quot;10quot; alt=quot;quot;></td> <td width=quot;1quot; colspan=quot;3quot;><img src=quot;spacer.gifquot; width=quot;1quot; height=quot;10quot; alt=quot;quot;></td> <td width=quot;1quot; rowspan=quot;2quot;><img src=quot;spacer.gifquot; width=quot;10quot; Navigation Content height=quot;10quot; alt=quot;quot;></td> <td width=quot;1quot; rowspan=quot;3quot; bgcolor=quot;blackquot;><img src=quot;spacer.gifquot; width=quot;1quot; height=quot;1quot; alt=quot;quot;></td> </tr> <tr> <td>Navigation</td> <td></td> <td>Content</td> </tr> <tr> <td colspan=quot;5quot;><img src=quot;spacer.gifquot; width=quot;1quot; height=quot;10quot; alt=quot;quot;></td> </tr> <tr> <td rowspan=quot;7quot;><img src=quot;spacer.gifquot; width=quot;1quot; height=quot;1quot; alt=quot;quot;></td> </tr> </table>
  25. 25. Also: what do you need to do when the navigation has to move to the right?
  26. 26. The solution was to separate the presentation from the structure.
  27. 27. CSS
  28. 28. CSS allowed you to define the look and feel in a much more detailed manner.
  29. 29. CSS is defined once and applied to as many documents as you want.
  30. 30. So moving a navigation meant changing a single file.
  31. 31. However, the problem was that developers wanted more and more and the standards took too long to agree on.
  32. 32. Browser Wars http://www.flickr.com/photos/7189565@N07/3279178176
  33. 33. As browser makers were in fierce competition this lead to non-standard extensions to both HTML and CSS.
  34. 34. This, together with more and more support for JavaScript in browsers lead to another dark period of web development.
  35. 35. DHTML Hell http://www.flickr.com/photos/19703909@N00/3411843177
  36. 36. Using DHTML (JavaScript controlling visual changes in the document) we went nuts.
  37. 37. Moving and scrolling and JavaScript dependent navigations.
  38. 38. Blink, Flicker, Crash.
  39. 39. The biggest issue was that we tried to support every browser the same way.
  40. 40. Which is why one group stood up and put a stake in the ground.
  41. 41. WaSP – to hell with bad browsers.
  42. 42. The work of the WaSP and many individual trainers, writers and developers made web standards a good idea to follow and understand.
  43. 43. Which made a lot of sense.
  44. 44. As the first .com bubble collapsed people spent much less money on silly web sites.
  45. 45. Instead, they wanted easy to maintain, extend and change web sites.
  46. 46. This meant also that people didn’t want JavaScript solutions any more.
  47. 47. We did our best to make people understand that – used the right way – JavaScript is not evil.
  48. 48. Unobtrusive JavaScript
  49. 49. http://icant.co.uk/articles/seven-rules-of- unobtrusive-javascript/ http://www.zhuoqun.net/html/y2008/1103.html
  50. 50. However, the painful memories of DHTML hell were still hard to forget.
  51. 51. Until the next revolution came.
  52. 52. var request; try{ request = new XMLHttpRequest(); AJAX }catch(error){ try{ request = new ActiveXObject(quot;Microsoft.XMLHTTPquot;); }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); } } }
  53. 53. Ajax meant that web sites are fast, easy to use and highly interactive.
  54. 54. And it works by using JavaScript.
  55. 55. 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.
  56. 56. To make this work, we needed a buzzword for “new JavaScript”
  57. 57. DOM Scripting
  58. 58. However, the idea of unobtrusive scripting and web standards development became a bit forgotten because of yet another revolution.
  59. 59. WEB 2.0 http://www.flickr.com/photos/brownpau/198591442/
  60. 60. WEB 2.0 meant that users are creating the web they use.
  61. 61. Everything had to be highly interactive and Ajax is not even a nice-to-have but a main goal.
  62. 62. So this is where we are.
  63. 63. The mess we have to deal with. http://www.flickr.com/photos/28114609@N05/3433642297
  64. 64. The Ajax revolution and the Web 2.0 move set high expectations.
  65. 65. Users expect web sites to be highly responsive and working like real applications.
  66. 66. However, we are still working in browsers and on the web.
  67. 67. Ajax driven web sites do not reload the whole document.
  68. 68. This breaks a lot of things.
  69. 69. No bookmarking. No back button. No interaction with assistive technology.
  70. 70. To make our products work, we need to know a lot of things:
  71. 71. the technologies how browsers fail supporting them how users interact with systems what people use
  72. 72. The problem is that most likely you won’t have the time to do all that.
  73. 73. The other problem is that as individuals we are likely to find solutions for our problems but not for all of the possible ones.
  74. 74. For this, we need to collaborate and compare our findings.
  75. 75. We also need to be careful not to repeat the mistakes of the past.
  76. 76. Working on a solid base
  77. 77. It is not about technology.
  78. 78. You do not work to satisfy browsers.
  79. 79. Standards only make sense when they offer an easier way of achieving a goal and if they have support in the real world.
  80. 80. As a developer, you should work first and foremost for the user of your products.
  81. 81. The second most important person to work for is the developer that takes over from you.
  82. 82. The easier the interface, the more people will use it.
  83. 83. In order to make web development a professional choice we need to act like professionals.
  84. 84. This means that instead of getting excited about hacks and quick solutions we should concentrate on other goals.
  85. 85. 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?
  86. 86. Here’s the good news: we are almost there.
  87. 87. Web development libraries like jQuery, prototype, mootools, Dojo, YUI... are there to help you do your job.
  88. 88. These libraries are all open for you to feed back problems and contribute solutions.
  89. 89. They are a much sturdier base to build on than browsers and their current documentation.
  90. 90. One base to work from is YUI:
  91. 91. http://developer.yahoo.com/yui/
  92. 92. The Yahoo User Interface library was build to make it easier for Yahoo developers to build our products.
  93. 93. Working with as many locations, products and people as Yahoo does it is the only way to keep a constant high quality.
  94. 94. With that many developers at hand we were able to build a great library based on solid principles.
  95. 95. When we build products, we test them with users and see what they want.
  96. 96. Analyzing this we came up with usage patterns, which are available to you.
  97. 97. http://developer.yahoo.com/ypatterns
  98. 98. They even come with stencils for your designers.
  99. 99. http://developer.yahoo.com/ypatterns/wireframes/
  100. 100. One thing we needed to do is to define what browsers to support and what “support” means.
  101. 101. http://developer.yahoo.com/yui/articles/gbs/
  102. 102. Support is not giving every browser the same experience.
  103. 103. It means using what the browser can reliably do and not making it reach what it cannot do.
  104. 104. This is the main principle of progressive enhancement.
  105. 105. We must build products that work, and only work more smoothly when the browser in use allows for it.
  106. 106. Without JavaScript With JavaScript http://developer.yahoo.com/yui/examples/autocomplete/ac_basic_array_clean.html
  107. 107. Without JavaScript With JavaScript http://developer.yahoo.com/yui/examples/datatable/dt_enhanced.html
  108. 108. We used the design pattern information and built widgets that work this way.
  109. 109. We test them across the supported browsers to make sure they work.
  110. 110. http://ui.jquery.com/ http://ui.jquery.com
  111. 111. Using these, you can build applications that work across all the browsers supported by the GBS.
  112. 112. We provide the bricks, you build the product. http://www.flickr.com/photos/seven13avenue/2080281038/
  113. 113. All of the widgets can be extended and styled the way you want them to.
  114. 114. http://developer.yahoo.com/yui/articles/skinning/
  115. 115. You can extend the widgets by listening for events that happen to them.
  116. 116. http://developer.yahoo.com/yui/examples/autocomplete/ ac_basic_xhr_log.html
  117. 117. If you don’t want to use the widgets, you can use the helper libraries that we use to build the widgets.
  118. 118. These do the same thing, but on a code level. They make web standards work across browsers (DOM support, event handling).
  119. 119. If all you need is creating CSS layouts that work across browser land, there’s that, too.
  120. 120. Even for *very* lazy developers: http://developer.yahoo.com/yui/grids/builder/
  121. 121. One other thing we do is make web development less random by providing testing tools.
  122. 122. 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).
  123. 123. Practices we follow: Progressive enhancement Standards compliance Code validation (JSLint) Extensibility Modularisation Documentation
  124. 124. Even if you don’t want to use anything we offer, these are good ideas to use in your work.
  125. 125. Don’t become a part of the group of developers that leave behind unmaintainable products.
  126. 126. Another thing to consider is how your products perform.
  127. 127. Fast and smooth products make users happy.
  128. 128. There’s a lot of good information available at the exceptional performance site.
  129. 129. http://developer.yahoo.com/performance/
  130. 130. All of which can be tested using YSlow. http://developer.yahoo.com/yslow/
  131. 131. One final thing we’re working on a lot is accessibility. http://yuiblog.com/blog/category/accessibility/
  132. 132. 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.
  133. 133. Two of mine were even translated: http://www.cn-cuckoo.com/2007/08/14/unobtrusive-javascript-progressive- enhancement-gracefully-degrade-82.html
  134. 134. Two of mine were even translated: http://www.zhuoqun.net/html/y2008/1103.html
  135. 135. THANKS! Christian Heilmann http://icant.co.uk http://wait-till-i.com http://scriptingenabled.org http://twitter.com/codepo8 http://delicious.com/codepo8/taiwantrip
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×