4. THE TECHNOLOGIES WE CAN PLAY
WITH ARE INCREDIBLE!
• Web Components
• Service Workers
• ECMAScript 2015/16…
• WebVR/WebGL/WebRTC
5. WE’VE COME A LONG WAY AS
PROFESSIONAL DEVELOPERS
• Version control
• Test-Driven Development
• Task runners
• Package management
• Pre/Post compilation
• Transpiling
6. OUR TOOLING HAS NEVER BEEN
BETTER…
• IDE Integration
• Watchers/Live Reloads
• In-browser debuggers and
development tools
• Remote debugging tools and
protocols
9. OUR COMMUNICATION TOOLS ARE
SPLENDID
• We all ❤ GitHub
• We all talk on Slack
• We all can access hundreds of free
resources on learning our trade
• We all can take part in meetups or
conferences almost every day - or
on the web.
15. INCREDIBLE?
• Almost everything we release 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
• After impressing one another with a
cool logo, grandiose statements and
a 3 line hello world demo there’s a
fine print stating “don’t use this in
production”
• To use any of the new standards, you
need to use an abstraction library
16. WHO DO WE
CODE FOR?
✘ Not our end users - they are not likely
to have the same computers,
connections and browsers we have
✘ Not companies who need to work
with products that work in large
teams or can be used in an
environment following certification
processes
✔ We code for ourselves, conference
participants, hacker news
commenters, the tech press and an
imaginary, perfect, future audience.
18. WHAT IS THE MAIN THING
WE KEEP TRYING TO FIX
WITH ALL OUR INNOVATION
EFFORTS?
19. MOBILE HAS BEEN SOLD TO
US AND BY US AS
TOTALLY DIFFERENT
• The app is a much better form factor
than web sites with URLs
• Everything needs to work offline
• Speed is paramount and every byte
costs money.
• Everything needs to be much simpler
interfaces - people are busy and on
the road
• Every app should take full advantage
over what the operating system and
hardware offers
25. ON MOBILE, THE
DECK IS STACKED
AGAINST THE WEB…
• Browsers are hard-wired and
update with operating systems
• Hardware creators, service
providers and even third party
vendors fork and release their
own unholy versions of the OS
and the browser.
• The more you control the
experience, the more
competitive you are.
26. DENIAL ANGER BARGAINING DEPRESSION ACCEPTANCE
THE FIVE STAGES OF MOURNING FOR THE OPEN
WEB IN A MOBILE WORLD.
27. DENIAL ANGER BARGAINING DEPRESSION ACCEPTANCE
THE FIVE STAGES OF MOURNING FOR THE OPEN
WEB IN A MOBILE WORLD.
• This is just a fad, it will go away.
• If we build our own operating system based on HTML5, the
others will learn from that and embrace it more.
• Surely the simplicity of web standards and the amazing
value of Microformats and properly structured HTML will
never cease to amaze new developers.
28. DENIAL ANGER BARGAINING DEPRESSION ACCEPTANCE
THE FIVE STAGES OF MOURNING FOR THE OPEN
WEB IN A MOBILE WORLD.
• It is all the fault of our users - they do all the things wrong
like using outdated browsers or turning off JavaScript!
• It is the fault of browser makers - they just don’t innovate
quickly enough to match what mobile can do!
• It is the fault of clients - they only want crap and nothing
exciting that pushes the envelope!
• It is the fault of tool creators - we need to match what native
has in terms of tooling and then we all can ride unicorns
and have ice cream!
29. DENIAL BARGAINING DEPRESSION ACCEPTANCE
THE FIVE STAGES OF MOURNING FOR THE OPEN
WEB IN A MOBILE WORLD.
• Let’s build a stop phone gap solution - one that is designed
to become redundant to show mobile OS makers that the
web is ready if only it had access to hardware capabilities.
• Let’s define lots of APIs and form expert groups - surely
these will be embraced an implemented by OS providers
instead of coming up with their own ones!
• Let’s inject browsers with our apps into the platform -
(crosswalk-project.org). This worked wonders with
Chromeframe and Internet Explorer.
ANGER
30. DENIAL BARGAINING DEPRESSION ACCEPTANCE
THE FIVE STAGES OF MOURNING FOR THE OPEN
WEB IN A MOBILE WORLD.
• Let’s concede defeat - we can never match what native
offers, and never innovate as fast.
• Let’s consider a new career - goat farming, for example,
sounds like a great investment.
• Let’s try to find recognition elsewhere - maybe in a smaller
group of people who care about what I do.
ANGER BARGAINING DEPRESSION
31. DENIAL BARGAINING DEPRESSION ACCEPTANCE
THE FIVE STAGES OF MOURNING FOR THE OPEN
WEB IN A MOBILE WORLD.
• Maybe this is just another form factor - and we could use
our time to care for the web that is instead.
• Maybe there is space for more than one form factor - just
maybe. I mean, crazier things have happened, like multiple
ways to use a road.
• Maybe this is a time to reflect and improve what we have -
after all, there is a lot that needs fixing?
ANGER BARGAINING DEPRESSION
35. 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
38. before
after
before
after
-webkit-appearance: none -webkit-gradient
EXPERIMENTAL? PROBABLY SAFE TO USE…
39. COPY + PASTE BEATS VALIDATION?
https://github.com/search?l=html&q=charset+%22UTF8%22&ref=searchresults&type=Code&utf8=%E2%9C%93
<meta http-equiv="content-type"
content="text/html;charset=utf-8" />
<meta charset="utf-8">
<meta charset=“utf8"> ✘
✔
> 600k times in use on GitHub!
40. 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
41. 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
43. PROMISES DON’T WORK
• Can we stop producing “not ready for
production” solutions?
• People are getting tired of “upcoming
amazing technology” we “need to use
now” and jump through hoops to
implement.
• Abstraction libraries end up in production,
become interoperability issues and fill up
the web.
• Experimental technology in use gets
included across browsers to ensure
backwards compatibility - making browsers
slow and fat.
44. WE SHOULD NEVER
PUNISH OUR USERS
• It isn’t their job to fix their working
environments to our needs
• There is no “everybody should use
this” - you publish on the web; you
knew what you signed up for.
• We’re wasting time re-evaluating
sensible concepts like progressive
enhancement. It works, it is future-
proof. Let’s not pretend we can
control things.
46. ✔ Let’s not repeated the same
mistakes we did with IE6
(checking for browsers, blocking
others)
✔ Let’s not write code “that works”
rather than “is correct”
✔ Let’s not optimise our work for a
platform that doesn’t appreciate
it and where it won’t flourish
(mobile)
LOVE FOR THE FORM
FACTOR THAT IS THE
WEB…
47. AND THIS IS WHERE
RIGHT NOW WE NEED
TO CONCENTRATE ON
GETTING ONE THING
RIGHT…
48. • 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…
49. 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
53. ✘ 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:
54. 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.
“
PRIORITIES OF CONSTITUENCIES…
61. 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…
62. HELP ES6 BY
LOOKING AT ITS
UNIT TESTS…
https://github.com/tc39/test262
http://test262.ecmascript.org/
65. Stick and Carrot: Alan O’Rourke
https://www.flickr.com/photos/33524159@N00/17233999165
THANK YOU!
Stick, Carrot and heart: opensourceway
https://www.flickr.com/photos/47691521@N07/5537457133/
Selfie Stick group: j0sh (www.pixael.com)
https://www.flickr.com/photos/87690240@N03/16322726941/
Skip by Denna Jones
https://www.flickr.com/photos/95267793@N00/2336623192
CHRIS HEILMANN
@CODEPO8
Messy room: David, Bergin, Emmett and Elliott
https://www.flickr.com/photos/44925192@N00/183227976