Windows 10 + PWAs: A Progress Report

Posted on May 9, 2019 by Paul Thurrott in Cloud, Microsoft Edge, Web browsers, Dev, Mobile, Android, Chrome OS, Windows 10 with 67 Comments

In October 2017, I spoke with Microsoft’s Jeff Burtoft and Aaron Gustafson about the company’s plans to bring Progressive Web Apps (PWAs) to Windows 10. Since then, a lot has changed: Microsoft incorporated PWA support into the platform, as planned, allowing users to install these more sophisticated web apps directly from the Microsoft Store. And more recently, of course, Microsoft announced its audacious plan to adopt Chromium for the next version of its Edge browser, a move that will dramatically change—and improve—how PWAs work in Windows.

So I was curious about the timing of things—did the need for better PWA support drive the decision to adopt Chromium?—and about how well PWAs have performed in the Store, since there’s no easy way for a user to understand the origins of the apps they install. So I reached out to Jeff and Aaron ahead of Build, and we met at the show with a few other folks from the Edge team to see how things have, ahem, progressed.

Paul: Let’s pick up where we left off.


Paul: When we last spoke, the thing that stuck out for me most was that you [Microsoft] were bringing apps to the Store while your contemporaries at Google were doing apps through the browser. And you both were looking at doing what the other was doing as well. I’m curious if that played any role in [the move to Chromium for Edge].

Jeff: We made a big bet on the Store, and the web app tech we had so far made that make the most sense to implement first. And we have some really great stories to tell about that. We talk about Twitter a lot, but Pinterest recently finished their roll out on PWA. And Hulu, which was a UWP, switched to PWA. So for us, it was kind of a point where we had made some technology choices, and they [the app makers] made some technology choices, and they are finally aligned. So there was a lot of collaboration …

Paul: Between you and Google?

Jeff: No, I’m thinking about the partners. For example, Pinterest had not been on the platform, but they were building a PWA. So when we started supporting PWA, it was really natural for them to get on board and put their app in the Store as a Progressive Web App. So we’re confident that we made a good choice there. That said, there are some benefits to Google’s approach [where PWAs are installed through the browser] as well. And frankly, those partners, the feedback they gave us as well was that there’s not enough continuity with the browser. And so if you look at how Google implements this, they have shared cookies. So if you’re already logged in, you don’t have to re-login. And we hear that time and again.

Paul: I’ve seen that myself.

Jeff: The other thing is, when you have a password manager, having [your passwords] automatically available in the app is a big deal for them. [If you manage passwords in Chrome, these passwords are pushed to apps in both Chrome/Chrome OS and Android.] So for us, whenever we think about how we’re going to take the next step, I don’t think that we can say that PWA lead the decision on the browser [in switching to Chromium]. But once we did make that browser choice, it was a really natural decision to re-baseline and meet those needs. It was a lot easier for us to figure out how to get that into the Store than it was to rebuild what we had in the Store into the browser.

Kyle Pflug (Senior PM Lead, Microsoft Edge): PWAs follow the logic in the browser. Whether it’s installing web apps, organizing tabs, we started experimenting in the previous version of Edge. But now that we have the chance to start over, we’re being a little more thoughtful about those experiments and start fresh. It’s kind of an opportunity to solve the same problems but in new ways.

Jeff: Yeah. We can’t put words in Google’s mouth but …

Aaron: I think throughout the process we [Microsoft and Google] were both looking at what the other was doing, seeing what’s working, what’s not working, looking at how our customers are reacting. We’re all in these different orgs, trying to work together to realize the same vision. They have the same thing going on there at Google. They’ve now gone the Store route using Trusted Web Activity, which in many ways borrows on what we had been doing with the Store. Because ultimately it is about serving our partners and allowing apps to be distributed as broadly as possible through as many avenues as possible. For some users, that’s going to be the browser, for some it will be the Store. For ten years, we’ve taught users, on mobile, that the Store is where you go to get software. But we’re just trying to create as many opportunities as possible for people to find what they’re looking for.

Paul: So if you look at the [pre-release versions of the new Edge, web apps and pages can be installed/pinned from the Settings and more menu or through an icon in the address bar].

Aaron: I don’t think we’ve come to an official stance in terms of the install prompt event. We’re looking at what Google’s done, talking to their developers a lot about what’s worked and what hasn’t, and to our partners about what they’ve liked or not liked about the approaches that Google has taken. And just try to figure out what’s right.

Jeff: I would say that the Google desktop implementation [for app install] is now very mature. And getting in there, and working on the same code base, was actually very good timing for us. What they had done so far, there wasn’t a whole lot to it, it was buried in a menu, had to be the right type of web page, and it would say “install” instead of “pin.” I don’t think they intended it as a good way to do it, and there is still a lot of work to do to refine that and make that experience make sense to both users and partners. We talked to some of the folks who are in the Store today and asked them about how to handle that [app install] through the web. Do we use the term “PWA”?  And they said, no, that’s not a term consumers understand. We do use those words that Google does, like “pin to home screen” or “install.” But I think there’s still a lot of experimentation to do. Developers know what a PWA is. But in the real world, it’s not something that people understand.

Paul: It shouldn’t matter to users how an app was made.

Jeff: Right. It shouldn’t matter, it’s an app. Users understand apps. They understand that this is a browser and this is an app. A website may tell they use that they should use the app. And we just need to figure out how that makes sense in the browser.

Aaron: The other thing is that sometimes it’s different depending on the audience. End users in India would very much prefer for something to feel web-like as opposed to app-like because it’s smaller and lighter. The same thing happens in rural America, or anywhere that there are lower-end devices or pay-as-you-go data networks. They’re going to suffer in app-land. Finding the right balance and serving the audience correctly is important. It’s all about options.

Jeff: Who was it that had this app where the PWA version was x-percent smaller?

Aaron: It was Tinder. Their PWA is 90 percent smaller than their app and it offers the same basic functionality.

Jeff: Those are the types of things where the web really makes sense.

Paul: So how are things going to work going forward. Today, you have PWAs in the Store and I assume they run on [the current Edge backends].

Aaron: We’re trying to find a path forward for app developers. That path forward will likely be the WebView. If they need to have access to native [Windows 10] functionality that we’re not bringing to the web. But at the same time, we’re very standards-focused and looking to see what are the high-usage and high-value APIs in Windows. Things like jump lists and potentially live tiles. What makes sense to bring over to the web as standardized APIs. And that’s where we’ve really gotten tucked in with the Google folks because they’re looking at this for Chrome OS as well. They want file system access, and more. And so we’re starting to work with them on those standards to help empower the next generation of web apps and PWAs. Ideally, we’d like for the web to be the path forward for existing PWAs in the Store. But for the few apps here and there that do require specialized Windows functionality for one reason or another, we want a path forward for them as well.

Kyle: We will not break PWAs.

Aaron: Right. WebView 2 is an Anaheim [Chromium-based Edge]-based version of the WebView. It would either be evergreen or you could package it with a specific version of Edge. [In the past, there was a different version of Edge and the WebView with each version of Windows. But WebView 2+ is tied to the Chromium schedule now.]

Jeff: I’m going to predict the transition a little more favorably. When we actually looked at how many people we were going to hurt in moving to the web context. Because we lose that WinRT API layer that we were able to provide in PWAs previously. Aaron came up with a list of maybe a dozen APIs that were really being used, even though we provided thousands of them.

Paul: What were a few of the top APIs? Push notifications…

Jeff: Push notifications were already being provided. Share target was a big one, and is coming. Media controls. Jump Lists is coming soon. All this stuff, these high-value APIs, we’re trying to bring them over. But I think most of them [apps/app developers] will just move to what’s already available in PWA in Anaheim [the new Edge]. There will be some who really need a certain API. And we will work with them. They can use a WebView and still have the same APIs. But it’s only a matter of time before they’re available the FUGU or W3C APIs, so that they can just go back to being a PWA. For example, we’re actively working now with Google on native file access.

Paul: Aren’t jump lists Windows only? How will they be added to a standard?

Aaron: No, there are things like jump lists on other platforms. Long press on iOS, Force Touch on Mac, etc. There’s parity across all these platforms. The APIs we’re taking as our first crack at this, the low-hanging fruit, are things that exist on all platforms [in some way]. Once we get our sea legs, we start pushing forward on some of the harder stuff. There are a bunch of things under the FUGU umbrella in the Chromium project that Intel and other partners have been tackling too. They’ve openly asked us for help. [FUGU is a subsection of the bugs on the Chromium tracker that are basically a catchall for device integration capabilities.]

Paul: OK, so at some point, you realize that this [the move to Chromium] is happening or might happen. Was there anything, like, Yikes horrible on the Chrome side?


Aaron: I’ve known a lot of the Chrome developers for years, so I should not have been surprised, but I am still a little surprised by how welcoming the reception has been. It’s been super-gracious. Everybody is collaborating, and I don’t feel even a tinge of, like, competitive worries, like we or they are holding anything back. We obviously have our own partners that we are dealing with, NDAs we need to work around, and so on. But relationship-wise, we have a really good rapport with the Chrome team. They’re very excited to have us onboard.

Jeff: We’ve been collaborating with Google on PWAs for years. We anticipated that we would have it pretty easy. And this has given us a bit more official platform to communicate. Chromium is becoming a more public channel to see the collaboration that’s happening. Which is pretty cool. In the past, it was just us talking about something or them [Google] talking about something. But now there is a forum where anyone can see that there are conversations actually happening. It’s official. So for us, it’s a really natural step up. Both parties understand that if it’s going to work, there has to be a lot of collaboration. And that we have to approach this in a very open source-minded way.

Paul: The last time we talked, I got the vibe from you guys that you had good relationships with Google at that level. But [with the Chromium-based Edge], has that relationship moved uplevel at all?

Jeff: Yeah. Now, our bosses are talking to their bosses. For whatever that’s worth. I don’t think they actually get anything done.


Jeff: But they’re talking. It’s not as grassroots as before.

Aaron: We’ve always tried to have coordinated messaging because we all ultimately want PWAs to succeed. We want the web to succeed. But yeah, it’s nice to see everything out there and we’re all working together. There was … some degree of community concern when we announced that we were going to Chromium. Especially from the web standards world. But I think people now see that we’re not just going to take Chromium and do our own thing. We’re here to participate and to so in an open way.

Paul: I think the fear is that Google, one day, will say no to something.

Aaron: Maybe, maybe not. I hope not. But one day at a time.

Paul: OK, back to PWAs. You mentioned some specific apps earlier. How do we gauge the success of PWAs, especially in the Store? There’s no way to really how apps are made. PWAs make a lot of sense to me. Has the uptake been better or worse than you expected?

Jeff: The trajectory is rising. One of the things we’re going to do for you and others in the community who want to know these things is to start showcasing partner apps in our PWA Builder tool. This is an opportunity for partners who do build PWAs to have a place where they can say, yes, I’m a PWA. When we do have a conversation like this, I can mention Pinterest because they went public with it. But there are hundreds of others that I can’t discuss because it’s not my place to call out the technologies they’re using. There are two levels to this: The front runners, or key players, that are in the Store, and we have clearly seen that rise. In the next couple of months, you will find out about players you hadn’t anticipated that are on board with PWAs as well. Thanks to Web Assembly, there are these traditional power apps that can utilize it to handle low-level code. And even for the legacy foundations of their applications. Then they can build the front-end of their apps on web technologies, and they are PWAs that will be delivered and maintained like PWAs. So we’re going to see that rise. And then I would anticipate that, after that, we’ll see more of the community. The numbers, I think, will follow after that. Once we see more big names announcing that they’ve [chosen PWA], others will follow as well.

Aaron: We’re also starting to see more, sort of, bespoke tools that developers are building for themselves as PWAs. In some ways, that kind of thing is what lit the fire on iOS app development back in the day. People would say, oh, I need a tip calculator. Now people are starting to do the same thing, but turning to web tech to do it in the mobile space. It’s really interesting. And that gets me excited about how apps are evolving.

Paul: So what’s going on with the Edge developer tools?

Brendyn Alexander (Senior PM Lead, Edge Developer):  The developer tools strategy ties in nicely with the point they made about being customer-centric. We went out and did a lot of investigations with developers using HTML dev tools. And the first thing they all said was, just make the tools like the Chromium dev tools. So we moved Chromium, and joked that we were done. But we’re not really done. Now we have a consistent set of tools that look like Visual Studio Code and Visual Studio and feel like a cohesive set of tools across platforms as well. Our big view was to go where the customers are and to make them more productive. And we’re contributing most changes back to Chromium, including accessibility fixes, localization, keyboard navigation, screen reader, high contrast mode, contrast ratio support, and more. Inclusivity is a big part of our first push, and I think we’ve made 400+ commits into Chromium so far. So we hit the ground running. And in terms of partnership, we have a great working relationship with the Chrome Dev Tools team as well. We submit PRs to them and collaborate with them on the best ways to get them done. For accessibility and localization, we’re doing a lot of the heavy lifting in terms of the sheer number of engineers we have working on that.

Jeff: One of the best things is that the F12 [developer] tools now work in PWAs too.

Brendyn: Yeah, it’s really cool.


Note: Apologies if this is a little rough. I wanted to get it published before I flew home from Seattle. I’ll try to pretty it up when I get home. —Paul

Tagged with ,

Join the discussion!


Don't have a login but want to join the conversation? Become a Thurrott Premium or Basic User to participate

Comments (67)

67 responses to “Windows 10 + PWAs: A Progress Report”

  1. ikjadoon

    Excellent read. Thank you for sharing, even if it's rough (quick typo: rapport instead of repour).

    They seem as cautiously optimistic as we users are.

    There's a lot polish needed for PWAs, TBH, and I think that prevents enthusiasm. Today, PWAs are (often) a solution looking for a problem. Then the damned inconsistency. Some PWAs have working notifications, some don't. Some PWAs have great caching, some don't. Just a turn-off.

    Chredge is now my daily browser: once they turn on MSA sync for extensions and settings, I don't see a need to look back.

  2. justme

    I just dont get it, at least from a Windows 10 perspective. A PWA is just a packaged website, albeit with push notifications and a bit of integration (like being able to talk to your camera) - and even those things arent consistent across all PWAs. Why would I use one on a desktop, laptop, or Windows tablet-ish device (think Surface) when I can just go to the website itself? To me they just seem like a new way of doing something thats already done - not faster necessarily, not better, just different. Yes, there is less overhead for a developer vice a traditional app, but in the end it is just a web front end. The only place they make sense in my pea brain is a phone (easier than typing for folks with large hands, better formatting for a smaller screen) but Microsoft has been out of that game for a while.

    EDIT: Regarding PWAs and phones, skane2600 posted a link below to a website that talks about 11 PWAs. What do they all have in common? Every single one is shown to be on a phone. Every. Single. One. How exactly does that help Windows 10? My Windows machines arent phones.

    • Paul Thurrott

      In reply to JustMe:

      PWAs are cross platform. So they're full apps that work across Windows, Mac, Linux, Android, and iOS. Consider Hulu: Instead of making multiple apps, one for each platform, they can make and update just a single app.

      • justme

        In reply to paul-thurrott:
        I completely understand something that allows cross platform development. The problem I see is that this works for SIMPLE apps. What happens, however, when the apps get complex enough to start dealing with hardware on any kind of scale? As you have already pointed out, the best apps in the store are adapted programs. I just dont see PWAs ever being robust enough to deal with the complexities of the myriad of hardware combinations that exist in a consistent, cohesive fashion. If PWAs are going to replace native apps, then they need to work as well as native apps.
        • cr08

          In reply to JustMe:

          The thing is that right now web apps can already take advantage of bits of hardware as necessary. We often have full GPU access, use of Bluetooth devices or game controllers, hell even full VR functionality with current HMDs. Even Chrome has the same hooks for this kind of stuff that work regardless of the fact you are on Android or on Windows. I think we are well past the point of web based applications being functionality restricted as it were.

          • justme

            In reply to cr08:

            You may be correct. And as Paul points out, cross-platform is huge. For me, my biggest concern would be the consistency (sp?) of the user experience. Maybe I am just cynical, but I dont trust Microsoft to get that right.

            As this is Windows we are discussing, the PWAs in general would naturally come out of the Store. Microsoft has trained generations of users to basically ignore the Store for little more than updates of its own software. Thats a hurdle you have to get over, particularly as Microsoft has virtually no hold in the mobile market. (I acknowledge that there are a handful of decent apps in the Store. But only a handful. I also acknowledge the Store is better than it used to be. But only marginally.)

            I'll go back to what I said in the beginning - given what PWAs are, on a *Windows* system, why would I ever use an app to do what could be done just as easy in a browser?

      • Stooks

        In reply to paul-thurrott:

        Provided the app is simple in terms of ability then yes a PWA is an option.

        Once the app's ability grows to the point of using the hardware (GPU, GPS, camera, etc, etc) then a native app will always be better. Using a PWA in this situation is great for the developers, but the user experience will suffer on one or more platforms.

      • skane2600

        In reply to paul-thurrott:

        Being cross platform is the pitch but it remains to be seen if it actually is achieved in the general case.

    • Stooks

      In reply to JustMe:

      I completely agree with you on a computer, there is simply no need. On a mobile device they are only good because they are slightly better than a web page or web app and <<<<<< than a native app 8 days a week.

    • JoePaulson

      In reply to JustMe:

      Did you miss the webassemble part? Blazor apps can be PWAs....that would be full blown .net apps delivered and managed like a PWA.

      • curtisspendlove

        In reply to JoePaulson:

        Except this essentially nullifies the “cross-platform” component of PWAs. Sure, WebAssembly is great for Windows apps. But mainstream companies aren’t going to be writing a specific version of a PWA for Windows that is essentially a small web wrapper around a .NET app.

        Some vertical market products that need Windows might certainly make a PWA-wrapped version for simpler distribution and installation, but I doubt you’re going to see any large consumer apps use anything but token web-supported PWA tech.

        I’ve only superficially looked into Blazor, but my understanding is that it isn’t all of .NET. it is essentially Razor web tech that can run use WebAssembly to run in-browser. Which is super cool, but I don’t think that is quite the same as being able to dump just any old C# project into a browser and have it magically hit all the Windows APIs via .NET.


        So I got curious and checked into Blazor a bit. I’m impressed. They are basically using WebAssembly to build out a .NET-based Single Page Application framework (competitor for React, Angular, etc).

        Very clever. It definitely supports far more than I expected, including .NET Standard 2.0. (Though I have a suspicion that certain APIs would need to call back to a Windows Server running a .NET server app, but still, super clever.)

        But my concern, as always with these “common framework” initiatives is that the “kicker” is always in the details. You see stuff like this at the end of the “Getting Started” docs:

        “APIs that aren't applicable inside a web browser (for example, accessing the file system, opening a socket, and threading) throw a PlatformNotSupportedException.“

  3. bill_russell

    PWA's would be something to make the bare store look chock full of name brand "apps" quickly. Maybe that hope is dimming at this point. But, maybe they can be seen as something to served from Azure, increasing business there. But I know nothing. I've never used the store or azure.

    • JoePaulson

      In reply to Bill_Russell:

      If you have a storefront, then you can actually put guardrails around the apps that people install. That is great for businesses and schools. Once PWAs become the dominant method of distribution, you could credibly turn on S-mode (or whatever windows lite will be) and have access to all the validated apps out there. Ideally there would be very little that would be missing.

  4. RonH

    Awsome Paul

  5. BizTechSherpa

    I like this line: "For ten years, we’ve taught users, on mobile, that the Store is where you go to get software."

    So both mobile users learned how to get software via the store?

  6. JoePaulson

    The amount of derp here is astonishing...."I don't get it"....great....and one day you will be using an application that is highly functional and not think twice about the fact it is a PWA.

    • skane2600

      In reply to JoePaulson:

      I don't get people who just take it on faith that a proposed technology is going to work out exactly like the promoters say it's going to. There have been many technologies in the past that didn't live up to the hype.

  7. Boo

    Great read - looking forward to more like this . Thanks Paul

  8. sandeepm

    These guys are sounding like so shit scared, like as if it were the Balmer days all over again. They will park their brains on their back sides and blindly be dictated by the dark side of stupid Google. Just listen to what your commonsense tells you and make Edge the same again, chromium notwithstanding. Stop copying others missteps. Do what is right.

  9. Ed

    Very good article. This is exactly the kind of content I'm interested in as a premium member. Nice work.

  10. waethorn

    I just don't see PWA's amounting to much. I think for whatever excitement people talk about around this stuff, there's going to be another big company that refuses to make a platform-specific applications for Windows. I think it's going to be mobile apps + websites for desktop web browsers for a very long time. The types of apps that do get put on Windows will be full-featured desktop apps that require that level of development, but putting additional work into some lame-brain extra features in Windows 10 on top of an already-built website is going to be a small niche at best.

    • skane2600

      In reply to Waethorn:

      It seems like a lot of the new technology that has been released in the past decade have provided new ways of doing the same old things, not necessarily faster or better, just different. I guess that's a lot easier than coming up with a great new idea for the end user.

    • Paul Thurrott

      In reply to Waethorn:

      Here's the big deal. Many developers would simply skip Windows 10 and the Microsoft Store. But when they go PWA, as many are, adding those apps to Microsoft is painless. So this is a net win for Windows 10.

      • Stooks

        In reply to paul-thurrott:

        Maybe. Or the developer just relies on their web site which works on everything already. If PWA's are just a slightly better web page UI experience on mobile devices but hardly any different on a computer then why waste the dev time on Windows 10?

        PWA's and Chromebooks, much hype, little reality/traction after multiple years of promotion. Yet some keep beating that drum.

      • waethorn

        In reply to paul-thurrott:

        They could easily repackage their websites now as compiled programs, but they're just not doing it. Facebook, Spotify, Netflix, etc....none of them are doing this for Windows. They're either porting their mobile application over, or telling desktop users to use their browsers to access the service.

        • curtisspendlove

          In reply to Waethorn:

          Well, in this case there actually *is* an advantage to developers. IF, and it’s a big if, the platform owners properly implement the WPA platform functionality in their operating systems. (Which is the exact topic of the discussion Paul had with the Microsoft team in this article.)

          For instance, if Windows, iOS/macOS, Android/Linux/Chrome OS, etc support the PWA platform standard for notifications, then a single codebase that confirms to the PWA standards could execute calls against the Notifications API and it would trigger a platform-appropriate response: Windows 10 gives a “toast” and tosses it in the notifications area of the taskbar, macOS gives a “toast” and tosses it in the Notifications panel, iOS and Android do their standard notification things, and Linux does...something. (It usually depends on the window manager.)

          The same goes for “jump lists”, file system access, and anything else they add to the PWA standards.

          It it is actually cool, IF all of the moving pieces come together. However, with 30 years of coding experience, this has never actually happened as the proponents have planned. To be fair, the PWA standard is more likely to bring a lot of this to fruition, but it still isn’t a magic bullet or the final solution (to end all solutions).

      • justme

        In reply to paul-thurrott:

        This brings a question to mind: if we assume Microsoft goes in heavy with its PWA push, what (if any) requirements/changes/fees/handcuffs will there be on developers who put their PWAs in the Store?

  11. karlinhigh

    Paul: If you did that on an airplane, it's quite good. The times I've done transcription work, my family experienced it as neglect. Dad might as well not have been home for the level of focus it took.

  12. wh

    I see only one edit to suggest: change "repour" to "rapport".

  13. Chris_Kez

    Thanks Paul, this was great. I'd like to see more of this kind of thing on the Premium side. I keep saying one of your hidden strengths is your network of contacts; put it to use. Anyone can write a thousand word blog post riffing on current tech news headlines, but very few people can provide access to the people who are actually building the things that others end up writing about.

  14. giskemo

    Paul , with the announcement of the transcription service i would assume next build you can spend more quality time with your family since Microsoft can transcribe the interviews you are doing with them for you! Did that make sense?

  15. Stooks

    I have yet to use a PWA on Windows or for that matter on any computing device I own (Windows PC's, Mac's, iPhone, iPad). I just do not get the hype or need really.

    • CajunMoses

      In reply to Stooks:

      How do you know that you haven't? If you've used a Web app, it may have been a PWA.

      • skane2600

        In reply to CajunMoses:

        But if a PWA is indistinguishable from a Web app from the users's POV, why bother with the PWA - just create the Web app.

        • Paul Thurrott

          In reply to skane2600:

          That's like saying, just use a DOS app. Why bother with Windows apps since Windows runs DOS apps too.

          You clearly don't understand what's happening here is you discount PWAs as not being important.

          • skane2600

            In reply to paul-thurrott:

            Seriously? PWAs are to Web Apps as a Windows program is to a DOS program? And a Windows program is indistinguishable from a DOS program?

            • curtisspendlove

              In reply to skane2600:

              Seriously? PWAs are to Web Apps as a Windows program is to a DOS program? And a Windows program is indistinguishable from a DOS program?

              It is actually a reasonably apt analogy. From a technical standpoint a PWA is an advanced web app that implements additional functionality.

              The main reason they are currently “indistinguishable” is more due to the fact that the standards are still pretty new and don’t offer a whole lot of new stuff yet. That will change.

              But also, the fact that there isn’t some huge, striking difference with a PWA that jumps out and punches you in the throat is a good thing. To be successful, a PWA should be as close to a native app experience as possible.

              This is all still very early in the PWA journey.

              • skane2600

                In reply to curtisspendlove:

                I would say you're either overestimating the value of PWA's relative to web apps or underestimating the value of Windows relative to DOS.

                It seems appropriate to evaluate a technology today based on how it is typically used today and then if tomorrow it is used in a more advantageous manner we can re-evaluate. Broad attempts to use advanced features of a technology sometimes uncovers unanticipated problems or a realization that there are some inherent flaws in the concept.

                • curtisspendlove

                  In reply to skane2600:

                  Reread Paul’s original comment you replied to. He said nothing about relative power.

                  I’m curious what I said you disagree with. A PWA is simply a Web App that takes advantage of additional features and APIs.

                  Your question was “why use a PWA when I can use a Web App? ”.

                  Paul’s response was “that is like saying why use WordPerfect when I can use WordStar?”

                  Why *not* use additional features if they are available? Seems silly not to.

                  It is almost trivial to make an existing web app into a PWA. To take full advantage requires additional thought and some refactoring. But all technologies do. Again, I’m on record here saying it isn’t a silver bullet. But it is far from useless.

                • skane2600

                  In reply to curtisspendlove:

                  I don't know what Paul said in your universe, but in ours he said nothing about WordPerfect or WordStar

    • Paul Thurrott

      In reply to Stooks:

      If you use the web, you probably have used a PWA.

      • pecosbob04

        In reply to paul-thurrott:Are there Consevative Web Apps for non progressives? Asking for a friend.

      • Stooks

        In reply to paul-thurrott:

        Yeah because there is no difference? Of course I use the web, on this page right now but I have never had a stand alone "thurrott dot com" experience, as in the browser is still running with different tabs but this stand alone, UI chrome-less web page stands by its self, looking like an app for your site.

        I know they exist. I have tried out the Google apps that way before they were called PWA's, like Google Docs when you could "pin" them, even on a Mac, before they took that away. However launching them back then would also open up Chrome in the background.

        Since that time I have not tried them.

  16. skane2600

    There are so many different technologies that are supposed to replace apps I have trouble keeping track.

    • Paul Thurrott

      In reply to skane2600:

      No one is replacing apps. These are all just choices for developers who make apps. PWAs are apps.

      • skane2600

        In reply to paul-thurrott:

        Obviously in the context of my statement I'm referring to native apps vs PWAs. Static HTML pages can be "apps" in the broadest sense.

        • curtisspendlove

          In reply to skane2600:

          Web tech is currently a cesspool of three-letter-acronyms and frameworks of the month.

          However, PWAs are actually a shiny spot cutting through the swamp fog. The question remains ... are they lighthouses, or will-o-the-wisps. ;)

          I actually share Paul’s optimism for PWA tech, however I also have a very healthy dose of pessimism for any kind of “write once, read anywhere“ dreams. (To be fair, the web is far closer than we have been in the past.)

          • skane2600

            In reply to curtisspendlove:

            The web is arguably the closest to WORA but largely because all browsers are close to being the same platform. But browsers have a more limited scope than a native program and while trade-offs can be useful, not everyone recognizes that a compromise is involved.

  17. Pbike908

    Perhaps I am a complete moron (I know I am at least a partial one). For the life of me, I have NO IDEA what a PWA is. I even went hunting for them. In the Edge store. I couldn't find one. I read up on them. I still couldn't figure out what one is.

    I know what an App is. I use them on Windows 10, Android, and I have used them on Windows phone and an Iphone in the past.

    I know what a web page is...

    I know what a browser extension is...

    I have NO IDEA what a PWA is. If I understand it, its supposed to be an app that runs like a web page. Perhaps someone could enlighten me and send me a link for some ACTUAL PWAs instead of articles about what they are supposed to be or what they could be....From what I can tell, they are a web "bookmark" that can appear as an icon on my home screen, that opens my browser and opens a web page, then once again I ask, what the heck is a PWA in the first place?

    I know Paul sure seems to be excited about he has written about them several times.

    • Paul Thurrott

      In reply to Pbike908:

      You can't search for PWAs in the Store. Just like you can't search for C++ or C# apps in the Store. The whole point of the Store is to make it easy for users.

      Please read the article I link to at the top.

    • codymesh

      In reply to Pbike908:

      the twitter app on the Microsoft Store is a PWA:

      it basically runs in its own window using the EdgeHTML engine, and it can give you notifications even when the app is closed.

    • skane2600

      In reply to Pbike908:

      I'm a bit of a skeptic about PWA's but here a link to a list of apps that are supposed to be PWAs. No, I never heard of most of them either:

      • curtisspendlove

        In reply to skane2600:

        That article with the list is written decently. I’ve only heard of or used two of the apps on the list.

        It is difficult to define PWAs because it isn’t just an API or development flavor, it is a methodology. There is a lot that goes into developing a web app in a user friendly manner. You are to be cautious with bandwidth, you are to cache as much as possible. You should take advantage of the expanding set of APIs to make your web app behave more “natively” and less “web”-by.

        For instance, you should present a functional (as functional as possible) “offline” mode. You should have the user’s last state cached in Local Storage, in case they are low bandwidth or completely disconnected.

        These are also things you can do in a regular (non-PWA-compliant) app, it is just easier to do with the PWA framework. And there is the promise that if you follow the standards, and as the underlying platforms (operating systems) add support, your web app will magically get more “native” as those features are added. Make no mistake...this IS cool. Or will be, if and when it happens.

        I commend Google and Microsoft for digging in and expanding the specifications standards and also implementing it in their OSs. I do have concerns that Apple will do the minimum they must, because they are all-in on native apps. (I actually tend to prefer the native app approach, as it is almost always a more user-friendly experience, but the budget to do native apps for all platforms just doesn’t exist for most companies.) Regardless, that is an Apple issue, not a PWA issue.

        I expect that if PWAs do fully catch on, you’ll see “premium tier” native apps (probably for iOS/Android) and PWAs as a downscale catch-all solution for the other platforms...IF a particular company chooses (or for some reason needs) to support native features or functionality not available via the PWA platform.

        For companies with simpler needs or lower budgets, I do expect PWAs to get to a point where they hit the 80/20 rule (or higher). They will be acceptable enough to cover most common cases for most users. There will always be a need for vertical market solutions. You’re never going to see a PWA interfacing via serial ports to drive assembly bots on a factory floor for instance. (However you *might* eventually see a server/WiFi managed robot floor, with a PWA UI allowing humans to send requests into the system or otherwise manipulate the autonomous systems.)

        The next few decades will continue to show some really amazing things driven by clever, creative individuals. We do need to think differently than we have in the past.

        But again, not a silver bullet. Very cool web technology though. The truth, as usual, is somewhere between “it will solve all the world problems” and “PWAs will slaughter our families” or “PWAs are DOAs lolz“.

    • chaoticbastian

      In reply to Pbike908:

      A PWA is a website that is packaged as an app with a manifest, push notifications, offline caching, and can sometimes integrate with the system on a deeper level like using a camera or file access like the Twitter app.

    • irfaanwahid

      In reply to Pbike908:

      Twitter website is a PWA example.

      You could PIN it or Install it on the local computer mimicking as an app.

      PWAs are websites that behave more like a local app, with Push notifications, accessing local resources such as a Camera, Mic, Location etc.

      • Stooks

        In reply to irfaanwahid:

        So on a PC why is this better than just having a tab in your browser up for Twitter? Lots of web sites push notifications, in fact I am getting tired of them asking to be honest.

        I totally get that on a mobile device a PWA is so much better than a web page because of the size of the device and the limited UI based on that size. Better than a web page but not as good as a native app.

  18. cr08

    IMHO if PWA's are done right and the overall UI (or web UI in this case) is done properly to function as close to a desktop app as possible, it is a no brainer. One of the things that has always annoyed me, especially on Android, in regards to 'web site wrappers' is the fact that the websites are often not fully built to act like a proper mobile app and either miss certain navigation functions or just look wrong. Whereas something like a third party app for the same site which is not a web wrapper functions better. It also brings up the concern for intermittent or slow connections on mobile where the web wrapper needs to load the entire site but a dedicated mobile app may only need to pull from an API or other data source with much lower bandwidth requirements.

    With that said, as an example of two desktop apps that I really enjoy are Discord and Slack and essentially those are already web wrapped apps of sorts. Though I believe much of the 'skeleton' is locally stored in those cases which helps tremendously as far as usability and feel vs trying to load the entire thing from the web on a regular basis. This kind of thing is where I'm hoping PWA's aim towards rather than just a dumb web wrapper. Do a full load from the web on first launch and keep the bulk of the web app local and update as necessary. HTTP already has functionality to cache and expire certain content as necessary.