Progressive Web Applications – a lengthier introduction for designers and developers
You stroll into your apartment, exhausted from work, whip out your tablet, and, with a bond stronger than superglue, you and the couch become one. You meander through social media feeds, flip through the latest headlines on Flipboard, and your better half video chats with you about plans for a sizzling barbecue. All the while, red notifications dart across your screen like shooting stars. You revel in the lightning-fast loading times, and the apps feel as if they’re magically fused to your fingertips. The year is 2020, and what you’re experiencing is all happening within your tablet’s browser – welcome to the world of Progressive Web Applications!
The online industry has always wrestled for a spot on the couch and a slice of the user’s “attention span” – and it’s been a battle waged on two fronts. Classic web applications are accessible on all devices, shareable, linkable, based on open standards, always up-to-date, and handle everyday tasks like printing, saving articles, online shopping, and filling out forms flawlessly.
On the other hand, native apps (iOS, Android, etc.) are speedy, powerful, have access to cameras, 3D, background processing, and can even receive voice commands (Hey Siri, what’s the situation in the fridge?!).
The differences in development and technology are vast, with native iOS apps typically produced by teams specializing in the iOS ecosystem. The same goes for Android. These native apps undergo app store distribution, versioning, and updates, while classic web applications sidestep those development hurdles (and headaches).
These divergent development approaches and technological capabilities have given rise to two major application camps – native vs. web. Google (weaving its web for AdWords-fueled ecosystem) started promoting the PWA concept, constructing a bridge between these two worlds.
The goal on paper is simple – make web applications behave like native ones while endowing them with the technological capabilities traditionally reserved for native apps. These Progressive Web Applications (a name coined by Francis Berriman) employ new standardized web technologies to achieve the desired interactivity:
- JavaScript Service Workers (offline functionality, client-side caching, push notifications)
- Web App Manifest (installation on Home Screen, Fullscreen mode)
- Credentials Management API
- Payment Request API
- Beacon API
- WebShare API
- WebVR API (experimental)
- Other new W3C technologies that enrich the web experience (see https://caniuse.com for a more detailed list and browser support)
Broken down to their essentials, PWAs are actually a collection of HTML, CSS, and JS files, designed following mobile-first responsive principles. Developers can use the aforementioned technologies as needed. For instance, the Web App Manifest is a descriptive file outlining the icon, name, or starting URL of a web application, but it’s not of particular technological interest.
The topic of responsive web design has already been thoroughly explored by the Blagonić brothers in the September edition of Mreža. The text directly relates to the design and user experience of responsive web, which is crucial for creating PWA concepts. So, let’s shift our focus towards Service Workers – the technological core of Progressive Web Applications.
Service Workers, Unite!
We don’t even have to set our interactive couch story in 2020 to experience the possibilities of PWAs. All it takes is turning on an Android smartphone to see what PWAs bring to the tempestuous world of web development. These apps want to send you push notifications, fetch contacts from your phone, or use the camera for a video call. PWAs aim to be useful even without an internet connection, and they want to work stealthily in the background of your device. All of this is made possible by the Service Worker – a JavaScript file that operates continuously in a separate browser thread, independent of both the website and user interactions.
At its core, a Service Worker is a programmable network proxy – a JavaScript module that allows developers to define what happens between a web application and the network or the internet. In doing so, the developer can cache static files, periodically sync the web page with background services, utilize GeoFencing, or enable users to work with the PWA in offline mode.
Digging deeper, Service Workers rely on “Promises” JavaScript objects, which resolve upon the completion of asynchronous network calls. The technology is supported by all relevant browsers, and the background and history of “Promises” development can be traced back to AJAX, XML, and JSON.
A unique feature of Service Workers is their support for the so-called Install event (which occurs upon the first visit to a Progressive Web Application). Developers can use this event to install all the resources a user needs for the application to function as intended. More importantly, the developer should record the cache version, or the PWA version currently in use, during this caching event.
Service Workers enable web applications to behave like native ones because they don’t rely on the classic HTTP (click > request > response > render) mode of operation. Imagine the following situations: you open your mobile web browser, and your favorite news portal displays the latest news tailored just for you without any need for an internet connection. Or perhaps an eCommerce example, where the online store you bought your new suit from sends you a push notification offering a coupon for purchasing a belt or pants at a 25% discount because you’re walking by their physical store (GeoFencing).
A trivial example includes offline functionality, where users can download parts of the content for later consumption. Offline functionality is crucial for all video games built on PWA concepts.
Caching also enables a more “engineering-focused aspect” of Progressive Web App development, such as faster loading times, responsiveness, and explosive usability – traditionally reserved for native apps only. Twitter pioneered the use of PWA capabilities and developed Twitter Lite, which weighs less than a megabyte. Similar endeavors are driven by simple business experience – a faster app means more conversions and higher revenue. Loading milliseconds are absolutely “everything” when it comes to mobile user experiences.
Research indicates that 53% of users abandon content consumption if loading takes longer than three seconds! More than half of users! The facts are even more striking in countries with weak internet connections.
The described Promises and Service Worker technologies serve as the foundation that enables the PWA revolution. However, while Promises enjoy support in all browsers, Service Workers are still being held back by Apple. Why?
Apple and Google; Macbeth and Macduff
Progressiveness is a nebulous term, prone to being attached to any technology, not just the one I’m selling you right now. Web designers and developers have been continuously “sold” on various technologies – Flash, Silverlight, Java, .NET, PHP, Figma, Sketch, PSD, React, Vue, Angular, Gulp, Grunt… vast arrays of terms originating from the camps of Microsoft, Facebook, Adobe, and Google.
Each camp nurtures its ecosystem, and the development of app stores, app distribution, and monetization has led to even more significant closures of technologies for native app development. For example, iOS app development is done on a Mac through the XCODE IDE, and certified distribution is only possible through the Apple App Store. In-app purchases, Apple Pay, and other monetization schemes are exclusively controlled by Apple. Android is somewhat more open, but the concept is the same – developers use Java (or modern Kotlin, which can conveniently be transpiled to JavaScript for the web), Android Studio, and distribution through Google Play or the Amazon store.
Even mobile app design guidelines differ. Not only is the engineering different, but designers are also versed in different camps. And that creates a significant problem for innovators and investors. Namely, mobile app development has always had to be budgeted twice – one part of the budget for the iOS team and another part of the budget for the Android team. Somewhere around 50% of the Gantt chart, the client remembers that they need a mobile responsive web as well, so the budget is increased for an additional front-end team.
Engineers who dream of a magical tool for deploying code to all native platforms have attempted to tackle this problem. Adobe had Air, Facebook pushes React Native, Apache supports Cordova, and Xamarin is also lurking around to become the king of all platforms. However, all these hybrid solutions have the same set of issues:
- Developers must produce a layer above the existing native platform.
- The IT system architecture depends on both the hybrid and native platforms.
- Hybrid systems have never been able to utilize 100% of the native platform’s functionality.
- App maintenance and development depend on the development of both the hybrid and native platforms.
- Hybrid platforms have corporate owners (subject to various market shifts).
A few examples illustrate these issues. Adobe Air (Flash) was a typical victim of the corporate war between Adobe and Apple, with Steve Jobs’ iconic letter marking the beginning of the end for that web technology. Consequently, developers had to switch from ActionScript 3.0 to JavaScript or perhaps Swift, which is quite similar.
A more recent example concerns Facebook and its React framework. Apache has banned the use of Facebook’s open-source modules (such as React) in its products, considering the license not “open-source” enough. More specifically, Facebook’s version of the BSD license is stricter to protect against patent trolls, and in this case, Facebook did not want to change its BSD license version. As a result, some organizations stopped using React in their applications, undoubtedly frustrating their developers who spent nights developing React-based apps.
Even Matt Mullenweg, co-founder of WordPress, abandoned React as a tool for developing the new WordPress editor (code-named Gutenberg). He explained to the community that they must find a replacement UI library and refactor a significant portion of the already developed code (more on the topic in the Vue vs. React debate).
Corporations, hybrid approaches, various tools, and an uncertain future already complicate the strained cost of mobile app development. PWA is a beacon of light in this foggy tunnel, precisely because it avoids such issues, and here’s why:
- PWAs are based on open and standardized W3C standards
- Code and services are developed using familiar and tried-and-true web technologies: HTML / CSS / JS
- To function, web apps only need a browser
- PWAs can be displayed on any device, browser, or OS
That last point gets a bit tricky – Service Workers are currently supported in Chrome, Firefox, EDGE, and Opera, but not in Safari. What’s the holdup?
In developed countries, Safari gobbles up 33% of the market share, and Apple is fighting tooth and nail to keep interactive and robust experiences on its App Store platform. This seemingly deliberate slow support appears to be a strategic business decision, similar to their stance on Flash, where Apple blocked video flash games and advanced payment experiences outside of their In-app purchases platform.
This time, Apple is up against Android, the W3C, and the internet itself, which led to them approving work on Service Workers in August 2017. This is excellent news for web standards, as it lays the foundation for PWA technology on Safari devices and ushers in a new wave of fresh web solutions for both mobile camps – iOS + Android.
How to start with PWA (for designers)
Interactive design for Progressive Web Applications is more complex than that of traditional web applications. In such projects, designers truly need to collaborate with developers to create an interactive experience, as backend services, Service Workers, and various UI libraries significantly influence the impression the app leaves on users.
The entire OFFLINE experience is the first thing to consider. Secondly, the development team needs to account for user flows on slow and fast internet connections. This adds new dimensions to the already complicated mobile-first responsive design. Variables designers and developers need to pay attention to include:
- Device type: smartphone, tablet, phablet, watch, laptop, full desktop, TV, car screen
- Orientation: horizontal, vertical, square
- Screen size (pixels): width X height
- Screen density: Dots Per Pixel (dppx), the number of device pixels per CSS pixel (e.g., Retina devices have a value of 2).
- Internet connection speed: 2G, 3G, 4G…
- Usage context: on-the-go, static-home, static-office, car, commuting…
- Connection status: OFFLINE, ONLINE
Considering these variables, there are countless user flows! At the end of the day, the project’s business aspect must be taken into account, and designers and analysts will determine the level of granularity for UX/UI.
Most design teams can immediately start with small progressive shifts. For example, if you have a web form that requires a postal code (ZIP Code) entry, enable the Geolocation API instead of having the user manually input that value. Such small changes are in the spirit of progressive web applications. Another, more significant example of progressiveness is the way resources and content are loaded. This topic is related to loading speed, the impression of speed, and the robustness of applications. Designers and engineers have the most work to do in this area.
Mobile app users have a short attention span and are constantly exposed to distractions. The designer’s task is to keep the user engaged at all times, offering a meaningful and high-quality experience every second – either through UI feedback or content. Progressive loading, proper animations, and well-structured loading architecture contribute to users perceiving a progressive app as a native one.
Chrome Developer tools and Google Lighthouse can help by providing detailed loading metrics to designers, such as First Meaningful Paint, Time To Interactive, and Fully Loaded events. Analyzing these metrics is the first thing a designer should learn.
How to start with PWA (for developers)
Currently, there is a mini JavaScript battle happening in the front-end world, somewhat related to PWA development. Developers are increasingly building “JS only” mobile-first web applications that communicate with backend services via REST APIs. This moves them away from the traditional choice of whether to create a web app using PHP or ASP.NET technologies. This goes hand in hand with the described PWA concepts and opens up a significant topic: which JS framework should be used for developing PWA applications?
The JavaScript framework market is crowded, with options such as Angular, Oracle JET, Ember, Knockout, and the leaders of the pack, Vue and React. The problem is that Vue and React are more similar than different:
- They are JS libraries for creating user interfaces
- They are fast and “lightweight” (in terms of loading impact)
- They use Virtual DOM
- Both have separate libraries for managing app state and routes
- Their architecture is component-based
The main difference is that React uses JSX syntax (declarative XML syntax for defining interfaces), while Vue uses a “standard” HTML template/JS approach.
Following links can help you with the analysis:
- Switching From React To Vue.js (Anthony Gore) – https://goo.gl/Lzehkd
- Vue comparison (Vue team) – https://goo.gl/DygpZ9
- Opinions & Debate: Vue.js vs. React.js (Pavel Malos) – https://goo.gl/fcco7e
- Yes, That Web Project Should Be a PWA (Aaron Gustafson) – https://goo.gl/hLFYnW
- Escaping Tabs Without Losing Our Soul (Alex Russell, husband of Frances Berriman, explains how he and Frances came up with the PWA concept) – https://goo.gl/PySRJE
- React or Vue: Which Javascript UI Library Should You Be Using? (Anthony Gore) – https://goo.gl/j1vNmT
A rough summary of these articles reveals the following advantages of Vue:
- Flexible template and rendering function options
- Simplicity of syntax
- Ease of project setup (insert one line of code and start writing :))
- Slightly faster rendering and smaller file size
- Clearer usage license than React’s
React’s advantages are more apparent in larger applications:
- Better for larger projects with more robust and “tested” code
- Ability to create web and hybrid native apps (React Native)
- Larger ecosystem with better support, documentation, and tools
Choosing one of these technologies will mark the beginning of a PWA project, so consider all possible articles and books describing the similarities and differences between the two frameworks. All in all, the work of designers, backend, and front-end developers will depend on your choice. Meaning – thread carefully 🙂
p.s. this article was first published inside Mreža print magazine on February 2018
Ex QBASIC developer that ventured into a web world in 2007. Leading a team of like-minded Open Source aficionados that love design, code and a pinch of BBQ. Currently writing a book that explains why ‘coding is the easier part’ of our field.
