Innovation vs. Impatience - keynote at JSOpenDay London 2015

INNOVATION VS. IMPATIENCE
CHRIS HEILMANN (@CODEPO8), JSOPENDAY, LONDON, ENGLAND, 26/06/15

JAVASCRIPT IS…
• An incredibly versatile
language
• Available web-wide and
across many platforms
• Toolset independent
• Forgiving and inviting

YOU CAN USE
JAVASCRIPT
• In browsers on the web
• On the server
• In applications
• To access services
• As a data format (JSON)
• On hardware
• … your turn, surprise me :)

OUR
DEVELOPMENT
ENVIRONMENT IS
INCREDIBLE!
•Developer tools in browsers are
outstanding and give us
incredible insights.
•We can debug across devices
and even convert HTML5 to
native apps for closed systems
(manifold.js/vorlon.js).
•Editors have linting, build
integration, and some are even
written in JavaScript and run in
the browser.
•We share code on GitHub and
help debug problems using
JSFiddle, JSBin and others…

JAVASCRIPT IS IN SUPER HIGH DEMAND!
https://www.google.com/trends/explore#q=undeﬁned%20is%20not%20a%20function

WE’RE GOING
FULL SPEED ON
INNOVATION…
•Componentised Web
•Extensible Web Manifesto
•WebGL
•WebAssembly/ASM.js
•PostCSS
•Progressive Apps (!)

NODE.JS MADE IT
POSSIBLE TO GO
FULL-ON SERVER
SIDE AND FAT
CLIENT, TOO…
•Package Managers (NPM)
•Task Runners
•Linters
•Integration in editors
•Live reload/watching
•Unit Testing Libraries

THE FLEXIBILITY
OF JAVASCRIPT
MAKES ALL OF
THIS POSSIBLE…

MAKING THE WEB EXTENSIBLE?
•Focus on adding new low-level capabilities
to the web platform that are secure and
efficient.
•Expose low-level capabilities that explain
existing features, such as HTML and CSS,
allowing authors to understand and
replicate them.
•Develop, describe and test new high-level
features in JavaScript, and allow web
developers to iterate on them before they
become standardized. This creates a
virtuous cycle between standards and
developers.
•Prioritize efforts that follow these
recommendations and deprioritize and
refocus those which do not.
https://extensiblewebmanifesto.org/

THE IDEA IS
SOUND…
•Today, most new features
require months or years of
standardization, followed by
careful implementation by
browser vendors, only then
followed by developer
feedback and iteration.
•We prefer to enable feature
development and iteration in
JavaScript, followed by
implementation in browsers
and standardization.

SOUNDS GREAT!
IF YOU KNOW
JAVASCRIPT…
AND IT IS
AVAILABLE…

THANKFULLY
ONLY PARANOID
FREAKS TURN
OFF JAVASCRIPT!

http://kryogenix.org/code/browser/everyonehasjs.html
WELL, NOT QUITE…

THE WEB ISN’T DEFINED BY
TECHNOLOGICAL AVAILABILITY

JAVASCRIPT
ALLOWS YOU TO
WRITE CODE THAT
IS EXECUTED ON
YOUR USER’S
COMPUTERS…

THIS IS GOOD
•You benefit from the
computing power of your
users without hammering
the server
•You avoid latency as there
is no server roundtrip
•You can store content
without having to know
about it - it is only on this
computer
THIS IS BAD
•You have no control over
what the visitor uses to
access your product.
•Many things can go wrong
and in many cases you
are unable to replicate
them.
•You have no access to the
machine to install
software as needed

JAVASCRIPT IS
TECHNICALLY NOT A
GREAT LANGUAGE
FOR THE WEB…

HTML AND CSS
ARE DESIGNED TO
BE FAULT
TOLERANT.
https://adactio.com/journal/4272

JAVASCRIPT ISN’T
FAULT TOLERANT.

ONE LITTLE
MISTAKE, AND
NOTHING SHOWS
UP.

I FEEL, THAT THERE
IS AN UNHEALTHY
SPLIT IN SCHOOLS
OF THOUGHT RIGHT
NOW…

ONE SIDE OF THE
ARGUMENT THINKS
WE’VE COME A
LONG WAY AND WE
DESERVE A RICHER
WEB RIVALLING
NATIVE AND MOBILE

THE OTHER SIDE IS
STUCK IN THE OLD
DOGMA OF
SEPARATION OF
CONCERNS…

THE OLDSCHOOL
FOLK TEND TO TALK
A LOT ABOUT
PROGRESSIVE
ENHANCEMENT AS
THE SOLUTION.

CAPABILITY
TESTING MEANS
YOU NEVER
DELIVER BROKEN
EXPERIENCES.

“CUTTING THE MUSTARD”
https://justmarkup.com/log/2015/02/26/cut-the-mustard-revisited/

THE OTHER SIDE USES
THE ARGUMENT THAT
WE BUILD APPS, NOT
WEB SITES.
AND THESE DON’T EVEN
USE ANY HTML THAT
COULD BE ENHANCED.

THIS ISN’T ABOUT
APPS VS. WEB SITES
•Apps are a form factor of
consumable software
•They are optimised for a use
case and work without web
access
•Instead they use the hardware
they run on to the full extend
•Everything else is a pale copy
of an app

BUT THAT’S A
DIFFERENT TALK.

FACT IS THAT WE
LIVE IN A VERY
DIFFERENT WORLD
TO OUR END
USERS…

WE ARE IMPATIENT AND
WANT UPCOMING
FUNCTIONALITY RIGHT
NOW.

SIGN OF IMPATIENCE #1:
POLYFILLS

POLYFILLS ARE
GOOD
• No waiting for browser
support or standards
body agreement
• Fixing browser
inconsistencies during
the adoption period
• Allowing developers to
concentrate on the
solutions rather than the
tech that enables them
POLYFILLS ARE
BAD
• We tend to become
dependent on them - they
work, why bother fixing
this?
• They give performance
hungry functionality to
outdated environments
• They tend to stay in non-
maintained projects and
add to the landfill of
unnecessary JS.

NOT EVERYTHING
CAN BE SOLVED BY
A POLYFILL…

LIBRARIES AND
FRAMEWORKS
Rwanda Government https://www.ﬂickr.com/photos/90842932@N05/8967026639

RESULTING IN A
MASSIVE GROUP
OF DEVELOPERS
WHO ONLY KNOW
HOW TO USE
THOSE…

MAKING HEAVY
BETS ON THEIR
AVAILABILITY AND
USEFULNESS NOW
AND IN THE
FUTURE…

TRANSPILERS
Rwanda Government https://www.ﬂickr.com/photos/90842932@N05/8967026639

TRANSPILERS ALLOW
YOU TO WRITE THE
NEXT VERSION OF A
LANGUAGE NOW…

HOWEVER, IT GENERATES
OLD SCHOOL CODE, SO
YOU FORFEIT THE
RUNTIME BENEFITS OF
THE NEW VERSION…

THE WEB USE CASE
OF JAVASCRIPT IS
VERY MUCH IN A
STATE OF
CONFUSION…

MOSTLY BECAUSE
WE FAIL TO LEARN
FROM MISTAKES OF
THE PAST.

REMOVING THE
LARGEST STUMBLING
BLOCK OF THE WEB!

DELETING OLD AND
UNNECESSARY
CODE FEELS
TERRIBLY GOOD…
✘ VML
✘ attachEvent()
✘ currentStyle
✘ X-UA-Compatible (render
modes)
✘ IE Layout Quirks
✘ VBScript
✘ Conditional Comments
✘ MS-Prefixed Events

REPLACING THE CRUFT WITH
GOODNESS…

A WEB SAFARI BURNING CHROME?
https://twitter.com/Caged/status/590602214021922818

USER AGENT
SNIFFING…
PARSING THE “PACK OF LIES”

LET’S DETECT MOBILE!
window.mobileCheck
=
function()
{

var
check
=
false;

(function(a){if(/(android|bbd+|meego).+mobile|avantgo|bada/|blackberry|blazer|compal|elaine|
fennec|hiptop|iemobile|ip(hone|od)|iris|kindle|lge
|maemo|midp|mmp|mobile.+firefox|netfront|opera

m(ob|in)i|palm(
os)?|phone|p(ixi|re)/|plucker|pocket|psp|series(4|6)0|symbian|treo|up.(browser|
link)|vodafone|wap|windows
(ce|phone)|xda|xiino/i.test(a)||/1207|6310|6590|3gso|4thp|50[1-‐6]i|
770s|802s|a
wa|abac|ac(er|oo|s-‐)|ai(ko|rn)|al(av|ca|co)|amoi|an(ex|ny|yw)|aptu|ar(ch|go)|as(te|
us)|attw|au(di|-‐m|r
|s
)|avan|be(ck|ll|nq)|bi(lb|rd)|bl(ac|az)|br(e|v)w|bumb|bw-‐(n|u)|c55/|
capi|ccwa|cdm-‐|cell|chtm|cldc|cmd-‐|co(mp|nd)|craw|da(it|ll|ng)|dbte|dc-‐s|devi|dica|dmob|do(c|
p)o|ds(12|-‐d)|el(49|ai)|em(l2|ul)|er(ic|k0)|esl8|ez([4-‐7]0|os|wa|ze)|fetc|fly(-‐|_)|g1
u|g560|
gene|gf-‐5|g-‐mo|go(.w|od)|gr(ad|un)|haie|hcit|hd-‐(m|p|t)|hei-‐|hi(pt|ta)|hp(
i|ip)|hs-‐c|
ht(c(-‐|
|_|a|g|p|s|t)|tp)|hu(aw|tc)|i-‐(20|go|ma)|i230|iac(
|-‐|/)|ibro|idea|ig01|ikom|im1k|
inno|ipaq|iris|ja(t|v)a|jbro|jemu|jigs|kddi|keji|kgt(
|/)|klon|kpt
|kwc-‐|kyo(c|k)|le(no|xi)|
lg(
g|/(k|l|u)|50|54|-‐[a-‐w])|libw|lynx|m1-‐w|m3ga|m50/|ma(te|ui|xo)|mc(01|21|ca)|m-‐cr|me(rc|
ri)|mi(o8|oa|ts)|mmef|mo(01|02|bi|de|do|t(-‐|
|o|v)|zz)|mt(50|p1|v
)|mwbp|mywa|n10[0-‐2]|n20[2-‐3]|
n30(0|2)|n50(0|2|5)|n7(0(0|1)|10)|ne((c|m)-‐|on|tf|wf|wg|wt)|nok(6|i)|nzph|o2im|op(ti|wv)|oran|
owg1|p800|pan(a|d|t)|pdxg|pg(13|-‐([1-‐8]|c))|phil|pire|pl(ay|uc)|pn-‐2|po(ck|rt|se)|prox|psio|pt-‐
g|qa-‐a|qc(07|12|21|32|60|-‐[2-‐7]|i-‐)|qtek|r380|r600|raks|rim9|ro(ve|zo)|s55/|sa(ge|ma|mm|ms|ny|
va)|sc(01|h-‐|oo|p-‐)|sdk/|se(c(-‐|0|1)|47|mc|nd|ri)|sgh-‐|shar|sie(-‐|m)|sk-‐0|sl(45|id)|sm(al|
ar|b3|it|t5)|so(ft|ny)|sp(01|h-‐|v-‐|v
)|sy(01|mb)|t2(18|50)|t6(00|10|18)|ta(gt|lk)|tcl-‐|tdg-‐|
tel(i|m)|tim-‐|t-‐mo|to(pl|sh)|ts(70|m-‐|m3|m5)|tx-‐9|up(.b|g1|si)|utst|v400|v750|veri|vi(rg|te)|
vk(40|5[0-‐3]|-‐v)|vm40|voda|vulc|vx(52|53|60|61|70|80|81|83|85|98)|w3c(-‐|
)|webc|whit|wi(g
|nc|
nw)|wmlb|wonu|x700|yas-‐|your|zeto|zte-‐/i.test(a.substr(0,4)))check
=
true})
(navigator.userAgent||navigator.vendor||window.opera);

return
check;
}

WHAT CAN GO WRONG?

RELEASING A
STANDARDS
COMPLIANT
BROWSER IN 2015
ISN’T ENOUGH…
✘ we repeated the same
mistakes we did with IE6
(checking for browsers,
blocking others)
✘ we practice code “that
works” rather than “is
correct”
✘ we optimised our work for
a platform that doesn’t
appreciate it and where it
won’t flourish

USER CHOICE VS.
DEVELOPER
PREFERENCE…

WE OPTIMISE FOR
THE ENVIRONMENT
WITH THE LEAST
BROWSER
INNOVATION AND
THE LARGEST
FRAGMENTATION:
MOBILE

WHERE ONE OF THE
LARGEST PLAYERS
WITH THE MOST
AFFLUENT USERS IS
NOT TOO FORWARD
ABOUT UPCOMING
FEATURES…

SADLY, ENGINE
FAVOURITISM EVEN
HAPPENS IN
CONTROLLED
ENVIRONMENTS…

https://github.com/sindresorhus/chakra-nerp

FIXING OUR
APPROACH TO JS
TO FIND HARMONY
AND PEACE…

JAVASCRIPT GREW
INTO SOMETHING
MUCH MORE
COMPLEX THAN
BEFORE.
✔ Different environments
play by different rules
✔ What’s great client-side
can be terrible in a node.js
script and vice versa
✔ What’s necessary in a
complex app can be dead
weight on the client
✔ Necessary checks on the
client aren’t needed on
the server - as there is
better error handling

WHILST WE CAN FIX
THINGS, WE
SHOULDN’T ADD ON
PILES OF DUCT-TAPE
✔ Browser differences will
always be a thing - this is
the nature of the web
✔ Some functionality should
only be available for high-
end devices and browsers,
no need to pester old and
slow hardware and
software
✔ Nobody reads the “don’t
use in production”
messages.

JAVASCRIPT HAS A
NEW ROLE THAT
ISN’T TALKED
ABOUT ENOUGH…
✔ Many use cases compile
to JavaScript
✔ These traditionally were
covered by plug-in
dependent code (Flash,
NaCl, Java Applets…)
✔ JavaScript’s flexibility is an
issue here - hence ASM.js/
WebAssembly…

THIS IS A GOOD
TIME TO SPEAK UP
ABOUT JAVASCRIPT
AS A USER OF THE
LANGUAGE…

WE LOST
OURSELVES IN
MAKING LIFE
EASIER FOR US…
•We’re the truck drivers of the
web - our job is to deliver
experiences to users
•The final experience is what
matters, not how many
keystrokes we saved
•Are cookie-cutter solutions
really the best experience?
•Not everything needs to be
made generic.

WE SHOULDN’T
PRIDE OURSELVES
ABOUT MAKING
THINGS COMPLEX.

THE PENDULUM
SWINGS BACK…
•Native is trying to emulate the
benefits of the web (indexable
Apps, updates outside the
market place)
•Hybrid Apps get better and are
more supported (Windows 10,
App Manifest, Manifold.js,
PhoneGap ContentSync)
•We run the danger of moving
into academic wonderland with
the language itself (remember
XHTML?)

LET’S CONSIDER THAT
DIFFERENT USE CASES NEED
DIFFERENT APPROACHES.
“YOU HAVE TO USE…”
DIDN’T GET US WHERE WE
ARE NOW.

THANKS!
CHRIS HEILMANN
@CODEPO8

Innovation vs. Impatience - keynote at JSOpenDay London 2015

More Related Content

What's hot

Viewers also liked

Similar to Innovation vs. Impatience - keynote at JSOpenDay London 2015

More from Christian Heilmann

Recently uploaded

Innovation vs. Impatience - keynote at JSOpenDay London 2015