javascript isn't evil

96
JavaScript isn’t evil… Chris Heilmann @codepo8, Copenhagen Frontend, October 2016

Upload: christian-heilmann

Post on 14-Jan-2017

732 views

Category:

Design


0 download

TRANSCRIPT

Page 1: JavaScript isn't evil

JavaScript isn’t evil…

Chris Heilmann @codepo8, Copenhagen Frontend, October 2016

Page 2: JavaScript isn't evil

Of innovation and impatience

Chris Heilmann @codepo8, Future Decoded, London, Nov 2015

CHRIS HEILMANN @CODEPO8

Page 3: JavaScript isn't evil

We all know this character, right?

https://en.wikipedia.org/wiki/Mario#Concept_and_creation

Page 4: JavaScript isn't evil

But do you know why it looks like it does?

https://en.wikipedia.org/wiki/Mario#Concept_and_creation

Page 5: JavaScript isn't evil

Red and Blue offered the best contrast to the skin, boots and the game background.

https://en.wikipedia.org/wiki/Mario#Concept_and_creation

Page 6: JavaScript isn't evil

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)

Page 7: JavaScript isn't evil

The large nose and moustache made it possible to avoid a mouth and facial expressions.

Page 8: JavaScript isn't evil

Design by limitations.!

Page 9: JavaScript isn't evil

Design by lack of definition.🌎🕸

Page 10: JavaScript isn't evil

Flexibility and forgiveness…

💧 HTML and CSS are fault tolerant…

Page 11: JavaScript isn't evil

Knives, bees and footguns…

🦂 JavaScript is not fault tolerant

Page 12: JavaScript isn't evil

With HTML and CSS you’re relying on the user agent to do the right thing…🙁

Page 13: JavaScript isn't evil

Using JavaScript, you have a means to test if what you’re trying to do succeeded…✅

Page 14: JavaScript isn't evil

Predicting things is tough…🔮

Page 15: JavaScript isn't evil

That’s why progressive enhancement was a great idea to solve this issue…

Page 16: JavaScript isn't evil

But is it still enough?🔬

Page 17: JavaScript isn't evil

And what does it mean?🤔

Page 18: JavaScript isn't evil

JavaScript can’t be trusted and can be turned off.💣

Page 19: JavaScript isn't evil

Everybody has JavaScript, and we can do everything with it?🔨

Page 20: JavaScript isn't evil

!

Page 21: JavaScript isn't evil

Story time…🐷*3🐺+🏠+🌳

Page 22: JavaScript isn't evil

https://a-k-apart.com/

Page 23: JavaScript isn't evil

Excellent, let’s do this!

https://codepo8.github.io/10kb-CSS-colour-game/

Page 24: JavaScript isn't evil

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/

Page 25: JavaScript isn't evil

Well done, Chris!

https://www.google.com/patents/US4608967

Page 26: JavaScript isn't evil

Here’s the source… …Luke?

Page 27: JavaScript isn't evil

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()

Page 28: JavaScript isn't evil

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

😍

🦄

🎉

Page 29: JavaScript isn't evil

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

📦

Page 30: JavaScript isn't evil

Then I read the contest guidelines…😟

Page 31: JavaScript isn't evil

https://a-k-apart.com/faq http://stateofjs.com/

Page 32: JavaScript isn't evil

I FAQed up… 😭

Page 33: JavaScript isn't evil

Should I try to make this a NodeJS, universal, functional, gluten-free…🤔

Page 34: JavaScript isn't evil

Sod it, I know PHP…🤓

Page 35: JavaScript isn't evil

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…

Page 36: JavaScript isn't evil

As we don’t keep the state of the game in the browser, I need to maintain the random array in between reloads…

👜

Page 37: JavaScript isn't evil

The amount is not much, but you better make sure that there is no way to inject code to the server.🚨

Page 38: JavaScript isn't evil
Page 39: JavaScript isn't evil

Constant vigilance, Harry…

Page 40: JavaScript isn't evil

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…🍕

Page 41: JavaScript isn't evil

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.

Page 42: JavaScript isn't evil

How about some heresy?😯

Page 43: JavaScript isn't evil

The “JavaScript not available” argument is largely bogus and is holding back the web!

⬇ 🎤

Page 44: JavaScript isn't evil

The “JavaScript is flaky and will break” argument is very much alive and will always be that way…🚧

Page 45: JavaScript isn't evil

We call this “programming”✊

Page 46: JavaScript isn't evil

🖥→💻→📱Evolution is happening around us…

…and user numbers are shifting.

Page 47: JavaScript isn't evil

This means that new error cases become much more important than “JavaScript is not available”⚠

Page 48: JavaScript isn't evil

✏ 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

❤📲

Page 49: JavaScript isn't evil

This is achievable using HTML, JavaScript and CSS, but it is much harder - if not impossible - without client side scripting.

👷

Page 50: JavaScript isn't evil

Which is annoying, as the HTML5 revolution promised a move from documents to apps…

Page 51: JavaScript isn't evil

The problem is that eight years after the proposal and five years after HTML5’s “last call”, there are still many basic support issues…

😦

Page 52: JavaScript isn't evil

https://vimeo.com/176453149

Monica Dinculescu < INPUT > HTML Special, CSS Day

Page 53: JavaScript isn't evil

https://www.filamentgroup.com/lab/type-number.html

Page 54: JavaScript isn't evil

And the bad people of the internet don’t stop abusing old technology either…💀

Page 55: JavaScript isn't evil

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

Page 56: JavaScript isn't evil

Keep users on this page…

https://mathiasbynens.github.io/rel-noopener/https://medium.com/@jitbit/target-blank-the-most-underestimated-vulnerability-ever-96e328301f4c#.mjuw7q3cf

🔓💩

Page 57: JavaScript isn't evil

Fix for newer browsers…

https://mathiasbynens.github.io/rel-noopener/https://medium.com/@jitbit/target-blank-the-most-underestimated-vulnerability-ever-96e328301f4c#.mjuw7q3cf

Page 58: JavaScript isn't evil

Fix for all browsers…

https://mathiasbynens.github.io/rel-noopener/https://medium.com/@jitbit/target-blank-the-most-underestimated-vulnerability-ever-96e328301f4c#.mjuw7q3cf

Page 59: JavaScript isn't evil

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

Page 60: JavaScript isn't evil

Our solutions should have excellent error handling instead of automatic tolerance.👌

Page 61: JavaScript isn't evil

And they should be great solutions and not just “good enough without breaking”.

https://twitter.com/dieni/status/767589581046841344

Page 62: JavaScript isn't evil

Non-defensive coding is a problem…

Page 63: JavaScript isn't evil

We all make mistakes and errors happen…

Page 64: JavaScript isn't evil
Page 65: JavaScript isn't evil

There is a culture of “let’s use whatever until it works”😐

Page 66: JavaScript isn't evil

Standing on the shoulders of… …people?

Page 67: JavaScript isn't evil

http://status.npmjs.org/incidents/dw8cr1lwxkcr

Page 68: JavaScript isn't evil

http://status.npmjs.org/incidents/dw8cr1lwxkcr

Page 69: JavaScript isn't evil

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".

Page 70: JavaScript isn't evil

https://www.npmjs.com/package/groot

Passive Event Listeners

Page 71: JavaScript isn't evil

https://www.npmjs.com/package/groot

Passive Event Listeners

Page 72: JavaScript isn't evil

This is not a JavaScript thing…

Page 73: JavaScript isn't evil

We have a lot of messy solutions, and we keep building more tools to undo what clogs up the web.

Page 74: JavaScript isn't evil

Best practices can help with that, but only when they apply to the people who build things and when they solve current issues and needs…

Page 75: JavaScript isn't evil

What about older browsers?

Page 76: JavaScript isn't evil

What about extreme environment browsers?

Page 77: JavaScript isn't evil

These are valid concerns, but edge cases. And shouldn’t be used as a punishment scenario.🗞

Page 78: JavaScript isn't evil

What about accessibility, eh?♿

Page 79: JavaScript isn't evil

Used sensibly, JavaScript is an accessibility benefit. Sometimes the only way to make things accessible. ARIA is not magic.

🕹

Page 80: JavaScript isn't evil

https://codepo8.github.io/gridnav/

Page 81: JavaScript isn't evil

It is more important for us to get a grip on the overall quality of the web and our code…🏅

Page 82: JavaScript isn't evil

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)">

Page 83: JavaScript isn't evil

Instead of bashing bad use of JavaScript, let’s embrace and scrutinise new ideas like components and paradigms like functional programming.

🔎

Page 84: JavaScript isn't evil

There is a very cool thing happening right now…😃

Page 85: JavaScript isn't evil

A lot of the next improvements of the web are progressive enhancements of existing JavaScript solutions.🍾

Page 86: JavaScript isn't evil

https://www.youtube.com/watch?v=NPM6172J22g

Passive Event Listeners

Page 87: JavaScript isn't evil

true: apply on capture

false: apply on bubble

false enables event delegation😊

Page 88: JavaScript isn't evil

Passive Event Listeners

Page 89: JavaScript isn't evil

Service Worker & PWAs

https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API

🔧 🦄

Page 90: JavaScript isn't evil

✅ 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…

Page 91: JavaScript isn't evil

🙂 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…

Page 92: JavaScript isn't evil

⚠ 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…

Page 93: JavaScript isn't evil

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…

Page 94: JavaScript isn't evil

We have to stop thinking in binaries, and consider writing great, secure and failure-aware solutions using each technology to its strengths.

🐝

Page 95: JavaScript isn't evil

Mario evolved - so can the web…

Page 96: JavaScript isn't evil

CHRIS HEILMANN

@CODEPO8

CHRISTIANHEILMANN.COM

THANKS!