Haha, you're reading this. You're alone in this.

1. Progressive Web Apps – the return of the web?
Chris Heilmann @codepo8, Goto Berlin, November 2016

2. Chris Heilmann
@codepo8

3. There is a very cool thing
happening right now…
😃

4. 💾
The honeymoon period
of native apps is over.
🗑
🔥

5. 💾🗑
🔥

6. 💾🗑
🔥

7. 💾🗑
🔥

8. 🌍
However, there is still the
problem of a changing
world.

9. 🖥→💻→📱
Evolution is happening around us…
…and user numbers are shifting.

10. 💔 The web wasn’t ready for
the mobile form factor.

11. 😠
🌧 Mobile was a throwback to the
web of old
🌧 Small screens, bad connectivity,
unreliable browser support
🌧 Constantly changing conditions
🌧 Hardwired browser and hardware
with unpredictable upgrades

12. ⚠ We weren’t ready to go all
out on web with mobile.

13. 💾
🌧 Instead of creating web sites that
work well on mobile, we packaged
them up and submitted them to
market places.
🌧 In a 1:1 comparison with native
apps, they looked rubbish.
🍎 This may or may not have been
by design

14. https://remysharp.com/2016/05/28/state-of-the-gap
These days, we’re
looking much better…

15. The big breakthrough:
Service Worker
https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API
🔧

16. Progressive Web Apps
🦄

17. “Websites that
have taken all the
right vitamins”
– Alex Russel?
https://webmasters.googleblog.com/2016/11/building-indexable-progressive-web-apps.html

18. 🦄
🔧 Work offline using Service Worker
🔧 Can hibernate and notify on
change
🔧 Possible progressive enhancement
of a working, standard web site
🔧 More functionality with
subsequent visits
🔧 The link is the distribution model

19. 🦄
🔧 All the benefits of native apps -
none of the sluggish distribution
issues
🔧 Natural evolution of web content
into the mobile form factor
🔧 A big opportunity to crack the
closed distribution model

20. 💷

21. 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
😍
🦄
🎉

22. 💩 And yet, the mobile web is
in a very sorry state.

23. 🤔
But, but but, everybody
says the mobile web
doesn’t exist!
It’s just the web and we
make it responsive…

24. 🔬 Alright, let’s look at the
problem…

25. This used to be
much easier…
HTML
(Structure)
CSS
(Look and Feel)
JavaScript
(Behaviour)

26. Flexibility and forgiveness…
💧 HTML and CSS are fault tolerant…

27. Knives, bees and footguns…
🦂 JavaScript is not fault tolerant

28. This is why we keep
banging on about
progressive enhancement

29. Using this, we can support the past…

30. And we can support
current edge cases…

31. And after some checking, all the current
browsers and what they support…

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

33. The HTML5 revolution
promised a move from
documents to apps…

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

35. https://vimeo.com/176453149
Monica Dinculescu < INPUT >
HTML Special, CSS Day

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

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

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

39. Keep users on this page…
https://mathiasbynens.github.io/rel-noopener/
https://medium.com/@jitbit/target-blank-the-most-underestimated-vulnerability-ever-96e328301f4c#.mjuw7q3cf
🔓💩

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

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

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

43. JavaScript isn’t evil.

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

45. Supporting the past balancing act…
Use powerful
language
additions…
Don’t block out
older browsers and
environments…

46. Progressive enhancement balancing act
Control the UX with
JavaScript and own
the failure cases.
Rely on the browser
to give a “working”
experience.

47. I don’t have all the answers
for you. A lot of this
depends on your project,
goals and resources.
😳

48. !

49. JavaScript can’t be
trusted and can be
turned off.
💣 🔨Everybody has
JavaScript, and we can
do everything with it!

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

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

52. Until the first successful load,
you have no JavaScript
functionality. That is a fact.B

53. However, subsequently, you
can do a lot with JavaScript
that is needed on mobile
and can’t be done in HTML/
CSS.
😊

54. New error cases become
much more important than
“JavaScript is not available”⚠

55. ✏ 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
❤📲

56. 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 things work offline - inlining everything
or using local storage would be enough
📦

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

58. What about accessibility, eh?
♿

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

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

61. It is time we took ownership
and responsibility of the
whole technology stack.🔋

62. There is a culture of “let’s
use whatever if it works”
😐

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

64. 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…

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

66. Instead of bashing bad use
of JavaScript, let’s embrace
and scrutinise new ideas.🔎

67. 🆙
🔧 Any web product can become a
Progressive Web App, not all have
to be.
🔧 You’ll reap the rewards of simple
maintenance and upgrade paths
and the form factor mobile users
expect.
🔧 However, it makes sense to clean
up before going there…

68. 🛠
🔧 Look at what you built, check the
current state of affairs at http://
caniuse.com and remove all the
cruft you don’t need.
🔧 Simplify your interfaces, the next
users are impatient and on flaky
connections.
🔧 Reconsider the ways you build
and deploy your products, a lot
can be automated.

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

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

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

72. 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…

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

74. CHRIS HEILMANN
@CODEPO8
CHRISTIANHEILMANN.COM
THANKS!