😠🌧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
💾🌧 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
https://remysharp.com/2016/05/28/state-of-the-gap
These days, we’re looking much better…
The big breakthrough: Service Worker
https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API
🔧
“Websites that have taken all the right vitamins”
– Alex Russel?
https://webmasters.googleblog.com/2016/11/building-indexable-progressive-web-apps.html
🦄🔧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
🦄🔧 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
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
😍
🦄
🎉
🤔But, but but, everybody says the mobile web doesn’t exist! It’s just the web and we make it responsive…
The problem is that eight years after the proposal and five years after HTML5’s “last call”, there are still many basic support issues…
😦
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
Keep users on this page…
https://mathiasbynens.github.io/rel-noopener/https://medium.com/@jitbit/target-blank-the-most-underestimated-vulnerability-ever-96e328301f4c#.mjuw7q3cf
🔓💩
Fix for newer browsers…
https://mathiasbynens.github.io/rel-noopener/https://medium.com/@jitbit/target-blank-the-most-underestimated-vulnerability-ever-96e328301f4c#.mjuw7q3cf
Fix for all browsers…
https://mathiasbynens.github.io/rel-noopener/https://medium.com/@jitbit/target-blank-the-most-underestimated-vulnerability-ever-96e328301f4c#.mjuw7q3cf
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
Supporting the past balancing act…
Use powerful language
additions…
Don’t block out older browsers and
environments…
Progressive enhancement balancing act
Control the UX with JavaScript and own
the failure cases.
Rely on the browser to give a “working”
experience.
JavaScript can’t be trusted and can be turned off.
💣 🔨Everybody has JavaScript, and we can do everything with it!
However, subsequently, you can do a lot with JavaScript that is needed on mobile and can’t be done in HTML/CSS.
😊
✏ 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
❤📲
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
📦
Used sensibly, JavaScript is an accessibility boost. Sometimes the only way to make things accessible. ARIA is not magic.
🕹
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…
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)">
🆙🔧 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…
🛠
🔧 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.
✅ 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…
🙂 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…
⚠ 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…
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…
We have to stop thinking in binaries, and consider writing great, secure and failure-aware solutions using each technology to its strengths.
🐝