4. 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/
7. 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()
8. Computers and smartphones are powerful.
Browsers can do a lot more and are a lot less
random than they used to be…
JavaScript is flexible and has evolved.
CSS has become amazing.
Developer tools in browsers give us great
debugging and even design capabilities.
😍
🦄
🎉
What I became aware of (once more)…
9. 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
📦
15. 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…
16. As we don’t keep the
state of the game in the
browser, I need to
maintain the random
array in between
reloads…
👜
17. The amount is not much,
but you better make sure
that there is no way to
inject code to the server.
🚨
20. 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…
🍕
21. 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.
28. It is time to re-think our best practice for
the web approach…
✅ 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.
29. It is time to re-think our best practice for
the web approach…
💣 Shit happens! Spend more time in creating sensible
error messaging and fallbacks, spend less time in
trying to predict every possible error
💣 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…
