4. WE’RE SMACK IN THE
MIDDLE OF THIS…
• We live in a market driven by hype
• We work with amazing hardware
• We work with great internet
connectivity
• We get paid very well and assume
everybody else is, too.
5. CONVENIENCE
BREEDS MORE
CONVENIENCE
• Browsers aren’t good enough
• Development environments are not
predictive and do our work for us
• Languages are confusing
• We should have to write less code
and achieve more
Instead of celebrating how lucky
we are, we complain…
6. CONVENIENCE
BREEDS ARROGANCE
• We are not the people who use our
products
• This is the web -‐ you don’t know your
users and you can not tell them what
to use
• We can’t assume that people
upgrade all the time
8. THE WEB IS AN
AMAZING IDEA AND
OFFER…
• Access to information world-‐wide,
24⨉7
• Independent of hardware, software,
ability, or geographical location
• A read/write medium, everybody is
invited to become a creator and not
just a consumer
9. ONE PERSON’S
BEAUTY IS ANOTHER
ONE’S WORRY…
• It is hard to build software and
interfaces for the unknown
• Open distribution, caching and
availability of source code is
anathema to content providers
wanting to protect their content.
10. THE NEXT USERS ARE
NOT THOSE WHO
COMPLAIN THE WEB
IS NOT AS GOOD AS
NATIVE APPS…
https://vimeo.com/139312920
https://brucelawson.github.io/talks/2015/velocity
Bruce Lawson at SOTB 2015
15. http://www.webperformancetoday.com/2015/09/08/deja-vu-all-over-again/
THAT’S A PRETTY
TERRIBLE STATE OF
THE WEB.
• The median page’s time to interact
is 5.5 seconds, and fully loads in just
over 15 seconds.
• The median page is 2MB in size and
contains 170 resources
• Most sites fail to take advantage of
core image optimisation techniques
• A lot is down to advertising and
third party includes (﴾social buttons)﴿
27. AS DEVELOPERS, WE
ARE ASKED TO DO
THE IMPOSSIBLE…
• Make it work the same in every
browser
• Make it easy to maintain and
we want to control everything
• Make sure it is also accessible -‐
I think there’s a law we need to
follow
• Don’t spent too much time on
it -‐ let’s release it now and fix it
later!
28. THE ANSWER IS
ALWAYS JAVASCRIPT
• Javascript is too powerful for its
own good.
• Almost everything that goes
wrong can be controlled and to
a degree fixed with JavaScript
• This leads to people relying on
libraries and frameworks
29. WE USE CODE WE
DON’T UNDERSTAND
TO FIX ISSUES WE
DON’T HAVE…
• Learning libraries and
frameworks beyond “hello
world” costs time and money.
• Time you don’t spend on
looking at optimising your code
• In essence, we value developer
convenience over user
experience.
31. IS DEPENDENCY HELL
A PROBLEM OF THE
TOO PRIVILEGED?
https://www.youtube.com/watch?v=PA139CERNbc
Stephan Bönnemann (﴾JSConfEU 2015)﴿:
Dependency Hell Just Froze Over
50. WE’RE GOING
FULL SPEED ON
INNOVATION…
• Componentised Web
• Extensible Web Manifesto
• WebGL
• WebAssembly/ASM.js
• PostCSS
• Progressive Apps
51. • We work around browser issues
• We make web standards of
tomorrow work today.
• We build solutions to clean up
others and make them smaller
• And each of those comes with
a “don’t use in production”
label.
BUILDING LIBRARIES
AND FRAMEWORKS
THAT MAGICALLY
FIX THINGS HAS
BECOME
FASHIONABLE…
54. FRAMEWORKS
ARE GREAT…
• They are fun to use -‐ achieve a
lot very quickly
• You build complex apps in a
matter of minutes
• They work around pesky
browser bugs
• They are good on your CV
55. …BUT THEY ALSO
COME WITH
DEVELOPER COST
• Learning new frameworks
• Re-‐learning new frameworks
• Debugging frameworks
• Setting up developer
environments
• Cutting down on possible hires/
adding to onboarding time
56. AND WE SHOULD
CONSIDER THE
EFFECTS WE HAVE
ON OUR END
USERS…
• Time to load / execute
• Bandwidth used
• CPU usage
• Frame rate (﴾60 fps)﴿
• Memory usage
• Battery hunger
57. WHAT ABOUT USERS
OF OLD BROWSERS
LIKE IE8 -‐ WE CAN’T
LEAVE THOSE
BEHIND!
#FFD700
78. • 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…
79. 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
80. SUPPORT IS ENCOURAGING (﴾EDGE, FIREFOX, CHROME, SAFARI (﴾ON 9)﴿)﴿
http://kangax.github.io/compat-table/es6/
83. THE SOLUTION: TRANSPILING INTO ES5…
https://babeljs.io
• Converts ES6 to older versions on the server or the client
• In use by Facebook and many others
• Used in editors and tool chains
84. ✘ Extra step between writing code
and running it in the browser.
✘ We don’t run or debug the code
we write.
✘ We hope the transpiler creates
efficient code
✘ We create a lot of code
✘ Browsers that support ES6 will
never get any.
THE PROBLEMS WITH
TRANSPILING:
86. ✘ It is an extra step that might be
costly
✘ We can only do it client-‐side
✘ We can get false positives -‐
experimental features might be
implemented in a rudimentary
fashion
✘ We have to keep your feature
tests up-‐to-‐date and extend them
as needed -‐ support for one
feature doesn’t mean support for
another.
THE PROBLEMS WITH
FEATURE TESTING:
87. YOU CAN USE AN
ABSTRACTION,
FRAMEWORK OR
LIBRARY THAT HAS
SIMILAR FEATURES…
88. 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…
http://www.sitepoint.com/the-‐es6-‐conundrum/
90. BE ACTIVE!
If you use JavaScript in an
environment you control,
please use ES6 and feed
back your experiences to
the browser creators and
the standard bodies.
91. THE JAVASCRIPT
LEARNING PROCESS
HAS ALWAYS BEEN
INTERESTING…
• Use view source to see what
others are doing…
• Copy and paste the bits that
look like they are responsible
for some things
• Change some numbers around
• Run into errors
• Blame Internet Explorer
92. THIS, OF COURSE,
WAS WRONG AND
WE GOT MORE
PROFESSIONAL…
• Search for a solution on
Stackoverflow
• Copy and paste the bits that
look like they are responsible
for some things
• Change some numbers around
• Run into errors
• Blame JavaScript for being
terrible and not a real language
• For good measure, blame
Internet Explorer.
93. WITH ES6 WE HAVE
A CLEAN NEW
SLATE…
(﴾AND YOU CAN’T BLAME IE ANY MORE)﴿
94. SEE THE BABEL.JS DOCS AND TRY IT IN THE BROWSER…
https://babeljs.io/docs/learn-‐es2015/
97. LET’S ANALYSE AND
CLEAN UP.
PUT THE WEB ON A
DIET.
ONE OUTDATED
LIBRARY AT A TIME…
http://dev.modern.ie/tools/staticscan/
https://github.com/MicrosoftEdge/static-‐code-‐scan
98. PLEASE, GO AND
MAKE A BETTER
WEB!
• Analyse the speed of your products
and improve it by simplifying them:
webpagetest.org
• Stop trying to guess what browser is
in use and assume unknown
browsers to be good, not terrible.
• Keep up to date with what browsers
can do: caniuse.com and use it!
• File bugs, report issues, talk to us!