Here are the slides from my talk at @media in London two weeks ago titled "Professional Frontend Engineering." I had four goals for the talk. Put a stake in the ground. Reiterate our values. Advocate the discipline. Nurture a healthy Web. The goals were threaded throughout the four sections of the talk:: Historical Perspective Our Beliefs & Principles Knowledge Areas & Best Practices Why It All Matters The professionalization of frontend engineering is a topic I'm passionate about. I think it is critical to the advancement of the Internet. Presented May 30th, 2008, in London at the @media conference in the plenary opening day two.

1. Professional Frontend
Engineering
Nate Koechley
Senior Frontend Engineer
Yahoo!
natek@yahoo-inc.com | developer.yahoo.com/yui
nate.koechley.com/blog | “natekoechley”

2. Why this topic?

4. • Put a stake in the
ground.
• Reiterate our
values.
• Advocate the
discipline.
• Nurture a healthy
Web.

7. Historical
Perspective

8. Historical Our Beliefs
Perspective & Principles

9. Historical Our Beliefs
Perspective & Principles
Knowledge
Areas & Best
Practices

10. Historical Our Beliefs
Perspective & Principles
Knowledge
Why It All
Areas & Best
Matters
Practices

11. Historical
Perspective

19. Year = 2001

20. Age = 7 years

21. Employees = 3000

22. Frontend
Engineers = 0

23. So?

24. 2001
First frontend engineering
specialists hired.

25. 2008
~700 professional frontend
engineers spread across
Y! offices worldwide.
And hiring!!!

26. 2001
Font tags & nested tables.
Static interface.

27. 2008
Semantic & accessible markup.
Rich DHTML & Ajax behavior.
More content. Same fast speed.

28. 2001
Available and accessible to
everyone.

29. 2008
Available and accessible to
everyone.

30. 2001
Plain but predictable.

31. 2008
Highly visual and adaptive, but
still dependable.

32. 2001
Modest user expectations.

33. 2008
Sophisticated, broad, and
non-trivial user expectations.

34. 2001
Intersection of design and
development still vague.

35. Now
Professional Frontend
Engineers focused at the
intersection of design and
development is a best practice.

36. —Irene Au, SVP of UED at Yahoo!

37. “In 2001, with developments in advanced
JavaScript and DHTML, we knew the web
experience would evolve beyond the static
pages we were producing. We brought in web
developers to help us pioneer Yahoo’s offerings
to include a more dynamic, interactive
experience for our users.”
—Irene Au, SVP of UED at Yahoo!

38. —Irene Au, SVP of UED at Yahoo!

39. “... Another motivation was to bring in a
disciplined frontend programming
practice to Yahoo. Before then, the
presentation, behavior, and structure of
our pages were not separate, which led
to many challenges and inefficiencies in
designing and developing our products.”
—Irene Au, SVP of UED at Yahoo!

42. “The Framers of the Web
saw browser differences
as beneficial and believed
that visitors should
choose how their browser
displays the page...”

44. “...I wanted more control
so I threw my HTML
book in the trash and
started from scratch.”

45. The Web is
still sick.

46. Frontend Engineers are
the Web’s Radiologists

47. Question:
What is Frontend
Engineering?

48. Answer:
We write software
in JavaScript, CSS,
and HTML & more...

49. Answer:
We tell browsers
what to do.

50. Answer:
We’re responsible
for “view source”

51. The Yahoo! Stack
Pages & modules
95% HTML, 5% PHP
Display logic & APIs
50% HTML, 50% PHP
Specific PHP biz logic
90% PHP, 10% Text
Generic PHP functions & libs
100% PHP
C/C++ Libraries.
90% C/C++, 10% PHP

52. The Yahoo! Stack
Pages & modules
Frontend
95% HTML, 5% PHP
Display logic & APIs
50% HTML, 50% PHP
Specific PHP biz logic
90% PHP, 10% Text
Generic PHP functions & libs
100% PHP Backend
C/C++ Libraries.
90% C/C++, 10% PHP

53. The Yahoo! Stack
Pages & modules
Frontend
95% HTML, 5% PHP
Display logic & APIs
50% HTML, 50% PHP
Specific PHP biz logic
90% PHP, 10% Text
Generic PHP functions & libs
100% PHP Backend
C/C++ Libraries.
90% C/C++, 10% PHP

54. SIMPLE?

55. no.

56. server

57. (X)HTML
server

58. (X)HTML
Specification
server

59. (X)HTML
Specification
Implementation
server

60. (X)HTML
Specification
Implementation
Bugs
server

61. (X)HTML
Specification
Implementation
Bugs
[ Theory / Practice ]
server

62. CSS
BOM API
(X)HTML DOM JavaScript
DOM API
Specification
Data Transport
data: custom, xml,
mixed: new xhtml
Implementation
json
behavior: js
Bugs
[ Theory / Practice ]
server

63. Safari Firefox Opera IE5, 6, 7 Firefox Opera 10,000+ UAs
Macintosh Windows Linux, Unix, Mobile
CSS
BOM API
(X)HTML DOM JavaScript
DOM API
Specification
Data Transport
data: custom, xml,
mixed: new xhtml
Implementation
json
behavior: js
Bugs
[ Theory / Practice ]
server

64. Safari Firefox Opera IE5, 6, 7 Firefox Opera 10,000+ UAs
Macintosh Windows Linux, Unix, Mobile
CSS
BOM API
(X)HTML DOM JavaScript
DOM API
Specification
data: custom, xml,
mixed: new xhtml,
Data Transport
Implementation
behavior: js
json
Defects
[ Theory / Practice ]
server

65. Safari Firefox Opera IE5, 6, 7 Firefox Opera 10,000+ UAs
Macintosh Windows Linux, Unix, Mobile
knowledge areas: 7
CSS
(X)HTML
dimensions: xJavaScript
DOM
4 BOM API
DOM API
platforms: x 3
Specification
data: custom, xml,
mixed: new xhtml,
browsers perDefects platform: x 4
Data Transport
Implementation
behavior: js
json
rendering modes: x 2
[ Theory / Practice ]
server
=672

67. usability, internationalization,
localization, visual design,
accessibility, information
architecture, security, build
processes, performance,
benchmarking, devices, portability

68. from Lifted
©2007 Pixar Animation Studios

69. Different from Backend
because we:
• Can’t compile.
• Can’t trust.
• Can’t predict.
• Can’t install or store.
• Can’t hide anything!

70. Douglas Crockford on browsers:
“The most hostile
software development
environment imaginable.”

71. If your business is online...
your value depends on
Frontend Engineering.

72. Elegant algorithms benefit users
through interfaces built by
Frontend Engineers.

73. Every gorgeous design is
brought to life by Frontend
Engineers.

74. Frontend engineers give sites
strength & resilience,
appearance & form, and
functionality & interactivity.

75. ...which is why professional
frontend engineering is
critical for success.

76. Historical Our Beliefs
Perspective & Principles

77. Four Guiding Principles

78. 1) Availability

79. Availability:
Maximize availability, accessibility
and utility of content and services
for all users worldwide.

80. 2) Openness

81. Openness:
Share. Learn. Support. Advocate.
We benefit from a healthy Internet.

82. 3) Richness

83. Richness:
Provide, but not too much.
Layer endlessly.
Remember we are not average.

84. 4) Stability

85. Stability:
The Web is young.
Invest in quality.
Prepare for the future.

86. Four Guiding Principles
• Availability
• Openness
• Richness
• Stability

87. Three Core Techniques

88. 1) Graded Browser
Support
http://developer.yahoo.com/yui/articles/gbs/

89. “Support” does not
mean identical.

90. “Support” is not a
binary choice.

91. Three Support Grades

92. Three Support Grades
C-Grade
• Blacklist (of incapable browsers)
• Withhold CSS & JavaScript

93. Three Support Grades
C-Grade
• Blacklist (of incapable browsers)
• Withhold CSS & JavaScript
A-Grade
• Whitelist (of capable browsers tested)
• Serve CSS & JavaScript

94. Three Support Grades
C-Grade
• Blacklist (of incapable browsers)
• Withhold CSS & JavaScript
A-Grade
• Whitelist (of capable browsers tested)
• Serve CSS & JavaScript
X-Grade
• Everybody else.
• Serve CSS & JavaScript

95. A-Grade Support
http://developer.yahoo.com/yui/articles/gbs

96. C-Grade Experience

97. A-Grade Experience

98. C-Grade Experience

99. A-Grade Experience

100. 2) Progressive
Enhancement

101. Rules of Progressive
Enhancement

102. Rules of Progressive
Enhancement
• Enrich content with thorough, explicit markup.

103. Rules of Progressive
Enhancement
• Enrich content with thorough, explicit markup.
• Test core functionality with HTML only.

104. Rules of Progressive
Enhancement
• Enrich content with thorough, explicit markup.
• Test core functionality with HTML only.
• Enhance layout via externally linked CSS.

105. Rules of Progressive
Enhancement
• Enrich content with thorough, explicit markup.
• Test core functionality with HTML only.
• Enhance layout via externally linked CSS.
• Enhance behavior via externally linked
unobtrusive JavaScript.

106. Rules of Progressive
Enhancement
• Enrich content with thorough, explicit markup.
• Test core functionality with HTML only.
• Enhance layout via externally linked CSS.
• Enhance behavior via externally linked
unobtrusive JavaScript.
• Respect end-user browser preferences.

107. Flipped definition of
“graceful degradation”

108. 3) Unobtrusive JavaScript
http://onlinetools.org/articles/unobtrusivejavascript/

109. Rules of Unobtrusive
JavaScript

110. Rules of Unobtrusive
JavaScript
• No JavaScript in HTML documents.

111. Rules of Unobtrusive
JavaScript
• No JavaScript in HTML documents.
• Don’t depend on or trust JavaScript.

112. Rules of Unobtrusive
JavaScript
• No JavaScript in HTML documents.
• Don’t depend on or trust JavaScript.
• Poke objects before using them.

113. Rules of Unobtrusive
JavaScript
• No JavaScript in HTML documents.
• Don’t depend on or trust JavaScript.
• Poke objects before using them.
• Write JavaScript, not dialects.

114. Rules of Unobtrusive
JavaScript
• No JavaScript in HTML documents.
• Don’t depend on or trust JavaScript.
• Poke objects before using them.
• Write JavaScript, not dialects.
• Mind your manners with vars & scope.

115. Rules of Unobtrusive
JavaScript
• No JavaScript in HTML documents.
• Don’t depend on or trust JavaScript.
• Poke objects before using them.
• Write JavaScript, not dialects.
• Mind your manners with vars & scope.
• Support multiple event triggers.

116. Don’t Break the Web!
href=“#”
href=“javascript:foo()”
onclick=“foo()”

117. Three Core Techniques
• Graded Browser
Support
• Progressive
Enhancement
• Unobtrusive
JavaScript

118. Making Decisions

119. Making Decisions (1)
1. Do what is standard.
if impossible, then:
2. Do what is common.
if impossible, then:
3. Do what it takes.

120. Making Decisions (2)
1. Do what is simple.
✚
2. Do what is flexible & progressive.
✚
3. Do what is open.

121. Making Decisions (3)
• Remember you have multiples
audiences to satisfy:
• Users
• Developers
• Machines

122. Historical Our Beliefs
Perspective & Principles
Knowledge
Areas & Best
Practices

123. 8 Areas of Focus
1. HTML 6. Performance
2. CSS 7. Infrastructure &
Process
3. JavaScript
8. Tooling
4. Accessibility
5. Internationalization

124. oc us
F
#1
HTML

125. Focus: Be thorough.

126. <label>

127. <fieldset>

128. <cite>

129. <caption>

130. <thead>

131. <th scope=”row” abbr=”ManU”>

132. <ins datetime=”2008-05-30”>

133. Aim for permanence.

134. Switching costs
are rising.

135. oc us
F
#2
CSS

136. Focus on the left side.

137. selector: declaration;

138. selector: declaration;

139. Focus: Specificity
great selectors are an
expression of professionalism

140. h1: declaration;

141. #mod h1: declaration;

142. div#mod h1: declaration;

143. body.cart #mod h1.class a:
declaration;

144. #mod ul li li: declaration;

145. Focus: Maintenance
think about how sites age

146. oc us
F
#3
JavaScript

147. JavaScript
• Quality
• Security

148. 1) Quality

149. Linting
• Use programs like JSLint (jslint.org) to
confirm the quality of your code.
• Adopt the idioms it promotes to improve
your code quality.

150. Unit Testing w/ YUI Test
• Rapid creation of test cases via simple syntax.
• Advanced failure detection for methods that
throw errors.
• Grouping of related test cases using test suites.
• Asynchronous tests for testing events and Ajax
communication.
• DOM Event simulation in all A-grade browsers.

151. Profiling
• Learn where to improve your code.
• Programmatically retrieve profiling
information as the application is running.
• Determine unit-testing success based on
profiling results.

152. JavaScript Pollution
• Do not mutate JavaScript itself.
• Do protect yourself from browsers.
• Minimize touchpoints between authors and
vendors so vendors can iterate faster.

153. 2) Security

154. JavaScript Security
• Beware of XSS
• Never Trust Data from the Client
• Monitor AdSafe/Caja Developments

155. oc us
F
#4
Accessibility

156. ARIA

157. Decoupled Events

158. oc us
F
#5
Internationalization

159. Begin serving all .css
and .js at UTF-8

160. @charset quot;

161. oc us
F
#6
Performance

162. 14 then. 8 more today.

163. <link> not @import
• Because @import
overrides the browsers’
native performance
sequencing.

164. Avoid Redirects
• 3xx status codes – mostly 301 and 302
HTTP/1.1 301 Moved Permanently
Location: http://yahoo.com/newuri
• Cache redirects via Expires headers
• Redirects are worst
form of blocking

165. Use Cookie-Free
Domains For Assets.
• Serving static cacheable assets from a
distinct domains keeps cookies from riding
along with all requests.
yimg.com
images-amazon.com
fbcdn.net

166. Preload Assets

167. Preload Assets
1. Unconditional preload - always w/ onload
Example: google.com’s sprite

168. Preload Assets
1. Unconditional preload - always w/ onload
Example: google.com’s sprite
2. Conditional preload - based on user action
Ex: search.yahoo.com’s Search Assist

169. Preload Assets
1. Unconditional preload - always w/ onload
Example: google.com’s sprite
2. Conditional preload - based on user action
Ex: search.yahoo.com’s Search Assist
3. Anticipated preload - give redesigns a boost

170. Optimize CSS Sprites

171. Optimize CSS Sprites
1. Horizontal alignment is usually smaller than
vertical.

172. Optimize CSS Sprites
1. Horizontal alignment is usually smaller than
vertical.
2. Combine similar colors in a sprite to
minimize color count.
Only 256 colors can fit in a PNG8.

173. Optimize CSS Sprites
1. Horizontal alignment is usually smaller than
vertical.
2. Combine similar colors in a sprite to
minimize color count.
Only 256 colors can fit in a PNG8.
3. Avoid unnecessarily large gaps between
parts of the sprite.

174. GET for Ajax Requests
• POST is a two-step process.
• GET can send in one packet.
• Use if possible, but max payload is 2K in IE.

175. Keep Focusing on Events
1. Event Delegation to reduce total number
2. Don’t always wait for onLoad
• YUI Event has onAvailable,
onContentReady, & onDomReady

176. iPhone Tip
• iPhone will not cache assets larger than 25K
• That’s 25K uncompressed.
• Only 19 total items in cache.
• http://yuiblog.com/blog/2008/02/06/iphone-
cacheability/

177. oc us
F
#7
Infrastructure &
Process

178. Build Process

179. Documentation

180. three versions of each member

181. *.js

182. *-debug.js

183. *-min.js

184. What Is YUI?

185. oc us
F
#8
Tooling

186. Need More Progress.

187. But there’s been some:
• JSLint, JScript Debugger, Firebug, Debug Bar,
Fiddler, Charles, HTTP Live Headers,
DragonFly, Visual Studio 2008
• YUI Logger, YUI Test, and YUI Profiler

188. Historical Our Beliefs
Perspective & Principles
Knowledge
Why It All
Areas & Best
Matters
Practices

189. There’s a lot of
work to be done.

190. We need more
people doing it.

191. The health of the
internet depends on it.

192. The health of our
businesses and passions
depends on it.

193. We must stay vigilant.

194. We must defend users.

195. Go forth with this in
mind:

196. Be Tireless
Trendsetters of Quality
Be active.
Find the way forward.
Educate.

197. Be Belligerent
Gatekeepers of Quality
Do not accept less.
Do not cut corners.

198. Exhibit Stubborn
Empathy for Users
We’re the last line of
defense!

199. Let’s keep talking...
nate@koechley.com
http://nate.koechley.com/blog
“natekoechley”

200. CC Images Used
• http://www.flickr.com/photos/dideo/407360526/sizes/l/
• http://www.flickr.com/photos/jenniferbuehrer/113554568/sizes/l/
• http://www.flickr.com/photos/peteashton/290691658/sizes/l/
• http://www.flickr.com/photos/pedjap/101230548/sizes/o/
• http://www.flickr.com/photos/songtuyuri/2200100451/sizes/o/
• http://www.flickr.com/photos/dominik99/1403329318/sizes/o/
• http://www.flickr.com/photos/cuellar/482993472/sizes/o/

201. nate@koechley.com
http://nate.koechley.com/blog
natekoechley = twitter,
delicious, flickr, tripit, last.fm, linkedin,
fireeagle, friendfeed, ... everywhere.