3. THE WEB AS A
PLATFORM WE
DREAMED UP IS
BASED ON A FEW
BEAUTIFULLY SIMPLE
PRINCIPLES…
✓ Maintainability
✓ Accessibility
✓ Predictability
✓ Flexibility
✓ Extensibility
4. THESE PRINCIPLES
HAVE ALWAYS BEEN
CHALLENGED…
✘ Products don’t start as service
ideas or content, but as visuals
✘ A false belief in “this should look
the same everywhere”
✘ A flawed comparison with more
defined, specialised
environments.
✘ “We don’t have time for you to
craft - just release this thing and
we’ll fix it later”
5. THE BIGGER
PROBLEM IS THAT WE
HAVE INTERNALISED
THESE CHALLENGES.
? Do we need to release more and
faster all the time?
? Are we OK with building and
discarding everything we do over
and over again?
? Are we just plumbers of the web,
or is it time to call the shots?
7. EVERY WEEK OR SO THERE WE
HAVE SOME NEW, INCREDIBLE TECH
TO PLAY WITH…
• Web Components
• Service Workers
• ECMAScript 2015/16…
• WebVR/WebGL/WebRTC
10. INCREDIBLE?
• Everything these days is experimental
• Many things need non-standard code
or flags to be turned on
• Things work only in one browser,
sometimes even a special build
11. IMPATIENCE AND
ABSTRACTION
• To make things work, we write
abstraction libraries
• To make these more reusable, we
base them on other libraries,
packages and frameworks
• Almost every single one of these
comes with a long web site,
documentation, a cool logo, a one
day hype on hacker news and a
“don’t use this in production” label.
13. SO, WHO DO WE
INNOVATE FOR IF WE
CAN’T USE IT IN
PRODUCTION?
?
14. WE HAVE GREAT
JOBS, WE SHOULDN’T
FEEL UNHAPPY OR
STRESSED…
• Things do not burn when we make
mistakes
• The environment we work in flows
like water, there is a constant need
for new ideas
• We need to be the masters of
uncertainty
• We work in a publication medium,
not a software platform
15. IT IS TIME TO BE
MORE RESPONSIBLE
FOR OUR WORK.
✔
16. ALWAYS QUESTION
AUTHORITY.
• Browser innovation
• Standards not implemented in
browsers
• Magical abstractions
• Impressive looking tool chains and
development packages
21. THE IDEA WAS TO GET
RID OF ALL THE BAD
IDEAS OF THE PAST…
✘ VML
✘ attachEvent()
✘ currentStyle
✘ X-UA-Compatible (render modes)
✘ IE Layout Quirks
✘ VBScript
✘ Conditional Comments
✘ MS-Prefixed Events
26. before
after
before
after
-webkit-appearance: none -webkit-gradient
EXPERIMENTAL? PROBABLY SAFE TO USE…
27. THINGS YOU LEARN WHEN YOU WRITE A NEW JS
ENGINE
https://channel9.msdn.com/events/WebPlatformSummit/2015/Chakra-The-
JavaScript-Engine-that-powers-Microsoft-Edge
@BTERLSON
@GAURAVSETH
28. THINGS YOU LEARN
WHEN YOU WRITE A
NEW JS ENGINE
✘ Only a third of the top 3000 sites
can benefit from JS inlining.
Reason is lots of scripts instead
of concatenation.
✘ You need to optimise a lot of JS in
the engine (length reading on
every iteration of for loops!)
✘ Outdated libraries are still very
much in use and clash with new
JS features (mootools breaking
with array.contains(), zepto
disliking array constructors)
✓ Minification is used a lot on the
web and optimising for uglify.js
code is a big win
29. THINGS I LEARNED
WORKING FOR
BROWSER MAKERS
✓ It is a constant race not to break the
web - every mistake web developers
make needs to get catered for.
✓ The pressure is immense. Instead of
pushing for an interoperable web,
browsers are constantly compared
and expected to be different.
✓ When implementing standards, we
find a lot of problems and feed them
back. That’s why a score of 100% in
feature tests makes no sense.
✓ Most speed increases are based on
analysing and fixing developer
mistakes/sloppiness.
31. AND WE NEED TO
CONCENTRATE ON
GETTING ONE THING
RIGHT…
32. • Arrow functions as a short-hand version of an
anonymous function.
• Block-level scope using let instead of var makes
variables scoped to a block (if, for, while, etc.)
• Classes to encapsulate and extend code.
• Constants using the const keyword.
• Default parameters for functions like foo(bar = 3, baz =
2)
• Destructuring to assign values from arrays or objects
into variables.
• Generators that create iterators using function* and
the yield keyword.
• Map, a Dictionary type object that can be used to store
key/value pairs. and Set as a collection object to store
a list of data values.
• Modules as a way of organizing and loading code.
• Promises for async operations avoiding callback hell
• Rest parameters instead of using arguments to access
functions arguments.
• Template Strings to build up string values including
multi-line strings.
ES6 COMES WITH
SO MUCH
GOODNESS,
TECHNICALLY IT
HAS TO BE
FATTENING…
33. Library Builders
map, set & weakmap
__proto__
Proxies
Symbols
Sub7classable built7ins
Scalable Apps
let, const & block7
scoped bindings
Classes
Promises
Iterators
Generators
Typed arrays
Modules
Syntactic Sugar
Arrow functions
Enhanced object literals
Template strings
Destructuring
Rest, Spread, Default
String, Math, Number,
Object, RegExp APIs
ALL OF THESE PARTS HAVE DIFFERENT AUDIENCES
37. IF YOU WANT TO USE
IT ALL: TRANSPILING
INTO ES5…
https://babeljs.io
38. ✘ It adds an extra step in between
writing code and running it in the
browser - probably the thing that
made the web grow as fast as it
did.
✘ You don’t run or debug the code
you write.
✘ You’re at the mercy of the
transpiler to create efficient code
✘ You create probably much more
code than you need
✘ Browsers that support ES6 will
never get any.
THE PROBLEMS WITH
TRANSPILING:
39. HOW DOES ES6 PERFORM? http://kpdecker.github.io/six-speed/
44. THE ES6
CONUNDRUM:
• We can’t use it safely in the wild
• We can use TypeScript or transpile it
• We can feature test for it, but that
can get complex quickly
• Browsers that support it, will not get
any ES6 that way (but can use it
internally)
• The performance is bad right now
(which is a normal thing). To improve
this, we need ES6 to be used in the
wild…
45. HELP ES6 BY
LOOKING AT ITS
UNIT TESTS…
https://github.com/tc39/test262
http://test262.ecmascript.org/
47. LET’S GO BACK TO A
GOOD PRINCIPLE OF
HTML5 DESIGN
http://www.w3.org/TR/html-design-principles/#priority-of-constituencies
In case of conflict, consider users
over authors over implementors
over specifiers over theoretical
purity. In other words costs or difficulties to
the user should be given more weight than
costs to authors; which in turn should be
given more weight than costs to
implementors; which should be given more
weight than costs to authors of the spec
itself, which should be given more weight
than those proposing changes for theoretical
reasons alone. Of course, it is preferred to
make things better for multiple constituencies
at once.
PRIORITY OF CONSTITUENCIES
“
48. WE LIVE ON TOO MANY
EMPTY PROMISES
• Tooling will save us in lots of cases, but we
shouldn’t have to counter bad decisions of
the past with more code
• It is great and necessary that browsers
innovate at different speeds , but unless
that innovation lands in all of them, it is
dangerous to use.
• Not everything that solves a problem has
to become a generic solution. Going
generic always comes with bloat.
49. WE WON’T ACHIEVE MUCH
WITH PUNISHMENT
• Our end users should never have to
change their environment because of
our code (other reasons, of course,
apply)
• Blaming the tool is a sign of a bad
craftsman, good craftsmen improve
the tools by feeding back to the tool
maker
• It is not your fault, you’re not too
stupid, we just like to show off too
much
51. LOVE RESPONSIBLY…
• Everything you do is for your end users - great
UX is invisible, so should our code issues
• What you use and makes you happy is not
what others have - consider yourself lucky, not
better
• If you love the web, keep it clean - remove
outdated code, keep helper tools up-to-date
• It is people like you who created the things that
annoy you - explain your issue, ask for reasons,
and you’ll see fixes
• Good things take time - let’s slow down our
pace and build better, not faster.
52. THANK YOU!
CHRIS HEILMANN
@CODEPO8
Selfie Stick group: j0sh (www.pixael.com)
https://www.flickr.com/photos/87690240@N03/16322726941/
Stick and Carrot: Alan O’Rourke
https://www.flickr.com/photos/33524159@N00/17233999165
Skip by Denna Jones
https://www.flickr.com/photos/95267793@N00/2336623192
Stick, Carrot and heart: opensourceway
https://www.flickr.com/photos/47691521@N07/5537457133/
