back to thedrum.com
Marie Manandise, Senior Web Developer at Studio 24, explains why she believes Progressive Web Apps (PWAs) are the most impactful innovation in web development since CSS media queries.
Pushed ahead by Google, they are likely to replace native mobile apps little by little, just as media queries made mobile sites obsolete. In this article, I’d like to describe a PWA we developed in 2019, the principles we followed during its development, and dissipate some of the confusion around what makes a progressive web app and what doesn’t.
In 2016 we wrote a mobile app for CBM using Angular 2 and Ionic. This is known as a hybrid approach, where the app is coded in JavaScript which is then compiled to a native app. The app was well thought out and users were very satisfied with it. But unfortunately, the technology behind it let us down. Libraries and frameworks fell out of support. People who originally developed the app left and no-one else in the studio could maintain it – the technologies were too niche. We are not a mobile app development agency. What we do best is PHP-based web apps.
Then came Progressive Web Apps. These are web applications that have features of native mobile apps. For example, navigating content whilst offline, ‘installing’ the app (adding its icon to the homescreen for direct access), push notifications.
At their core, they are web applications, based on technologies we are very familiar with (PHP, HTML, CSS, JavaScript), that have an added JavaScript layer to add native-like capabilities to them. The ‘Progressive’ in ‘Progressive web application’ comes refers to the concept of ‘progressive enhancement’. Strip the PWA scripts, and you are left with a web app that works fine (provided you made the right application design decisions). The PWA ‘layer’ is an added benefit that kicks in the most recent browsers.
We, therefore, decided to re-build the CBM app as a Progressive Web App. (Actually, we developed a second app using the same codebase).
The CBM HHoT and i-DRR apps provide resources for humanitarian workers on the field in the form of information cards. Essentially, they are libraries of information cards or pages. For example, a disaster relief worker needs to build a ramp to access a temporary building using a wheelchair. He/she can navigate the app to find the ‘ramp’ card, which describes how to build the ramp and to which dimensions and inclination.
Using PWA techniques, the app user can download the whole site data (cards and pages) and then navigate the whole app when offline, as you would after installing a mobile app.
Even if the user decides not to download the data, visited pages are cached in the browser cacheStorage, a new, persistent cache we can explicitly add and remove content to (we do not have that level of control over the other ‘traditional’ browser cache). Caching pages and other resources such as images greatly improves performance. Visited pages load fast and can still be viewed when offline.
Users can also perform a keyword search to find a card and mark cards as ‘favourites’. They can also add the app to their homescreen.
The websites follow a headless architecture. The content of the apps is managed via a Drupal 8 CMS. We extended the Drupal API to serve the content to a front-end application.
The front-end application is a PHP Symfony web application, using the usual MVC pattern. It receives requests, queries the corresponding data via the Drupal API mentioned above, and serves the right view populated with the content.
And on top of that, there’s the JavaScript application, some of which uses PWA technologies, e.g. a serviceWorker and the cacheStorage. The application does a series of things.
Some are available to a wide range of browsers (even those that don’t support PWA technologies):
Other features are only available in the latest browsers, those that support serviceWorkers and cache storage:
The PWA also deals with updates. When loading the app, it checks whether updates are available from the CMS via the Drupal API. It then either prompts the user to go through an update process if data was downloaded into IndexedDB, or performs a simple background cache clean up if data was not downloaded.
The serviceWorker catches requests before they hit the network. What the serviceWorker does depends on the URL that is requested but for most pages of these apps, this is what it does:
As mentioned above, this behaviour will be adapted to the type of resource requested. For example, search results pages will not be cached. This is to avoid clogging the cacheStorage. API requests to the CMS when checking whether there are updates will go straight to the network.
The front-end application of a headless CMS architecture doesn’t have to be a JS app, let alone a single-page app. Ours is in PHP and keeps all the good old features of the web such as URL-based navigation. Content is accessible even if JS is disabled in the browser or couldn’t load.
A PWA definitely doesn’t have to be a single page app. On the contrary, a JS single page app would not work at all if JS were disabled or could not load in the browser. That would go against the principle of progressive enhancement, which partly defines what a PWA is.
A JavaScript app can be written in Vanilla JS, as opposed to using a framework such as React or Vue. When I mentioned to other developers I had been tasked with building a progressive web app and described the project a little bit, I was asked which JS framework/library/packages I was going to use. That question took me aback more than anything. I will happily use React or any other framework when the need arises. I actually spent some time learning React. I’m yet to come across a situation where it will serve the project purpose. This PWA project is almost entirely custom Vanilla JS. The only library we used is lunrjs to perform the search.
Thorough planning goes further than build tools. As you can see from the ’technical’ description above, some functionalities are available to a wide range of browsers, others only to the latest ones. We designed this application with browser-compatibility in mind. Instead of relying heavily on a transpiler (hello Babel!) we segmented our code according to browser support. For example, none of the IndexedDB-related code uses Promises, as IndexedDB and Promises browser support do not match. On the other hand, code within the serviceWorker makes full use of Promises, because where serviceWorkers are supported, Promises will as well. We did have to use Babel in the end as we wanted to be able to write classes to organise our code (which, in hindsight, we could have done without). So in the end, our build tools are limited to:
Nothing too complicated or fancy, so it is more likely to work on a wide range of browsers, less likely the break down when updating build tools, and more likely to build without any glitches on the machines of other devs. Can I use is your best friend.
No need to work on performance itself if you don’t mess it up in the first place. The best way to ensure performance is to follow a few principles during development as opposed to try and improve performance when you are done. Only load JS files on the page where they are needed. Don’t load whole frameworks if you are only going to use a fraction of them or they do not exactly serve your purpose. Don’t rely too much on build tools that are going to have to expand your code – even if they also minify your JS in the end.
Don’t forget about cache management. It’s important to manage the content of the cacheStorage. This data will accumulate in the users’ browsers and devices. And browsers can be unforgiving when the cache gets saturated. They will remove whole apps in one go according to criteria that are not fully transparent. Make sure you implement cache clean ups when data or your serviceWorker are being updated. Don’t cache anything that doesn’t bring much benefit.
