Download to read offline
Uploaded byChristian Heilmann
Progressive web and the problem of JavaScript
1. The document discusses the debate around relying on JavaScript for web applications and progressive enhancement. 2. It argues that while JavaScript can break, the web has evolved to focus more on capable client-side devices rather than availability of JavaScript. 3. It suggests embracing new paradigms like components and functional programming to build high quality, error-handling code rather than avoiding JavaScript.
More Related Content
![[jqconatx] Adaptive Images for Responsive Web Design](https://cdn.slidesharecdn.com/ss_thumbnails/adaptive-imagesv14-130911193737-phpapp01-thumbnail.jpg?width=600ounds&width=560&fit=bounds)
Similar to Progressive web and the problem of JavaScript
Progressive web and the problem of JavaScript
- 1. Progressive web andthe problem of JavaScript Chris Heilmann @codepo8, SmashingConf Jam Session, September 2016
- 2. Of innovation andimpatience Chris Heilmann @codepo8, Future Decoded, London, Nov 2015 CHRIS HEILMANN @CODEPO8
- 3. We all knowthis character, right? https://en.wikipedia.org/wiki/Mario#Concept_and_creation
- 4. But do youknow why it looks like it does? https://en.wikipedia.org/wiki/Mario#Concept_and_creation
- 5. Red and Blueoffered the best contrast to the skin, boots and the game background. https://en.wikipedia.org/wiki/Mario#Concept_and_creation
- 6. The cap meantthere 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 noseand moustache made it possible to avoid a mouth and facial expressions.
- 8.
- 9. Design by lackof definition. 🌎🕸
- 10. Flexibility and forgiveness… 💧HTML and CSS are fault tolerant…
- 11. Knives, bees andfootguns… 🦂 JavaScript is not fault tolerant
- 12. With HTML andCSS you’re relying on the user agent to do the right thing…🙁
- 13. Using JavaScript, youhave a means to test if what you’re trying to do succeeded…✅
- 14. Predicting things istough… 🔮
- 15. That’s why progressive enhancementwas a great idea to solve this issue…
- 16. But is itstill enough? 🔬
- 17. And what doesit mean? 🤔
- 18. JavaScript can’t betrusted and can be turned off. 💣
- 19. Everybody has JavaScript,and we can do everything with it? 🔨
- 20.
- 21.
- 22.
- 23. Excellent, let’s dothis! https://codepo8.github.io/10kb-CSS-colour-game/
- 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/
- 25.
- 26. Here’s the source……Luke?
- 27. The structure wasnot 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 smartphonesare 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 ofHTML, 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 📦
- 30. Then I readthe contest guidelines… 😟
- 31.
- 32.
- 33. Should I tryto make this a NodeJS, universal, functional, gluten-free…🤔
- 34. Sod it, Iknow PHP… 🤓
- 35. New, more sturdystructure… 😎 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’tkeep the state of the game in the browser, I need to maintain the random array in between reloads… 👜
- 37. The amount isnot much, but you better make sure that there is no way to inject code to the server. 🚨
- 39.
- 40. Now it workswithout 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.
- 42. How about someheresy? 😯
- 43. The “JavaScript notavailable” argument is largely bogus and is holding back the web! ➡ 🎤
- 44. The “JavaScript isflaky and will break” argument is very much alive and will always be that way… 🚧
- 45. We call this“programming” B
- 46. 🖥→💻→📱 Evolution is happeningaround us… …and user numbers are shifting.
- 47. This means thatnew error cases become much more important than “JavaScript is not available” ⚠
- 48. ✏ Small initialpayload ✏ 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 achievableusing 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 isthat eight years after the proposal and five years after HTML5’s “last call”, there are still many basic support issues… 😦
- 52. https://vimeo.com/176453149 Monica Dinculescu <INPUT > HTML Special, CSS Day
- 53.
- 54. And the badpeople of the internet don’t stop abusing old technology either…💀
- 55. In UGC, wecan’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 onthis page… https://mathiasbynens.github.io/rel-noopener/ https://medium.com/@jitbit/target-blank-the-most-underestimated-vulnerability-ever-96e328301f4c#.mjuw7q3cf 🔓💩
- 57. Fix for newerbrowsers… https://mathiasbynens.github.io/rel-noopener/ https://medium.com/@jitbit/target-blank-the-most-underestimated-vulnerability-ever-96e328301f4c#.mjuw7q3cf
- 58. Fix for allbrowsers… https://mathiasbynens.github.io/rel-noopener/ https://medium.com/@jitbit/target-blank-the-most-underestimated-vulnerability-ever-96e328301f4c#.mjuw7q3cf
- 59. Almost… Listen for theclick 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 shouldhave excellent error handling instead of automatic tolerance. 👌
- 61. And they shouldbe great solutions and not just “good enough without breaking”. https://twitter.com/dieni/status/767589581046841344
- 62. Non-defensive coding isa problem…
- 63. We all makemistakes and errors happen…
- 65. There is aculture of “let’s use whatever until it works” 😐
- 66. Standing on theshoulders of… …people?
- 67.
- 68.
- 69. http://status.npmjs.org/incidents/dw8cr1lwxkcr Better be safeand 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".
- 70.
- 71.
- 72. This is nota JavaScript thing…
- 73. We have alot of messy solutions, and we keep building more tools to undo what clogs up the web.
- 74. Best practices canhelp with that, but only when they apply to the people who build things and when they solve current issues and needs…
- 75. What about olderbrowsers?
- 76. What about extreme environmentbrowsers?
- 77. These are validconcerns, but edge cases. And shouldn’t be used as a punishment scenario. 🗞
- 78.
- 79. Used sensibly, JavaScriptis an accessibility benefit. Sometimes the only way to make things accessible. ARIA is not magic. 🕹
- 80.
- 81. It is moreimportant for us to get a grip on the overall quality of the web and our code… 🏅
- 82. Using instead of aURL 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 bashingbad use of JavaScript, let’s embrace and scrutinise new ideas like components and paradigms like functional programming. 🔎
- 84. There is avery cool thing happening right now… 😃
- 85. A lot ofthe next improvements of the web are progressive enhancements of existing JavaScript solutions. 🍾
- 86.
- 87. true: apply oncapture false: apply on bubble false enables event delegation 😊
- 88.
- 89. Service Worker &PWAs https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API 🔧 🦄
- 90. ✅ Create andpublish 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’trely 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’thide 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 tostop thinking in binaries, and consider writing great, secure and failure- aware solutions using each technology to its strengths. 🐝
- 95. Mario evolved -so can the web…
- 96.