BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Learning Progressive Web Apps - Book Review and Q&A

Learning Progressive Web Apps - Book Review and Q&A

Bookmarks

Key Takeaways

  • Building native apps for several target platforms ((desktop computers, smartphones, televisions, etc.) may be time-consuming and expensive.
  • Progressive Web Applications allows developers to reuse standard web technologies to create applications that may run cross-platform, while still narrowing the gap with native applications in capabilities and user experience.
  • The book *Learning Progressive Web Apps* presents a gentle but thorough introduction to PWAs, so developers may build modern web applications leveraging service workers.
  • The book introduces web manifests and service workers through three practical PWAs using plain HTML, JavaScript and CSS, and does not require any knowledge of a front-end framework.
  • While relatively new to the scene, PWAs have already occupied a significant market share of mobile applications. As the web APIs grow to encompass more native features, PWAs are expected to further grow in importance.

The book Learning Progressive Web Apps by John M. Wargo explores the benefits and importance of progressive web apps (PWAs) and how developers can leverage PWAs to enhance user experience on multiple devices. The book deals in detail with web manifests and service workers, the latter providing the core capabilities that differentiates PWAs from mere web applications. The book contains plenty of code samples and runs the reader through creating three PWAs, each of which illustrates specific PWA features.

InfoQ readers can download a sample chapter of the book here.

InfoQ interviewed Wargo about the book.

InfoQ: Can you tell our readers about yourself? What drove you to write this book?

John M. Wargo: I've been involved with software development for a long time (more than 30 years) and I've had many roles as a developer, product manager, consultant, etc.

For the last 15 years or so, I specialized in mobile software development (building apps for mobile phones). I've never been a very good native mobile app developer, but as I experimented with different development approaches, I discovered I liked best the approaches that allowed me to leverage my web development skills. I ended up spending many years in the Apache Cordova community and ultimately wrote four books on the topic. The Cordova community always set as its goal making themselves obsolete; saying that when browsers offered most of the capabilities required by mobile applications, then the Cordova project would no longer be needed. Over the years, the browser, and especially the mobile browser, got a lot more capable - delivering native-like capabilities in the browser. With that in place, the last few things needed to make the web a first class citizen on devices are the capabilities provided through service workers and web app manifests - the core capabilities that make a PWA a PWA.

So, essentially, this book is just the natural extension of many of my previous books - the natural progression for the Apache Cordova developer. However, the book also allowed me to target a wider audience since the technologies that make a web app a PWA are very powerful capabilities for any web developer to use to make their web apps more app-like.

InfoQ: Some analysts identify three options for developers targeting handheld devices: native apps, web apps, and PWAs. What distinguishes a PWA from a regular web app? What do they achieve that regular web apps do not? What can native apps achieve that PWAs cannot? What make PWAs progressive?

Wargo: Actually, I used to be an analyst at Forrester Research, and when I was there, I wrote about a lot more options for mobile developers.

The biggest issues for mobile developers are that native mobile development is hard, really hard. Especially when your app must target multiple device platforms (Android and iOS for example) since each platform uses a completely different set of technologies from concept to delivery. Because of this, the market over the years looked for ways to make this easier for developers and companies to deliver mobile apps.

The market (community and software companies) delivered a lot of different approaches for delivering mobile apps. The ones you listed, although I'd argue it should be only native and web apps as a starting point (a PWA is just a web app with some extra code in it, and I'll explain more later), plus things like JavaScript-driven native (Appcelerator Titanium, React Native, NativeScript, etc.), adjacent native apps (Flutter, Xamarin, etc.), and hybrid apps (Apache Cordova, Adobe PhoneGap, Ionic Capacitor, etc.).

There is even a whole other class of tools available called mobile application development platforms (MADP), which provide special tooling to make it easy for developers (or even non-developers) to build mobile apps using a special design tool that spits out native apps using the technologies listed in the previous paragraph.

All of this is stuff that consumed most of my career for the last 15 years.

PWAs solve a problem most of those other solutions can't (although MADP does solve many). If you're building an app, especially a non-enterprise app, that targets mobile users, you're likely going to build an app the user installs on the device plus a web app customers/users can use when they don't have the app installed. Web users can bookmark apps on their device, but how many of you ever use bookmarked pages in a mobile browser? I never do. Users can also copy a web app icon to their home page, but, as I show in the book, that's a subpar user experience.

There are two views on this, but for me PWAs are essentially web apps with some additional capabilities in them that make them act more like native mobile apps.

The use of “progressive” in the name is a shout out to the progressive enhancement approach to web development popularized in the early 2000s. In this context it means that a web app is progressively enhanced based on how much of the technology is supported in the browser. When your PWA runs on an older browser, one that doesn't support all or any of the PWA capabilities, it works just like any non-PWA. However, when the browser supports the core PWA technologies, additional capabilities unlock in the app depending on what code you have therein.

PWAs allow you to register a chunk of JavaScript code called a service worker (SW) that runs in the browser context (as opposed to the app context). With a SW in place, your web app can do things a normal web app (a non-PWA) can't. Things like receive push notifications, enable an app to work while offline, even sync updated data with the server in the background when the app isn't running. SWs, along with a web app manifest file, also enable a more streamlined, app-controlled approach to installing the app on the user's desktop or home screen.

As I said, PWAs make a web app work more like a native mobile app, but there are still a lot of things native apps can do that web apps just can't. Over the years, the mobile browser got more and more native capabilities - like the ability to interact with the device compass or accelerometer, file system, geolocation, local storage, etc. - and its the addition of these capabilities that ultimately made Apache Cordova obsolete. Native apps can just do more - true background processing, access local APIs the browser can't, deal with more on-device events, and more. 

InfoQ: You say in the book that "this is a book about service workers". What are service workers, how do they relate to PWAs and why did you choose to focus on them?

Wargo: A service worker is a block of code a web app registers with the browser and runs in the browser's context (until its deactivated). This in-browser context lets the code do things a web app can't do very well.

It enables web apps to register for, and process, push notifications. It also enables the web app to efficiently cache resources (like HTML, CSS, JavaScript files) so the web app has access to them when the browser loses network connectivity. If the web app updates some data while offline, a SW can queue up the data and deliver it later when the device reconnects to the network. These capabilities are things native mobile apps can do all day, but only work in web apps because of SWs.

I chose to focus on them because they're core to what makes a PWA a PWA. You can't have a PWA (although some would argue against this) without a service worker.

InfoQ: The book takes the user through understanding and writing PWAs with three concrete sample web apps. I liked the fact that none of those applications are overly fancy, nor require any framework knowledge. Focus is kept on the PWA side of things rather than the application features or framework particulars. Can you run us quickly through what those applications are and what each application is designed to teach the reader?

Wargo: Yeah, this was a different approach for me. In my earlier mobile development books, I spent all my time talking about the technology, tools, and how to use each API/capability. For this book, I decided to take a more code-based approach - skipping any discussion of tooling (until the very end) and getting as much code in there as possible. I originally planned to focus on a single app, and progressively enhance the app as we progressed together through the chapters. As I started writing, I quickly realized that I could deliver higher impact by splitting the single, monolithic app into smaller parts.

Thank you too for noticing that the apps are deliberately focused on core technologies (HTML, JavaScript, and CSS, which I never talk about). I didn't want to obscure the core content by implementing the framework of the day, or a lot of tight but confusing JavaScript code. I made the examples as simple and as clear as I could, and I think readers really benefit from that.

Most PWA books and articles cover app installation at the end of the content, digging deep into service workers before finally getting around to how to use them to install the app on the user's device. Since I wanted to go deep into service workers, I decided to get installation out of the way early, and I needed a very simple single-page app to use for this purpose. So I quickly coded up a small, simple tip calculator app and my friend Scott Good made it beautiful with some artful application of CSS. In the book, I use the app to illustrate how to write the code to manage the installation process. Since the app is so small, and has very little JavaScript code in it, it's really easy to see the code I want you to see as you're working through the chapter.

The app's online today, so you can see it in action as you compare what I have against your code as you work through the chapter.

The second app is the PWA News site located here. The chapters that use this app cover resource caching and caching strategies, so I needed an app that had lots of files and data to cache. For this, Scott and I created a simple news site that pulls PWA articles from the Internet using the free Bing Web Search API - the app works while online or offline, demonstrating the core capabilities of service workers. I also use the Feedback area of this app/site to demonstrate how to use the background sync capabilities of PWAs to upload data to a server when a device comes back into network coverage.

For the last app, I needed something to demonstrate how to register for and process browser notifications (push notifications). I originally planned on adding some lame register for notifications option to the PWA News site. As I started thinking through it, I realized that approach was too contrived, that nobody would ever want to receive notifications from my news site and I didn't want to pay for the server processing to manage it. Instead, I decided to create a simple two-part app that cleanly and simply demonstrates everything you need to know about how to register for, send, and process browser notifications. It's a clean, simple, and concise way to show just the code you need here and nothing else.

I also discovered that this last sample app was the perfect app to use to demonstrate how to send messages between a web app and a service worker. In the book, I demonstrate how to make a change in one browser window and use a service worker to update all other windows running the same app. It's an amazing demo.

InfoQ: Chapter 1 traces the origin of PWAs back to the iPhone and developers lobbying Apple for more power than that offered by just the browser. The book tells the story with interesting details that I discovered for the first time and enjoyed reading. The chapter also explains the growing market share of PWAs and the existing options to package them for distribution on the same application stores as native apps.

Chapter 2 deals with web app manifests and explains how they are a necessary but insufficient part of the cocktail that enables offline installation. The reader will get acquainted with the criteria used by a browser to decide whether an app is installable and the properties in the manifest file that define what the app looks like when it’s installed, runs, and more. The reader will get important tips for troubleshooting and tooling. The reader will also install the first of the three PWAs used in the book: the tip calculator. Did I forget anything?

Wargo: No, not really - I think you captured it. In Chapter 1 though, I make the case that Apple failed dramatically to understand what developers wanted. Even today, Apple lags far, far behind other browsers and OSes in support for PWAs.

InfoQ: In Chapter 3 to Chapter 7, you introduce in earnest SWs and their use cases. You use two PWAs to showcase service workers: the PWA News, available online, is used in Chapter 3 to Chapter 5 and a third PWA serves to showcase push notifications and communications between the service worker and the application core. The aforementioned five chapters are the main part of the book. What will the reader be able to do with SW after completing these chapters?

Wargo: You're right, those chapters are the core and they really contain everything I think you need to know to build your own PWAs. Developers who understand SWService Workers and everything they can do will be able to do amazing things in their web apps.

InfoQ: The last two chapters deal with the assessment, automation, and deployment of PWAs. What is the outlook for PWA? What challenges remain to be overcome? Distribution? Platform differences? Native APIs not available in the browser? Performance? Business model?

Wargo: Aaah, yes! Those are very important questions.

I deliberately moved the tooling chapters to the end of the book since I write my books in chapter order and I knew the tooling would change and I wanted the most up- to- date information in the book. Google has enhanced their PWA installation UI and releaseds the BubbleWrap CLI, which enables Android developers to more easily package a PWA into a Trusted Web Activity (TWA). Microsoft's PWA Builder started work on a PWA Starter project making it easier for developers to get started coding PWAs.

As I mentioned in the book, aAnalyst firm Gartner predicted a while back that 50% of consumer-facing apps would be PWAs this year. We're almost halfway through the year and I'm seeing evidence of this. For example, Microsoft (my employer, although I'm moving to GitHub July 1st) released PWA versions of OneDrive and Outlook. Those are BIG apps, built by big teams. That should easily solidify anyone's view that PWAs are useful, stable, and capable of doing both big and small things.

This isn't edge or rising technology, it's here now.

The future looks like this: Google and most of the other browser vendors will continue to innovate and add new, native-like capabilities in their browsers. Count on it and get onboard now. Apple will continue to lag in their support for PWAs; mostly, I think, because they don't like others telling them what to do.

Tooling will continue to improve, making it easier and easier to turn web apps into PWAs. I don't see that slowing down for a while.

Challenges? It's so easy to progressively enhance your web apps to make a PWA that you should just do it. On non-capable browsers, nothing changes - so your users won't know the difference. The biggest challenge I see is that support for PWAs on iOS and macOS is dismal. Apple even recently changed the way it manages local storage in a way that could impact PWA users negatively. I'd like to see them get onboard, it will make the world a better place.

Readers may find all of the source code for the sample apps on GitHub. Book readers also have additional online resources available.

About the Book Author

John Wargo is a professional software developer, writer, presenter, father, husband, and geek. He's been writing code and teaching others for more than 30 years. For the last 15 years, he’s focused on building web and mobile apps. He’s an author of six books on mobile development, including four on PhoneGap/Apache Cordova, and has been a contributor to the open-source Apache Cordova project. He loves writing code and building hardware projects based on Arduino, Particle Photon, Raspberry Pi, and more. He’s currently a product manager at GitHub.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT