Progressive Web Apps: The Future of Mobile Web

Stephanie Cox: I'm Stephanie Cox and this is Mobile Matters. Today, I'm joined by Alex Russell at Google. Alex is a Senior Software Engineer at Google and is an engineer on the Chrome Web Platform team. Most recently, he helped design and lead the team that was responsible for developing Progressive Web Apps or PWAs. In this episode Alex and I talked a lot about what exactly is a progressive web app, and what are the technical requirements for one. How the idea for PWAs got started, and why sushi and a presentation at Auburn are somewhat responsible for their name, and what it means but tech players like Microsoft, Apple, Samsung and others have adopted progressive web apps. And make sure you stick around till the end where I’ll give my recap and top takeaways so that you can not only think about mobile differently but implemented effectively. Welcome to the show Alex!

So I’m really excited to talk to you about progressive web apps, and really where the future of the web is headed. So for all of my listeners that aren’t familiar with PWAs, can you just give us a really good understanding of what a progressive web app really is.

Alex Russell: Sure. I think in a nutshell you can sort of fast forward to the end. You can say imagine if all of the apps on your phone, and increasing on your desktop, are just web apps. That is to say they actually are web apps, you build them to put them on the web, but they have that deep system integration. What’s the difference between where we have been and what’s required to be there. That space in the middle, that’s what we really work on, and that’s what the genesis of progressive web apps has been.

Stephanie Cox: No I think that is a great understanding and explanation of them. When I tell people what a PWA is, one of the things I say is, think about what you can do on native mobile, but it’s delivered on the web. It’s kinda like the best of both worlds coming together.

Alex Russel: Yeah so, there’s kind of an organizational structure thing that bleeds into this conversation. Where PWA technology isn’t core web platform technology at some level. It’s a set of capabilities. One of those capabilities is a set of metadata that lets us generate a high quality icon on your homescreen. One of those is the ability to work offline. Then there is a whole follow on host of things that you would want to do, in sort of a capable application platform for mobile, but you traditionally haven’t been able to do on the web. So, we kind of view all of those things as being in scope. Our effort, this multiyear effort, has been basically to take that as a to-do list, then burn it down.

Stephanie Cox: So I know you just mentioned some of the technical requirements of a PWA, when you think about the key characteristics from a technology and functional requirements standpoint, what are the most important ones for you that make a PWA different from web apps that we have thought about in the past?

Alex Russel: So we have kind of worked backwards, I have worked backwards from the user experience. It’s a question that we don’t ask ourselves enough as web developers, which is, what is it about mobile apps that’s better? I think there is a lot of identity wound up with technology. If we choose to be web developers that means we choose this set of technologies, and therefore we choose to not be as honest as we should be about their benefits and their costs, both to ourselves and our users. So, looking a little bit past that envelope and sort of trying to stretch ourselves into an uncomfortable dimension and ask, okay is there something there that is really more satisfying about a native application, in a lot of cases, and what’s the technical development between those things got us to a set of key experience properties that we would like to maintain in PWAs. So for instance, when I tap on the homescreen icon for any native app, on any operating system, where I’ve made an explicitly install step, it never fails to load. Maybe it doesn’t actually do anything, like maybe it isn't a well built application and it didn’t cache any data, but it never fails to actually load. Where as with the web, our experience with it is that it can frequently fail to load. That is a very large user experience difference. So we have kind of formed this as a set of hurdles that certain websites have to pass before we, at least in Chrome, consider your site to be installable. And so that is kind of the basis. So on the one hand, I mentioned that sort of high-quality metadata that looks as though it deserved to belong inside of your home screen application list. On the other hand, working reliably, starting all the time, every time. And that is to say not just when you are offline, but when you are on flakey connections. Those are user experience differences between traditional web applications and native applications that we think are important enough to kind of earn your spot on the homescreen. You have to be that tall to ride the ride.

Stephanie Cox: I know you mentioned flakey connections. One of the things I have heard about progressive web apps was this idea that it can be really beneficial in really low to no connectivity areas, especially some parts of the world where connectivity is really a challenge. How much of that played into how you guys thought about really developing the framework for PWAs.

Alex Russell: Yeah, it's a big part of it. Not to dwell too much on history, but we started building some of this technology that didn’t require UI first. So service workers are this technology that we designed which allows you to make your website work offline, or on flakey connection, but this is a make it work all the time after the first visit. So, since this is a key tell, it’s such a difference that you can smell as a user between a native app and a web app, we started working on that technology first. So, those technologies again are kind of inspired by the user experience need. We want users to have a good time in things that are of the web, that are on the web, that also happen to be integrated into the os. That is to say, imagine fast-forwarding to the end of the story where we come to a place where the web is as successful on mobile as it is on desktop. I don’t know about you, but I spend a very large proportion of my time when I’m not, I mean even sometimes these days when I’m coding, when I’m not running a compiler, a good chunk of my time is spent in a browser. And that’s not where we were at on mobile today, so the question is where is the delta? What’s the difference between that and where we’d like to be? And if we get to the world, is the web a net worse experience. That is to say if your operating system is mostly populated by web applications, are you going to want it less? I think that is not a benefit to users. We should get to a place where users have all the upsides of the web. It should be safer, it should be faster potentially, that it should not invade your privacy nearly as much, that you should not have to sign away the keys to the kingdom right up front, that you should be able to make affirmative choices about who is doing what, that you should get an auto updating run time, that applications shouldn’t be massive, they shouldn’t be predating your storage space. All of those things should be continual benefits that the web delivers, but you shouldn’t have to give up all the nice things that you like about native apps to get there. So, if we get to the space where there was an operating system that is mostly peopled, or mostly populated by PWAs, would it still work like you expect it to? I think that is the question we should be focused on. And so, what’s the difference again between where we are we want to be to get there?

Stephanie Cox: So one of the things I've heard is that you and your wife came up with a name for progressive web apps, can you tell me a little bit about that story?

Alex Russell: Yeah, Frances Berriman, my partner and wife, is a product manager now at Netlify and you know we spent time in the Javascript mines in our youths. And we spent a lot of time, both as web developers and programmers. But also, sort of as people thinking about this pile of questions together...not to bring my work home too much. Her best mate is Jake Archibald, who also helped design the service worker spec with me and a bunch of other people. So, it's a very small group of people who were thinking hard about these problems in London in 2012. But the baseline for the conversation has always been, imagine if we could get to a place where web apps can do all the stuff. And then so, fast forward three years to 2015, we had built and shipped it all. We shipped the ability to add PWAs to the home stream. We shipped the ability for web apps to work offline. We ship the ability for web apps to do push notifications even when Chrome is closed. So, those are big deal capabilities, and then we would have this set of conversations over and over and over again, both with partners at Google but also with friends. And sort of trying to describe this set of things together. And so, when we'd have to say web apps that you can install to your home screen or installable web apps and then people would ask the obvious question, why aren't they all installable? And so, you'd have to get into the long-winded explanation you couldn't get you the moniker that people could hang their expectations off of. And so, having done that for about six months in the middle of 2015, we realized that we needed some name for it. Partially because I was invited to speak at a conference in Auburn, I was also just putting together a Web Directions code, and I needed to talk about this stuff and I didn't have a way to describe it. So, we went out for sushi and just wrote down all the attributes and I started taking apart the adjectives and rearranging them together and then this was the least worst alternative. Now I got to say we're not particularly proud of it being a long winded thing. But the hope has always been that it's an engineering brand, that it's not really an end user brand. It's a grouping of preexisting things, servers workers, web app manifests, push notifications, add to the home screen, all sorts of things.

Stephanie Cox: Well, it's interesting that you mentioned it was never meant to be like an end user name. Eventually, I think, we think of it as web apps, progressive web apps, native mobile apps. And I think the consumer just sees them as apps.

Alex Russell: Yeah, that's my experience of it and I can't imagine, you know I think back to this moment when Chrome first launched. There was a video that the initial marketing team did, where they went around sort-of person on the street interview, and they just asked people what's a browser? And Chrome was not, was by no means I mean it was a new browser that you could choose in opposition to other browsers, but It wasn't a new thing in the market. And people who were answering these questions spent most of their day in a browser. And so, the lack of vocabulary, I wouldn't say lack of technical acumen I think people actually fundamentally understand the difference between web content and the browser, but the lack of vocabulary is reasonable, right? You shouldn't have to teach people the parts of the body and how the entire anatomy works to get them to do a little bit of exercise. In the same way that we shouldn't have to teach people all the constituent parts of an operating system to allow them to check on their bank account balance.

Stephanie Cox: No, that's a great point. So, I know you obviously were at Google when PWAs really came to life and since 2015, when they were first introduced, we've seen Microsoft, Apple, Firefox really start to adopt PWAs in their operating systems. So, can you tell me about what that has been like for you as really being one of the first people to kind of bring this idea and concept forward?

Alex Russell: So first, I want to give credit where it's due. Jeff Burtoft at Microsoft was one of the first people who I ever had conversations with around this, at the time, very subversive notion. Both inside of Microsoft and inside of the Chrome team at Google. The idea that the Web was going to be the platform of the future, which maybe sounds surprising, given that I was working on Chrome at the time. But the idea that the Web was going to be the platform in the future for these sorts of experiences was at least a fringe view. Microsoft had XAML and Windows 8 application model and WinJS. Those things were all happening. And inside of Chrome, the chrome apps platform had launched and there was a second version underway. And the idea was that, if you needed that set of extended capabilities, well it was going to take a long time to get them done inside of the web. So, why not just use this other platform which has all the reach that Chrome does. And Jeff and I were all, we caught each other on the sidelines of conference at some point, and had a conversation, I think it was somewhere in San Francisco, about this pile of things that we could maybe do together. And it was important that they be small and incremental. And I think it was important to me that they be compatible with the Web as we have it, right? So one of the things that’s deep, but seems shallow about the difference between PWAs and other platforms has been that with other platforms, you have to change your deployment model. So this has fractal implications. If you can't update your app whenever you want push. Every time, every second, every minute suddenly your engineering velocity goes down, your design velocity goes down, your iteration rate starts to stall. You wind up having to wait on apps store reviews or some sort of automated process since you've got your thing actually went. You stop being able to have that control R, sort of ability to iterate and to modify content. This has implications for experimental frames, for logging, for all sorts of technologies that the Web has come to embody, both positively and negatively. And that meant that when you wanted to build something with these quote on quote web technologies, but deploy them to these other models, you had to package them up put them in a bundle and then you remove that superpower, that ability to deploy it almost instantly. You end up with this bundle that's distributed out of the band that users have to discover separately. They have to make a large upfront choice to install it through this out of band discovery mechanism because it isn't safe to try before you buy. The security model of these other application platforms because they are so powerful and they've got such a relatively mature security model, has meant that it requires, historically required at least, a large upfront user choice and that mediator to tell you what you can get, before you ever got there. And so, those things seem small technically. Like you still make a native app with Cordova or Phone Gap, make it out of HTML in CSS, right? But people don't make web apps because HTML, Javascript, and CSS are fun. They aren't the best part of anybody's day and, no matter how good they can be, so why do people make stuff on the Web? And I think it's because of that deployment model. And so, we honed in on this idea that you could use these small changes that these before compatible interventions into the platform. And so (name) at Mozilla and Jake Archibald, who eventually joined Google but that time was not Google, Andrew Betts at the Financial Times, a bunch of people at that time had been thinking in this way and were the key people who helped us drive both the web app manifest specification forward. Marco Cesaros at Mozilla, and eventually became supporters. Jon Qu Song at Samsung and who's now at Microsoft. So from the beginning, it was an industry collaboration, but it's sort of a ragtag group of people who were not doing anyones official bidding at any of the companies we worked for, but could see a better way forward. And that kind of collaboration is really essential, I think, to making anything on the web platform happen. It's part of the reason why we eventually end up with standards, but part of the reason why we wind up doing so much of this kind of, giving this process of a formal mechanism now, with this idea of incubating web standards, out in the open early on. And trying to bring together folks who are just quote-on-quote browser engine people, but people who make websites. People who have the experience of knowing what isn't working and then can vet whether or not something works well. I think of the folks at GitHub who were super early on in the service worker design who helped us prototype and then design polyfills for service workers to try to understand, is this going to do what we think it's going to do? Is this going to work out? Samsung was a huge early supporter of this effort and continues to be really supportive of making this technology work well, for all their uses across all their platforms. You know that's the kind of thing, without that kind of broad industry participation with lots of different perspectives not just browser engines or browser makers, you wind up making the wrong thing. And I think the history of the platforms that were web-inspired but came before PWAs tells that story pretty clearly. A lot of folks who work in browsers thinking, well, everybody wants Javascript, HTML, and CSS and missing the thing that the big inversion in that deployment model being the big deal. It wasn't that they aren't smart people so they didn't have all the perspectives in the room.

Stephanie Cox: I love how you know you just basically explain how all of these major players from so many different companies that are so essential when we think about tech, really worked together on this concept. That's not really a story I've heard a ton before.

Alex Russell: This is how all of this stuff works, is that it's a set of individuals who are looking to the left and looking to the right and trying to build a larger community of folks who have problems and need solutions to work together to do it. And then there's a big open question of, are the forums that we build successful for that, are they open enough, do they bring in enough people in early enough. How we can we avoid path dependence, while at the same time avoiding fishing expeditions or exploratory shots into space that are very expensive and can't get us results quickly. So, all those things wind up shoring up the doorstep, but the key thing is to pin our hopes on this idea that it's a combination of people who work on browsers that is to say, who can ship bits that change the world. And people with the experience of what isn't working in the bits they've already got that creates a constituency that can really move things.

Stephanie Cox: So thinking about PWA standards moving forward, would you say that a lot of the people that were involved from the beginning and then obviously other people from other companies that have really jumped on the PWA bandwagon, are helping develop what the future of PWA standards look like and how we think about that moving forward?

Alex Russell: Yeah, absolutely! So one of the things I also wind up doing with my time and from the reason I did come back to this is that I'm our, I guess the title is, tech lead. But this is the person whose responsibility is, even if it isn't my fault, for things that happened regarding web standards for the Chrome team. And so, that kind of winds up being central to how we think about everything we do because when we want to make changes to our platform, obviously we don't, we never have and never will own the web platform. Google and Chrome are not the sole purveyor of the bits that implement the web. I think everyone's benefit, and we never want to be. And so, there's a key element of health for the platform that is played out over and over again in that diversity. We want people to be able to take the platform and reimplement it however they want, to show a better way, to do a better job. While at the same time, we have a vested interest in making sure that it continues to progress quickly enough to make meaningful progress in the lives of developers and end users. And so that requires us to work in the open all the time. So there's a group that we've helped to build and bolster with Microsoft and Mozilla, called the web incubation community group. And it's one of this other set of incubation groups a W3C (World Wide Web Consortium) whose job it is to sort of take a nascent idea or even just a problem statement and start to chew on it. It isn't to say that we know what the answer is. There's a real set of anti-patterns that get employed when folks walk into the room, thinking they know what the answer is without fully investigating the problem. So, to try to avoid that we have partnered and collaborated on these incubation groups and they are working pretty well. So they are now our go-to mechanism for helping folks train their attention on problems, rather than solutions and then do the iteration process that's really necessary to get to a deep understanding of the problem space. Because until you have that, it's very difficult to really even begin to design meaningful answers. The way I think about this is, there are lots of standards bodies, there's WG, there's ITF, there's ISO, JavaScript's and all these famous bodies have a lot of experts in the room. But experts are just a sub-people of people who've made all the mistakes in an area. A standards body when it gets together, it has a lot of people who have a lot of experience, but that's not the same thing as your end users telling you whether it's working for them. The standards process doesn't have a fitness function attached to it. It can only tell you whether or not you've dotted the I's correctly and crossed all the T's. Acknowledging that means that there's a space here for something that's different to a formal charter working group. And I think that's the right thing, because big chartered formal working groups have a lot of momentum, right? They're designed to crush through a set of residual problems that come from the core of a good design and make sure that you've got to something that works for everybody. Rather than coming up with a good idea that could work, if given enough time and enough investment. So, there's this front stage of the new feature process for the web that we've started to get a little bit better at. I hope. And is really critical. So yeah, I think that process is something that we, I wouldn't say pioneered, but took some notes from the way IETF works and have continued to iterate on over in these other areas in the web platform. And hopefully that has allowed us to participate, not just with other browser vendors, and with other folks who are "in the industry", but with web developers who just want to get engaged and get involved in solving problems that they specifically and very acutely feel.

Stephanie Cox: So I know you mentioned Microsoft and if you look at really what Microsoft has done recently with almost a little bit of an all in bet on PWAs. Can you talk to me about kind of just what your thoughts are on that?

Alex Russell: I'm ecstatic, obviously. Microsoft beat us to desktop PWAs, the Chrome team that is, by more than a year. So we launched support for installing web apps to the desktop in Chrome OS, Windows and Linux, a couple of releases ago. And Microsoft was there last summer. In fact, they're out ahead still in that you can go find progressive web apps inside the Windows store. And so, not only have they been a strong technical partner, in terms of designing these new features and working with us to iterate on the designs and test them out and figure out when are they going to meet all the needs that everyone has and be implementable in their engine. But also, they have really taken the platform aspect of it and run with it in a way that's, I think, a little bit inspiring. I'm optimistic that their lead will be taken by lots of other folks. I should say, Samsung has done similar work in terms of getting out ahead. They've modified the UI of their browser in the same way that Firefox has to tell users in a more ambient way that something is installable. So, there are these places where because the core of this stuff doesn't have an opinion about the UI or sort of any kind of business or platform-level things, it's open to interpretation. And I think that's one of the benefits of this really interesting lack of control that comes from an open standards-based platform, where folks can figure out what's going to work best, not by sort of agreeing to it in a smoke-filled room proverbially, but by having everyone try stuff out and see what's working best and then everyone follows the leader.

Stephanie Cox: So speaking of that a little bit, obviously Apple was a little bit I would say slower to the PWA game than a lot of other players.

Alex Russell: Three to four years behind, yep.

Stephanie Cox: So what do you think their reluctance to adopt PWAs initially was and why they really haven't honestly caught up to where a lot of the other browsers and operating systems are?

Alex Russell: So I want to first speak to my friends and colleagues on the WebKit and Safari teams, in case they happen to catch this. We see you, we know that you are doing extraordinarily good work. So, that's the background here, right? The folks who we’re on Safari and WebKit are doing extraordinary work. Individually, they are some of the best web platform engineers in the world, if not the best pound for pound. And the primary issue here is that they are sort of structurally underfunded. I can't tell you why a company that on any given Tuesday is potentially the world's most valuable firm can't find it in its budget to build a credibly sized web platform team. I can tell you that Apple doesn't have a credibly sized web platform team. They just, no matter how good the individuals are, like if you were to look at the web platform size of the team inside of Chrome, obviously, I would like it to be much larger than it is, but there's so much more we can do if we had more more resources. But then, I look at both the scale of Mozilla's investments and the scale of Apple's investments and I get a little worried. Because it's not healthy for the platform when the folks who are, hopefully, with us at the leading edge and helping us push new designs forward, aren't able to implement new things in a timely fashion. Now, I will say that there are some very bright spots. We've been extraordinarily happy with our collaboration with these Safari team, WebKit on things like web components. They were, I think we shipped the web components V1, which is the most recent version of those specs, not too far before they hit Apple's stable ranch. I think they were actually even making it to their dev channel before we were. So, there's a lot of this sort of this discontinuity, but that just speaks to a lack of depth. Again, it's not that the individuals aren't extraordinary, it's just that there aren't enough of them. And so, when that situation arises, it creates a sparse implementation of the platform. And that means that every team is going to have to make some sort of a research tradeoff in that environment. And so, it's natural without a lot of strong leadership in some specific area to take a wait and see approach. So that's just what I see. I see extraordinary people doing incredible work when they're given the time and space to do it. And the question is really to Apple about why Apple's investment in the web is so poor.

Stephanie Cox: That's such an interesting take on it, because one of the things that I hear, at least from more of a business conversation, is well does Apple really believe in PWAs? And I think there is a question that, what people talk about sometimes is this idea of well, maybe they're just so committed to the native mobile app store that's why they're not fully investing. And I think the way you, your perspective is really completely kind of flips that on its head. It's not really, maybe, a strategic decision it's more of, there's a limited resources for this team and they're doing the best they've got with what they have right now.

Alex Russell: Well, those could be the same story, right? If your organization is at the scale of Microsoft or Google or Apple, they make strategic decisions in the form of headcount allocation. It's very literally at some level you're not making the decision about whether you're going to ship this one feature, you're making a decision about whether or not you're going to staff a team to 100% of its current size, 80% of its current size, 200% of its current size. And that's just, that's just a very subtle thumb on the scale that doesn't have any individual actor's name attached to it, but it is, the consequences are very predictable and they play out over the long term. One of the things I think the Web community should get better at, is looking at these sets of outcomes and trying to attribute them. Like it's a dead-weight loss. I don't know how much that phrasing makes sense, but the idea that it's still a loss, even if something wasn't taken away from you. But it just wasn't otherwise would have happened but didn't happen because of some reason that caused it not to. That's the idea of a dead-weight loss. And there are a lot of these deadweight losses that show up on the web platform because various teams decide not to keep the pace.

Stephanie Cox: If you haven't realized it already Alex is kind of like the father of progressive web apps, and just shared some really great behind-the-scenes stories of how PWAs came to life. I don't think I've heard him share that much detail about who was involved in the initial conversations about the concept of PWAs before. And the best part, this is just the first part of my conversation with Alex you guys. When you get the opportunity to interview the leader of PWAs from Google you ask a lot of questions trust me. So let's just say there's another episode coming next week. Now, let's dive into my top three takeaways from the first part of my conversation with Alex, and then I'll share with all of you a sneak peek of what you can expect in next week's episode.

First, since Google was really the leader in the PWA movement, I've always attributed the concept of PWAs really to them, and I never realized how many other people contributed to that discussion of what eventually became a progressive web app. It was great to hear Alex tell the story of how it all started in London 2012 and how individuals from various companies like Microsoft, Mozilla, Financial Times and others really contributed to the concept of what we now call progressive web app. Next, his comments about how he thought about taking what consumer is a lot about Native mobile and bring that to the web with progressive web apps was really impactful and it's clear how much of that has really driven what we now refer to as technical requirements for a PWA. And I wonder if that's why you're seeing so many brands and I'm talking Starbucks, Pinterest, Trivago and others that are really doing their first PWA almost as a replica of their native mobile app. And if you look at any of the data on those, you'll see that they're having phenomenal results with their PWA, especially compared to native mobile. Finally, I loved hearing Alex's insights on how other Tech players are latching onto the PWA concept. Clearly, If you paid attention to Microsoft, they're all in on PWAs from a platform perspective. And he shared a different concept about why it took so long for Apple to adopt progressive web apps, that I think was really insightful, and something I never heard before.

Now make sure you check out next week's episode where Alex is sharing is so much more about progressive web apps, including what Google has planned for PWAs this year, how to determine if a PWA will work for your business, the advice he personally gives when someone's building on for the first time, his favorite PWA example, and how Chrome is thinking about Mobile in general. If you enjoyed hearing Alex talk on this episode, trust me, you're going to love next week. See you.

I'm Stephanie Cox and you've been listening to Mobile Matters. If you haven't yet be sure to subscribe, rate and review this podcast. Until then be sure to visit Lumavate.com and subscribe to get more access to thought leaders, best practices, and all things mobile.

Progressive Web Apps: The Future of Mobile Web

Episode Information

Stephanie's Strong Opinions

Find us at:

Stay Up-to-date On All Things Digital

See Lumavate in Action

Meet with one of our experts to see how easy it is to centralize your product data, manage digital assets, and create digital product experiences. Trust us…you’re going to be wowed.