Javascript

The Renaissance of PWAs

Dario Djuric
5 min read
The Renaissance of PWAs
This article was written over 18 months ago and may contain information that is out of date. Some content may still be relevant, but please refer to official documentation for the latest information.

What Are PWAs?

Progressive Web Apps, or PWAs, are not a new concept. In fact, they have been around for years, and have been adopted by companies such as Starbucks, Uber, Tinder, and Spotify. Here at This Dot, we have written numerous blog posts on PWAs. PWAs are essentially web applications that utilize modern web technologies to deliver a user experience akin to native apps. They can work offline, send push notifications, and even be added to a user's home screen, thus blurring the boundaries between web and native apps.

PWAs are built using standard web technologies like HTML, CSS, and JavaScript. However, they leverage advanced web APIs to deliver enhanced capabilities. Most web apps can be transformed into PWAs by incorporating certain features and adhering to standards. The keystones of PWAs are the service worker and the web app manifest. Service workers enable offline operation and background syncing by acting as network proxies, managing requests programmatically. The web app manifest, on the other hand, gives the PWA a native-like presence on the user's device, specifying its appearance when installed.

Looking Back

The concept of PWAs was introduced by Google engineers Alex Russell and Frances Berriman in 2015, even though Steve Jobs had already discussed the idea of web apps that resembled and behaved like native apps as early as 2007. However, despite the widespread adoption of PWAs over the years, Apple's approach to PWAs drastically changed after Steve Jobs' 2007 presentation, distinguishing it from other tech giants such as Google and Microsoft. As a leader in technological innovation, Apple was notably slower in adopting PWA technology, much of which can be attributed to its business model and the ecosystem it built around the App Store.

For example, Safari, Apple's web browser, has historically been slow to adopt the latest web standards and APIs crucial for PWAs. Features such as push notifications, background sync, and access to certain hardware functionalities were unsupported or only partially supported for a long time. As a result, the PWA experience on iOS/iPadOS was not - and to some extent, still isn't - on par with that provided by Android.

Despite the varying degrees of support from different vendors, PWAs have seen a significant increase in adoption since 2015, both by businesses and users, due to their cross-platform nature, offline capabilities, and the enhanced user experience they offer. Major corporations like Twitter, Pinterest, and Alibaba have launched PWAs, leading to substantial increases in user engagement and session duration. For instance, according to a 2017 Pinterest case study, Pinterest's PWA led to a 60% increase in core engagements and a 44% increase in user-generated ad revenue.

Google and Microsoft have also championed this technology, integrating more PWA support into their platforms. Google highlighted the importance of PWAs for the mobile web, while Microsoft sought to populate its Windows Store with PWAs.

Apple's Shift Towards PWAs

Despite slower adoption and limited support, Apple isn't completely dismissing PWAs. Recent updates have indicated some promising improvements in PWA capabilities on both iOS/iPadOS and MacOS. For instance, in iOS/iPadOS 16 released last year, Apple added notifications for Home Screen web apps, utilizing the Web Push standard with support for badging. They also included an API for iOS/iPadOS browsers to facilitate the 'Add to Home Screen' feature.

The forthcoming Safari 17 and MacOS Sonoma releases, announced at June's WWDC, promise even more significant changes, most notably:

Installing Web Apps on MacOS, iOS, and iPadOS

Any web app, not just PWAs, can now be added to the MacOS dock from the File menu. Once added, these web apps will open in their own window and integrate with operating system features such as the Stage Manager, Screen Time, Notifications, and Focus. They will also have their own isolated storage, and any cookies present in the Safari browser for that web app at the time of installation will be transferred to this isolated storage. This means many users will not need to re-authenticate to web apps after installing them locally.

PWAs, in particular, can control the appearance and behavior of the installed web app via the PWA manifest. For instance, if your web app already includes navigation controls, or if they're not necessary in the context of the app, you can manage whether the navigation buttons are displayed by setting the display configuration option in the manifest to standalone. The display option will also be taken into consideration in iOS/iPadOS, where standalone web apps will become Home Screen web apps. These apps offer a standalone, app-like experience on iOS, complete with separate cookies and storage from the browser, and improved notification handling.

Improved Notifications

Apple initially added support for notifications in iOS/iPadOS 16, but Safari 17 and MacOS Sonoma take it a step further. If you've already implemented Web Push according to web standards, then push notifications should work for your web page as a web app on Mac without any additional effort. Moreover, the silent property is now taken into account, and there are several improvements to the Notifications API to enhance its reliability. These recent updates put the support for notifications on Mac on par with iOS/iPadOS, including support for badging, and seamless integration with the Focus mode.

Improved API

Over the past year, Apple has also introduced several other API-level improvements. The enhancements to the User Activation API aid in determining whether a function that depends on user activation, such as requesting permission to send notifications, is called. Safari 16 updated the un-prefixed Fullscreen API, and introduced preliminary support for the Screen Orientation API. Safari 17 in particular has improved support for the Storage API and added support for ReadableStream.

The Renaissance of PWAs?

With the new PWA-related features in the Apple ecosystem, it's hard not to wonder if we are witnessing a renaissance of PWAs. Initially praised for their ability to leverage web technology to create app-like experiences, PWAs went through a period of relative stagnation, especially on Apple's platforms. For a time, Apple was noticeably more conservative in their implementation of PWA features. However, their recent bolstering of PWA support in Safari signals a significant shift, aligning the browser with other major platforms such as Google Chrome and Microsoft Edge, both of which have long supported PWAs.

The implications of this shift are profound. This widespread and robust support for PWAs across all major platforms could effectively reduce the gap between web applications and native applications. PWAs, with their promise of a single, consistent experience across all devices, could become the preferred choice for businesses and developers. The cost-effectiveness of developing and maintaining one PWA versus separate applications for multiple platforms is an undeniable benefit. The fact that all these platforms are now heavily supporting PWAs might suggest an industry-wide shift toward a more unified and simplified development paradigm, hinting that indeed, we could be on the verge of a PWA renaissance.

About the author

Dario Djuric

Dario Djuric

Senior Software Engineer

Dario is a full-stack engineer who has spent most of his career doing enterprise Java projects. He has always had a hidden passion for frontend, though -- and he is now able to pursue that passion at This Dot. He spends most of his free time with his two sons, but occasionally, he manages to squeeze in some casual sports activities such as jogging, cycling, and soccer.

Keep reading

View all posts →

WebGL Morph Targets and Ginger: Modernizing for Today's Web

WebGL Morph Targets and Ginger: Modernizing for Today's Web Ginger is a morph target demo that was initially written in 2011 for chrome experiments, and then rewritten to work as progressive web app in early 2016. In essence, Ginger is a customizable head that uses a slider to tweak various facial features, much like a character customization system one would find in a video game. It also supports taking screenshots, and generating share links that can be used to share your creation with others. The rewrite in 2016 focused on improving performance, and supporting modern web features. Notable improvements were made in the following areas: 1. Utilizing HTTP/2 multiplexing to load model data concurrently, and efficiently. 2. Utilize manifest.json for "Add to Homescreen" capability. 3. Offering a full offline experience with service workers. 4. Performance improvements from the previous version. We inherited the project with our recent acquisition of Stickman Ventures, and thought it appropriate to showcase. Since it was rewritten in 2016, Ginger hasn't been touched, and has fallen into neglect, though it still worked fine in modern browsers. It was using an old version of Polymer 2 which has long since fallen out of use. The Refactor The first order of business was replacing Polymer 2 usage with something more modern. Polymer 2 was bleeding edge at the time, and used many proposed browser features that have since been adopted or dropped in favor for other standards (modules vs HTML imports). Replacing Polymer with lit html To reduce friction, we opted to refactor Ginger's web components to use lit html from the Polymer Project. Lit isn't a framework necessarily, it just makes it easier to write standard web components that are efficient, and work across all major browsers. Transitioning from Polymer to lit was not a very complicated process, as they both use the same element lifecycle. The most notable difference was the transition from HTML imports to modules. With Polymer 2, elements are defined inside of HTML files, and are imported directly using HTML imports; however lit html allows defining elements using a modern class based approach. With lit html, it's very easy to define custom elements by extending off of the LitElement class, and registering it using either customElements.define or the decorator. We then use rollup.js and babel to create a bundle that works well across browsers. Using Workbox to Support Offline Usage Ginger is able to work completely offline thanks to its use of service workers. The previous iteration of Ginger used a service worker that came from platinum elements. Platinum elements made it possible to add offline capabilities to an application with very little effort. However, they've been deprecated in favor of workbox and sw toolbox. We chose to go with workbox as it supports all of the features that we need, and I was already familiar with it. The service worker uses caching strategies to cache images, fonts, code and model data. Data that won't change often or at all uses the "cache first" strategy, while code uses the "stale while revalidate" strategy. The cache first strategy will grab the requested file from the cache if it exists, and do nothing else. The stale while revalidate strategy will return the cached data similar to the cache first strategy; however, it will also download a newer version from the server in the background. Here's some basic examples taken directly from Ginger. You can find out more about other caching strategies that workbox offers in their docs. Closing You can find Ginger's source code on Github, and it's available under an Apache 2 license. The Ginger model was created, and is copyright of David Steele. This work is licensed under a Creative Commons Attribution NonCommercial 4.0 International License....

Jamie Kuppens3 mins
PWAHTMLJavaScript

Announcing Free Trainings - Progressive Web Apps and Using NgUpgrade for your Angular Migration

Less than two weeks after wrapping up our inaugural JavaScript Marathon, we are thrilled to share two brand new free trainings from the team at This Dot Labs available for you to watch anytime. In Introduction to PWAs and Service Workers, Software Engineer Pato Vargas will walk you through creating your first PWA, implementing push notifications, testing your features, and using Firebase. "I really enjoyed working on this training," says Vargas, "learning service workers is important for any JavaScript developer, so this training appeals to anyone writing JavaScript!" Software Engineer, Frederick Prijk, is also excited to present his new training series, Upgrading AngularJS to Angular Using NgUpgrade, which walks you through a simple AngularJS to Angular migration in just over an hour! You can find these trainings, and all other past trainings, including those presented in the JavaScript Marathon series, by visiting our free resources page! Introducing a new technology to your enterprise development team, or having trouble with an existing technology? Learn more about how This Dot Labs can tailor a training program to your team by chatting with us, or by reviewing the trainings we already offer!...

This Dot1 min
AngularJavaScriptPWA

History of Mobile Web Development and the rise of PWA

In this post, we are going to cover the history of Mobile Development, provide insightful details of current trends and uses of Progressive Web App development...

Simone Cuomo10 mins
PWAMobile Web Development

How to do social Media sharing in your PWA

PWA using Web Share API Have you wondered how you can make a use of the "social" sharing API PWA? You know, when you want to share something, and it gives you the option to share via email, Twitter, Instagram, etc? Well, it's actually very easy! Take a look at the demo app to test it on your device. LIVE DEMO https://pwa share api.firebaseapp.com/ About the project I have built the sample project that can be found in this repo. In this project, you can see how I added the share functionality to the PWA , but you don't need a service worker or a PWA to add this functionality. I added it to this project because I wanted to show you how to do it specifically in a PWA, but you can add my code to any web app easily! Web Share API The bland definition of what a WSA is: The Web Share API is meant to help developers implement sharing functionality into their apps or websites, but using the device’s native sharing capabilities instead of having to resort to scripts from the individual social platforms and DIY implementations. The API surface is a simple as it gets. alligator.io The Web Share API has two share methods: share() and canShare() . The ShareData dictionary of the web share v1 consists of several optional members: text member : Arbitrary text that forms the body of the message being shared. title member : The title of the document being shared. May be ignored by the target. url member : A URL string referring to a resource being shared. The canShare() method contains an extra field which is the files property. files member : A File array referring to files being shared. To read more about it, check out this link So let's have a look at how it actually works. First, let's collect data to make our ShareData dictionary. Then, after we have declared what we want to share, we can use it in the .share() method. We can put that inside of a function, called onShare() , for example. Then pass the onShare() as a click handler to the share button. If you want to take it to the next level, you can check to make sure the web share api is supported by your browser. Your code will look as follows: If you want to use the canShare() , to send files, your code might look like this Browser Support If you go to canisue.com, you can see that browser's support for the share() method. Pretty much every major browser supports it. What about the canShare() method? Not as good as the share() method, hopefully it gets to more browsers soon. Resources https://www.w3.org/TR/web share/#sharedata dictionary https://alligator.io/js/web share api/ https://web.dev/web share/...

Pato Vargas3 mins
UXJavaScriptPWA