2. Of innovation and impatience
Chris Heilmann @codepo8, Future Decoded, London, Nov 2015
CHRIS HEILMANN
@CODEPO8
3. We all know this
character, right?
https://en.wikipedia.org/wiki/Mario#Concept_and_creation
4. But do you know
why it looks like it
does?
https://en.wikipedia.org/wiki/Mario#Concept_and_creation
5. Red and Blue offered the
best contrast to the skin,
boots and the game
background.
https://en.wikipedia.org/wiki/Mario#Concept_and_creation
6. The cap meant there was
no need to worry about
hair style, eyebrows and
forehead.
(There were also not enough
pixels for waving hair when
falling down a hole)
7. The large nose and
moustache made it
possible to avoid a mouth
and facial expressions.
24. That was fun…
😎 Written on a plane, offline and in
roughly two hours
😎 Works on desktop and mobile,
independent of input and is
responsive
😎 Using ServiceWorker caches
content locally and can be played
offline
😎 All in all < 8 kb with the biggest
part being iconshttps://codepo8.github.io/10kb-CSS-colour-game/
27. The structure was not hard…
😎 Have an array of all the possible colours.
😎 Get a random cut of n elements, display them as a list; store the name of the colour
as a data attribute
😎 Get one item of the list as the colour to match, show its name.
😎 Use event delegation on the list to add one click handler (also allows for keyboard)
😎 Compare the data attribute of the target of the event with the colour to match
😎 If true, display a new random list
😎 If false, decrease the possible moves counter
😎 If no more moves left, show game over
💩 Only issue: there is no array_rand()
28. Computers and smartphones are
powerful.
Browsers can do a lot and are open to
feedback.
JavaScript is flexible and has evolved.
CSS has become amazing.
Developer tools in browsers give us great
debugging and even design capabilities
😍
🦄
🎉
29. The beauty of HTML, CSS and JS…
😍 All is contained in one package
😍 Everything is running on the end users
environments
😍 You wouldn’t even need ServiceWorker to
make this work offline - inlining everything
would be enough
📦
35. New, more sturdy structure…
😎 Write a PHP API with the named colours as the content
😎 Use array_rand() to get a cut of that, pick one as the one to match
😎 Write out a list of buttons with the same name and the colour as the value.
😎 If the colour matches the button that was clicked, get a new list
😎 If the colour doesn’t match, decrease the amount of moves and show the list again.
😠 Oh, crap…
36. As we don’t keep the
state of the game in the
browser, I need to
maintain the random
array in between
reloads…
👜
37. The amount is not much,
but you better make sure
that there is no way to
inject code to the server.
🚨
40. Now it works without JS, let’s add some…
😎 Load the API content with Francis, err… AJAX
🤔 Repeat the rest of the functionality client-side, or do
a lot of unnecessary server roundtrips…
🍕
41. The better, sturdier, more webby version
🤔 Almost same amount of
JavaScript content
🤔 Doesn’t work offline, unless
we also create a different
API
🤔 But it does work with
JavaScript disabled.
😨 It also allows bad people
to inject code unless we
are very vigilant in keeping
our backend secure.
47. This means that new error
cases become much more
important than “JavaScript is
not available”
⚠
48. ✏ Small initial payload
✏ Form factor supporting content
✏ Form factor supporting interfaces
✏ Offline/Flaky connection support
✏ Taking advantage of the power of
the end user device
✏ Avoiding interaction latency
❤📲
49. This is achievable using
HTML, JavaScript and CSS,
but it is much harder - if
not impossible - without
client side scripting.
👷
50. Which is annoying, as the
HTML5 revolution
promised a move from
documents to apps…
51. The problem is that eight
years after the proposal
and five years after
HTML5’s “last call”, there
are still many basic support
issues…
😦
54. And the bad people of the
internet don’t stop abusing
old technology either…💀
55. In UGC, we can’t have nice things…
https://mathiasbynens.github.io/rel-noopener/
https://medium.com/@jitbit/target-blank-the-most-underestimated-vulnerability-ever-96e328301f4c#.mjuw7q3cf
56. Keep users on this page…
https://mathiasbynens.github.io/rel-noopener/
https://medium.com/@jitbit/target-blank-the-most-underestimated-vulnerability-ever-96e328301f4c#.mjuw7q3cf
🔓💩
57. Fix for newer browsers…
https://mathiasbynens.github.io/rel-noopener/
https://medium.com/@jitbit/target-blank-the-most-underestimated-vulnerability-ever-96e328301f4c#.mjuw7q3cf
58. Fix for all browsers…
https://mathiasbynens.github.io/rel-noopener/
https://medium.com/@jitbit/target-blank-the-most-underestimated-vulnerability-ever-96e328301f4c#.mjuw7q3cf
59. Almost…
Listen for the click event and prevent the default
browser behavior of opening a new tab. Inject a
hidden iframe that opens the new tab, then
immediately remove the iframe.“
https://github.com/danielstjules/blankshield
60. Our solutions should have
excellent error handling
instead of automatic
tolerance.
👌
61. And they should be great
solutions and not just
“good enough without
breaking”.
https://twitter.com/dieni/status/767589581046841344
69. http://status.npmjs.org/incidents/dw8cr1lwxkcr
Better be safe and require()…
More detail: the "fs" package is a non-functional
package. It simply logs the word "I am fs" and exits.
There is no reason it should be included in any
modules. However, something like 1000 packages *do*
mistakenly depend on "fs", probably because they were
trying to use a built-in node module called "fs".
81. It is more important for us
to get a grip on the overall
quality of the web and our
code…
🏅
82. Using
instead of a URL or using a
button is not JavaScript’s fault.
It is a bad idea and practice -
probably copy & paste.
💩
<a href="javascript:void(0)">
83. Instead of bashing bad use
of JavaScript, let’s embrace
and scrutinise new ideas like
components and paradigms
like functional programming.
🔎
84. There is a very cool thing
happening right now…
😃
85. A lot of the next
improvements of the web are
progressive enhancements of
existing JavaScript solutions.
🍾
89. Service Worker & PWAs
https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API
🔧 🦄
90. ✅ Create and publish as much content
independent of JavaScript as you can
✅ JavaScript can make things much more
enjoyable and some things are just not
worth while to implement without.
✅ Use JavaScript to benefit from the user’s
hardware
✅ Spend more time building great
interfaces, less time relying on what is
there and can’t break - in many cases it
is disappointing.
It is time to re-
think our best
practice for the
web approach…
91. 🙂 You don’t rely on automatic fixes.
JavaScript breaks and it is painful. It
allows us to analyse what went wrong.
🙂 Tooling is much better and we get much
more insights into what happened than
with, for example, CSS
🙂 We take responsibility of the interface. It
is our job to make it happen - not
browser makers to agree and find a
consensus
🙂 We have full control over what gets
loaded when, cached where and
rendered when.
Benefits of an “It’s
OK to rely on JS
for this”
approach…
92. ⚠ We shouldn’t hide functionality in
magical abstractions. A product that
relies on the availability and maintenance
of a framework is not a script
dependency - it is a support issue.
⚠ Just because we can do everything in
JavaScript, doesn’t mean we have to. Use
it when HTML is not good enough or too
broken to rely on.
⚠ While the client is powerful, it is also
unknown. A lot more can be done on
the server - and in JavaScript.
Dangers to be
aware of…
93. Important
considerations
independent of
technology used…
💣 Shit happens! Spend more time in
creating sensible error messaging and
fallbacks, spend less time in trying to
predict every possible error
💣 Slowness kills - our solutions must load
fast what is needed and enhance when
they can. They also need to be snappy.
💣 Offline and flaky is the norm - avoid
network dependency as much as you
can
💣 Security is paramount. A hacked
server sending out malware or spam is
worse than an app that needs a
restart…
94. We have to stop thinking in
binaries, and consider writing
great, secure and failure-
aware solutions using each
technology to its strengths.
🐝
