I don't understand how we got to such misuse of "PWA" in this context (e.g, on both sides of the conversation).
Progressive Web Apps are not a standard. Rather, it is the idea that a an application - presented through a web browser - can use additional features provided by browser _if_available_. The term is based on the concept of "Progressive Enhancement".
Everyone's pet feature - service workers, single site browsers, offline mode, push notifications, video codec support - gets branded "PWA" in their rant that such and such browser is not keeping up. However, writing your web application to require a feature that not all of the common browsers support means fundamentally your application is _not_ written for progressive enhancement.
The reality is that the term "Progressive Web Apps" was coined by Google as they started pushing harder for web apps to perform like native apps - but at the time they had a strategic initiative to have web apps instead of native apps (ChromeOS and the ChromeBooks, pre Android support). None of the other browser or OS platform vendors have that level of strategic investment in supporting web apps as a new 'native' format - especially considering the security model is usually different than that of the native platform.
This is a fantastic distillation of how bitter the PWA discussion often seems to be. I had no idea that “progressive” should be understood as “progressive enhancement” (graceful degradation) rather than “technological progress”.
Looks like the term was coined in [1], which describes the idea of something that starts as a website, but progresses to become app-like as technology and the user’s wishes allow. By that definition it’s your PWA not planning on supporting Firefox.
I have heard the term progressive enhancement used much earlier than that- probably by at least 5 years.
In ye olden days, people used it to mean that websites should be able to work without javascript at all, and not overly rely on new CSS features.
At the time we were making websites for customers that cared about IE6 support. The notion of a "web app" was a dream that most people would have considered a nightmare, given how inconsistently everything was implemented at the time.
The point is that Progressive web app takes it’s first word from Progressive enhancement. For that to be possible the chronology must be that PE predates PWA. The terms are not synonymous.
It would have been helpful to have quoted the sentence you did not understand as I cannot be sure that I now see the same thing you did. However, in case we are seeing the same thing I’ll reword the following sentence for you:
> By that definition it’s your PWA not planning on supporting Firefox.
The above could also be written:
> Under the assumption that a PWA is defined as a website which queries the browser to discover additional functionality, and then goes on to use features it discovers, it is the PWA which doesn’t support a particular browser. Specifically, the PWA likely depends on functionality which may not always be present, which means it it not progressively enhanced.
Apologies if my rewording comes across condescending. I have no information about your level of knowledge on the subject and chose not to omit anything on purpose.
A friend once said, "A buzzword is here to stay when people start arguing about its definition." I don't know if it was in the context of Cloud Computing or AI or Industry 4.0, but you can see the pattern.
I did not downvote you, but I think the general spirit of the Hacker News community is to ensure that comments make good faith efforts to contribute something novel to each discussion. Humor is tricky - certainly humor contributes something, but if you're going to make a humorous comment here as opposed to a more entertainment-focused forum, it should also attempt to expand someone's perspective on the topic. It should be funny or entertain because it lights up some new parts of the brain. Grandparent comment is educating everyone on the origins of PWA to dispute the article, with a proclamation of bewilderment that we got to this place of term misuse, and parent is just giving a very general reason for this happening.
Your joke, at best, is an unrelated and in this case unnecessary example of "misuse" but unfortunately doesn't add anything substantial to the conversation. Even if we "get" the joke, we do not want to trend in the direction of low effort jokes dominating our discussions.
It's interesting how the javascript ecosystem sucks you in until you stop being aware that there is anything else outside your bubble and assume everyone will understand your acronyms.
But then, it's not new. Heard people saying they know "the Visual C language" ages ago. Guess that's how MS started its monopoly.
What's worrying this time is that they're redefining "cross platform" to "runs in the same emulator".
Yeah, that happens to everyone, I think. Web devs forget that everything isn't (some form of) website, Microsoft-ecosystem folks tend to forget that there's a whole world outside of that bubble, GNOME developers... infamously... seem to think no other Linux desktops exist, functional programmers frequently seem to believe that everything should be functional. Honestly, it's probably just a side effect of only having a finite number of hours in the day; to master one system, you tend to forego having enough time for others.
Edge doesn't really count given it's just Chromium.
KaiOS is a platform built entirely on the concept of web apps as apps so saying they're all in here is a bit tautological, and not particularly compelling.
Edge was doing PWA even before it was Chromium. (Arguably better, because Old Edge had native UWP integration stories that Chromium doesn't have access to.)
Even Chromium-based Edge is still doing at least a few things in terms of native integration on Windows (including Windows Store support) that probably "count" as "more than just inheriting from Chromium".
Right. This is hardly the death of PWAs. It just means the PWA experience will just be a shortcut to a regular browser tab.
Which is fine. The Single-Site Browser experience, putting an icon on the desktop that opens a browser with no url bar, extensions, back button, or any of the other features of the browser, isn't actually good. There's a better way to approach web apps with notifications and offline support.
According to MDN (https://developer.mozilla.org/en-US/docs/Web/Progressive_web...) a PWAs are "are web apps that use emerging web browser APIs and features along with traditional progressive enhancement strategy to bring a native app-like user experience to cross-platform web applications."
I would consider being able to install the app to the homescreen part of having a "native app-like user experience". And installing to homescreen is listed as part of PWA on that MDN page.
For now you can supply --ssb on the command line - but I suppose that will go away, if the feature discussed in op is axed (it's not entirely clear to me if axing the pefrence/feature flag includes axing the command line flag - but it seems so).
At any rate - most desktop os' should allow shortcuts to urls - so should support "installing" apps.
> At any rate - most desktop os' should allow shortcuts to urls - so should support "installing" apps.
That's just part of it though. What about hiding browser chrome, or making sure it opens as a new window instead of a new tab, or having seperate window preferences (such as size and location) for it?
And I believe one goal of PWA is that "installed" apps have additional permissions, such as being able to use keyboard shortcuts that are normally reserved.
> If there is some hard data somewhere we've missed that shows we would gain more market share by implementing [SSB] than other projects then that would sure be useful though!
This is a rare opportunity for everyone on HN disappointed about this removal (myself included) to put together a convincing argument with data about how important PWA desktop integration could be. The pessimist in me thinks there's just going to be more derision and complaints without action though. Hoping to be proven wrong.
So the “mobile Firefox” there isn’t really a mobile Firefox just the desktop browser used in a mobile context? Or does Mozilla support such platforms in any official way?
Even the Android Firefox app just got fairly recently rebuilt, mobile isn’t really Mozilla’s strong game after they shut down Firefox OS (which though strangely lives on as KaiOS)
Yes and I thought it make sense. Do people not just use Electron App on Desktop? I mean the App would be packaged as such most consumer wont even notice.
And I thought some of the comments in the Bug Tracker were quite hostile.
It would be nice to not have 80+ slightly different chrome installs on a desktop for all the apps these days.
Shipping just the app code and using the runtime (edge or chrome i guess, would've been nice to have firefox as a modern xulrunner successor) on the end users machine makes more sense to me.
Linux Mint's take on this in it's next release seems the most appealing to me. It's based on "Peppermint Ice" [1]
"WebApp Manager" uses the Chrome/Chromium/FF installed on your machine and creates a separate browser profile for each "WebApp" you configure and launches the "app" or "site-specific browser" in a new window. Details: [2][3]
Works well for simple sites where you're mostly visiting links in the same site, like Youtube.
For Windows Chredge/Edgium is planned to support that via Microsoft’s something-something API which allows to declare Electronesque-mode for a app and get independent updates to the common Electron layer (and hopefully, reduce memory usage).
I don’t recall if such is only available via Windows Store or is only dependent on APPX (which correlates but does not depend on Windows Store - at least not on the server side of it)
oh wow that was helpful, ok there is a uap10:HostRuntime, unfortunatly the same problem than the webview2 has, you need to package your runtime so that it works with the appx model, which is not always the case and thus you need to create your own "runtime" package if there is no electron runtime package that is inside the windows store.
basically if nobody provides an up to date hostruntime package, it will be the same case as it is now.
> It would be nice to not have 80+ slightly different chrome installs on a desktop for all the apps these days.
Especially considering that old versions of Chromium are likely to have more security vulnerabilities.
On the iOS platform, Apple essentially forbids the use of any browser engine other than the WebKit/Nitro engine provided by the OS itself. From the user's point of view this has the advantage of guaranteeing the absence of old and vulnerable browser engines on their system (provided they're up to date with iOS updates, and of course provided Apple hold up their end and maintain their software well).
As AnIdiotOnTheNet points out, this requires app vendors to stay on top of testing their app as the iOS browser engine is updated by Apple.
There's a lot of buzz lately about flash player being retired. Why couldn't Electron copy its approach? Install a single runtime and run all your apps on it (like Archlinux already does, btw); problem solved. It's pretty much how the JVM or .NET have worked for decades.
I understand people don't care about supporting multiple version of the runtime, but there should be a way to reduce the cruft of multiple bundled Chromiums on systems that might have storage constraints (thanks Apple and soldered SSDs)
The JVM world is moving away from that approach. The current recommendation is to use jlink[1] to build a custom runtime image, which doesn’t depend on a JRE being present on the system.
Unfortunately, node modules with native components must be compiled to a specific version of Electron. This non-portability throws a monkey wrench into any "single runtime" approach (you'd need an electron runtime installed for every unique nAPI version).
How convenient nowadays every JS environment supports a platform-independent way to run native code (WASM). I think it could solve the issue nicely, if anyone tried to put in the effort to adapt Electron and tooling around it.
When COVID forced us to work from home, I initially resisted installing Slack on my computer. I don't like Electron, and I'd set up my machine such that installing Electron apps was technically difficult anyway.
IMO, the UX was horrible. I tried to keep Slack as a pinned Firefox tab, but it was far too easy to accidentally move over to a different website, at which point I stopped getting notifications. I also felt like I had to constantly keep my web browser open—I can't say why that's substantially different than having to keep a Slack application open, but for some reason, the separate dock icon helps me to mentally compartmentalize.
When I finally switched to a standalone Slack app, it felt much nicer.
If you would like to try an alternative Slack client which doesn't require Electron, give Ripcord[0] a try. I'm not affiliated in any way, just a happy user. If you really wanted, it's so lightweight that you could use it just to consistently receive notifications that prompt you to check your pinned tab.
From the website: "Shareware is coming back, baby."
I've been on Linux for a while now and have not come across the word shareware in a long time. Odd the it makes me feel nostalgic and (oddly) hopeful (that is: a business model that doesn't rely on tracking, ads or some nebulous behind the scenes actions to monetize you).
Nice, straightforward, simple business transaction. Software sales (especially shareware) is really tough. Wish the author some success for his efforts.
I can confirm from monitoring the traffic coming out of Ripcord that it doesn't track anything about you at all. It's wonderful.
It'll check for updates on launch, performing a single HTTP request, but if you really like you can disable that with an environment variable on first launch and a configuration option going forward.
We need more software like this, honestly. I hate how we as users have to depend on enormous multinational entities to get back the privacy we once had. I happily paid for my Ripcord license and I'd recommend it to anyone else who cares about the same things I do :)
I do. But it's often nice to be able to manage them like an app in the operating system. For example being open them with a command (such as spotlight for mac or searching by name in windows). Always having their own icon in the task bar. Even missing all the chrome around the app window is nice since it reduces clutter and eliminates parts you may accidentally click on.
It makes sense as long as forward and backward compatibility are maintained perfectly. If a future version of the runtime breaks something in your application you suddenly lose a lot of the value of this kind of packaging. Ditto if you make an application that uses features only available in the latest runtime.
This is precisely why Firefox should support adding websites as desktop apps.
Electron is Chromium. Anyone who installs Slack as a desktop app is using Chromium. The more people who use Chromium, the less incentive Slack has to make their website compatible with anything which isn't than Chromium, which is presumably why you can't, for instance, make Slack calls in a browser other than Chrome or Edge.
If the purpose of Firefox is to give Mozilla a say in the direction of the web, they should be supporting and encouraging users to install websites as "apps" through Firefox.
There's another angle to this that was discussed on the Risky Business[0] podcast a while back, namely the security angle. As the recent Microsoft Team's vulnerability[1] illustrated, with many Electron apps any XSS vulnerability turns into RCE. Personally I am moving away from Slack, Discord, and other electron apps like them. The browser sandbox ensures that XSS is "only" XSS and doesn't turn into RCE as well.
Electron has a number of problems. First, as already mentioned, any XSS turns into much more serious RCE bug. Second, the bloat. Third, on platforms like MacOS you're encouraged (soon required) to obtain a code signing certificate, which costs money and time and is often unfeasible for someone developing a simple app, compared to web. Finally, another security issue is/was that Electron releases lag behind the official Chrome releases (although nowadays this is much better).
I'd prefer one Firefox tab in a standalone window (for example: Slack) instead of booting an instance of a different browser.
Granted, I could always have that tab in a separate window, but that groups it with other Firefox windows, making it harder to navigate to when compared to PWA.
Honestly the lack of PWA support (Spotify, Figma, code-server, background sync etc.) was the reason I dropped Firefox earlier this year. I now have a system with nothing but DWM, st and Chromium, and it’s beautiful; no maintenance, no hundreds of parallel Chromium/Electron installations, no need to support proprietary platforms and most importantly no need to be a slave to the Play store, App store or Microsoft store. Why Mozilla wouldn’t support such a libre ecosystem, even though they clearly benefit from it’s existence (check the mobile Firefox usage stats; it’s nothing even compared to the small desktop share) is beyond me. I’ve had high hopes for Firefox after the quantum release, but at this point using anything other than a Chromium or WebKit-based browser just seems to be a waste of time to me, and I’ll gladly take the downside of a monolithic system if it means that I and my users are free from proprietary platform-specific apps and proprietary distribution mechanisms.
> no need to support proprietary platforms and most importantly no need to be a slave to the Play store, App store or Microsoft store
While seemingly replacing it with closed-source web software. Spotify and Figma are listed, but presumably there's others too.
Here's the thing. These web apps are much worse from a freedom perspective than the client-side software they're replacing. You're less likely to be able to run them if the company doesn't want you too, e.g., they normally can't be run without having an account. But more importantly, with closed-source web software you've taken the one thing you actually did own, your data (which once lived on your hardware that you have full control over) and now you've given that to the company too. And you still don't have the source code.
In a freedom sense, this is absolutely the worst of all worlds. Slowly losing ownership of your data as we move to web apps is a path to a Kafkaesque nightmare where a tech company can arbitrarily cut off access to your life's work on a whim. This is already happening.
You can still get by only using apps that let you own your data today, but it becomes harder and harder every year. And at least in the tech community, a lot of this is driven by a mind-bogglingly paradoxical-on-its-face preference among open-source advocates for closed-source web apps over native apps (which are actually "freer" from a data ownership perspective).
Whether you have to log in or whether any data is stored locally isn't a technical distinction made by whether the client is implemented as a browser application or a native application. Your post is one big non sequitur.
Moving from streaming music from my Spotify Javascript client to streaming music from my native iTunes Swift app does nothing for me. I'd say it's actually worse because now my solution isn't cross-platform anymore and I've lost the browser chrome's dev tools like the network inspector.
A browser client puts much more control in the hands of the user. It's one of the last bastions of freedom that we have before all software in locked behind app stores and app approval processes.
My native iTunes app supports hosting my entire music collection as MP3 files that I've bought from any number of services (or ripped myself) on my hard disk that I can simply copy to any other computer and it will play them just fine, in any application that supports that format. That's exactly what 100% data ownership looks like, rendering your claim that the post is "one big non sequitur" absolutely ridiculous.
The fact that users don't usually control the servers with web apps is just a reflection of the fact that users don't usually control anything these days, and most user facing applications these days are implemented as web apps. The average user doesn't have control over their desktop apps either, those apps are dependent on Microsoft/Apple/Adobe servers and even if they aren't "helpfully" syncing everything to a cloud they're sending disturbing amounts of telemetry. As hombre_fatal points out, there's no intrinsic link between the freedom question and the technical question. Enough free software developers (understandably) just prefer a traditional desktop app/local storage design over an API/web client design that people get the impression that freedom respecting apps are always desktop apps. Partly because of that choice, free software is going to keep looking outdated and inconvenient to use while more people flock to SaaSS for the services' superior cross-platform and multi-device capabilities.
I'd argue that most of the time you never owned your data, it was held under lock and key by proprietary serialization formats.
Sure it's physically on your disk, but data is only useful if you own the mechanisms to read and write it. If that software is proprietary you don't own the data.
I absolutely see your point; in theory, a web of many engines and browsers would be awesome. In practice however, at least IMHO, Safari isn’t really a competitor to Chrome at this point, but rather a means of Apple to curb the web and to conform to it’s standards. Think WebP, WebM, WebA (or Ogg/Vorbis - no support for any free/libre codecs at all), PWAs, offline support, push notifications and the list goes on. A serious competitor like the Firefox from a few years ago would have been awesome, but Safari really just seems to push people away from the web platform, much like IE’s lack of support in the past has done. The alternative to a (kinda, but not really) monoculture web platform is IMHO preferable to a platform of fully proprietary native platforms.
> Safari isn’t really a competitor to Chrome at this point, but rather a means of Apple to curb the web and to conform to it’s standards
You got this wrong. Currently it's Chrome that pushes its own standards at neck-breaking speed with utter disregard to any objections. For example, all of the standards that Mozilla considers harmful are enabled by default in Chrome. Or standards that both Safari and Mozilla consider woefully under-specced or badly implemented? Well, Chrome ships them to Google's own teams and then refuses to hide them back under a flag.
Apple may not give enough resources to Safari, that's true. But don't for a second assume that Apple is unequivocally bad and Google is unequivocally good when it comes to the web. I'll take Safari over Google any day of the week.
I don't understand why Firefox doesn't work for you?
i use slack, spotify, figma on Firefox without missing anything.
Lastly I don't really understand the monolithic argument in this discussion.
It's a crappy terminal emulator that has poor support for everything and requires you compile plug-ins yourself to mitigate said poor support.
Some users feel this is good because it has little "bloat". It has pretty high latency[0] to show for it but saves 500 or so KiB on their hard drive[1].
Ironically Apple is also the ones who kicked off the entire PWA race because of the lack of an SDK when the iPhone launched. The messaging then was "build for the web, that is better than native" and now its "native or gtfo" and web apps are not preferred. The last 5 years that I've built web versions of apps first, the client told me "look the web app is great, hard to tell its a web app honestly. Except when I want to..." and you all know the rest of the conversation from here.
Firefox, I love you, but you're bringing me down. We need a powerful, semi-native, offline capable architecture for the web. I don't care about the PWA spec, it's quite messy handling the implementation of one. But I do think it has always been the vision that the web is accessible regardless of physical connection to it.
As long as I can remember in this industry we've swung back and forth between "thin" and "thick" clients as if one way is the right way. Microservices over monoliths, etc. It's all the same symptom that naturally we don't want to grapple complexity. This announcement is yet another entry in the cannon of thin vs thick. It's a hard problem and any PM who only cares about optimizing time spent will say everything they can once they've zeroed in on the perceived waste.
Apple's love for native apps began - if I remember correctly - with the popularity of jailbroken devices and third party app stores like Cydia that could unleash the full potential of iPhone 1. Until then, Jobs was stubbornly against giving developers access to the native ecosystem and preferred that they develop web applications. I wonder if browsers would be full-fledged VMs by now if we had continued along the web application trajectory.
This seems like a misconception. It's clear that Apple was brewing the SDK for developer adoption and that their crowing about web apps was a stop-gap measure.
Are we really imagining Apple brought out a public SDK, set up the app approval system, certification, all that stuff, updated Xcode to support it all on a whim in under a year (starting with iPhoneOS 2) just because Cydia existed No way, José.
Apple are good but even they can't pull all that out of their ass overnight. Web was clearly a stop-gap because the SDK wasn't ready and iPhoneOS was, at the time, an outlier in purposefully not supporting Java ME apps.
Apple's love for native apps began - if I remember correctly - with the popularity of jailbroken devices and third party app stores like Cydia that could unleash the full potential of iPhone 1
As someone who developed a couple of the first round of web apps for the original iPhone, while waiting for the first SDK, I can tell you that this it not true.
To someone evaluating it from the outside using a list of release dates, it may seem logical. But an SDK isn't invented overnight.
Hmm you are right I came to that conclusion largely from Apple's original messaging and the change in stance around the time jailbreaking was getting popular.
> As someone who developed a couple of the first round of web apps for the original iPhone, while waiting for the first SDK, I can tell you that this it not true.
Were you given early access to the SDK before release?
Apple killed Flash by not allowing it to run on iPhones and iPads. It seems to me that Apple is doing the same thing with the features usually associated with PWAs.
It is interesting that Apple devices are far from having a monopoly in the mobile market. Yet their influence is so great that they can kill platforms just by not supporting them.
> Apple killed Flash by not allowing it to run on iPhones and iPads.
This old chestnut? This many years on and people still say this?
Adobe killed Flash through their own engineering incompetence, not Apple through policy. Apple's policy merely reflected the liability that the Flash plugin posed.
Adobe could not deliver a version of Flash on mobile that didn't chew up CPU cycles. They tried on Android, it was rubbish, and Adobe themselves deprecated it in 2012. That's only two years after Steve Jobs published Thoughts on Flash.
For Flash content to make any sense on mobile, with its lack of mouse pointer and persistent keyboard, developers could use Adobe AIR, a separate SDK from that used to make Flash web applets. One of the earliest apps ported from Flash to AIR, Machinarium, was a memory and battery hog — not even a new runtime could let Flash content from running unacceptably on iOS.
And all this in addition to Flash spinning up fans on desktops and laptops due to its inefficiency, let alone mobiles. Not to mention the security vulnerabilities in the Flash plugin and renowned instability that caused it to be the major source of browser crashes in Mac OS X.
Between Adobe deprecating their own mobile Flash plugin for running applets in Android browsers, the abysmal performance of Adobe AIR apps, I'm quite happy to say the one to kill Flash was Adobe, not Apple.
Can we put this one to rest at last?
> Yet their influence is so great that they can kill platforms just by not supporting them
Well, aside from not supporting a platform from a vendor that can barely support it themselves, I'd say Apple is more responsible for the rise in adoption of HTML 5 features (WebKit invented <canvas>, iPhone and Android together accelerated websites to display video in HTML players rather than depend on Flash/Silverlight, etc.) than the killing of something that was already dead.
Apple merely saw the writing on the wall. Perhaps they did contribute to making it happen quicker but it would always have happened.
That particular change to the iPhone Developer License Agreement happened in April 2010. It was relaxed, or rather reverted, in September 2010. The latter version of the agreement actually allowed limited support for running scripts on-device.
> There was certainly more pettines there than "Steve didn't think Flash was performant enough."
It's important to distinguish between Apple not wishing for Adobe to create a meta-platform atop UIKit (which started just prior to the release iOS 4, roughly the start of 2010) and not bundling or allowing the Flash plugin (since day one, mid-2007). Thoughts on Flash reflected criticism received against Apple for that three year run.
It wasn't performant in 2007. It wasn't performant in 2008. It wasn't performant in 2009. It wasn't performant in 2010. It certainly wasn't performant in 2011 when Adobe killed it for Android.
It's not that anybody, let alone Steve Jobs, thought it wasn't performant enough; it wasn't performant enough. Anywhere. On anything. Full stop.
And to say Adobe's technologies made for a lesser experience when used on iOS wasn't entirely unjustified. Reviews for Adobe AIR games released in 2010 and 2011 all centred around one major point: they were CPU hogs that chewed up battery life noticeably worse than other games at the time.
True. Apple is currently the biggest threat to the free and open web as (they even force their own browser engine on their users and ban anyone who tries to use anything else). The EU should step in and force them, just like they forced Microsoft in the past, to allow multiple browser engines on their devices.
There's a huge difference between the EU vs Microsoft antitrust investigations involving Internet Explorer. This was at a time when Microsoft was still the dominant player in the market and IE had a stranglehold on the browser market.
By contrast, Apple doesn't have a monopoly on the mobile device market, the browser market is dominated by Google's Chrome, and the majority share of browsers use Chrome's Blink engine.
'PWA' is a Google-invented term to describe technologies already implemented in their own browser; none of it constitutes a single standard unto itself. Apple not fully implementing Google's standard, made not for the benefit of the open web but to make ChromeOS a little more functional than a glorified web browser, is only a threat to those who've forgotten that coding for one browser is what got us stuck in the code-only-for-IE mindset and halted progress for browsers for about a decade.
Apple isn't the biggest threat to the free and open web. Google is. Everybody's using Google's browser, based around Google's own standards designed to force people to stay using Google, to access Google's search which displays Google's ads above Google's curated AMP results.
iOS safari users have made up at least 50% the traffic of the last few sites I’ve launched. In the US at least they effectively have veto power on new browser features.
They haven’t vetoed any features. Google added a lot of features without implementation (and security) in mind. The last parts of “PWA” are its most vulnerable, and with apple having such small safari team, they don’t have the same capacity to help google do it’s job, since they rushed all the features without presenting to W3C.
Push notifications are the most obvious example of a feature webapps need to compete with native apps that Apple has so far refused to implement on iOS. They’re also much aggressive about wiping out local storage data.
Whether you agree with these decisions or not Apple is clearly and deliberately using its influence to limit what a web app can do.
Apple is clearly and deliberately using its influence to limit what a web app can do, in many cases to protect users against features that are poorly designed and harmful to privacy.
I don't see how supporting push notifications for native apps is any different than PWAs. The user would still have to explicitly enable them for the installed PWA, and could revoke it at anytime. Safari for desktop actually supports push notifications [0]. So why not mobile Safari? Even the their aggressive deletion of local storage could be handled with a permission request. Once you've installed the PWA it could ask the user to store data for longer. Basically what I'm getting at is that Apple already has a robust permissions system that could easily be extended to support PWAs and the necessary features, but they seem to choose not to do so.
Bluetooth does have privacy issues, but again, that's no different than a native app. If I install a native app, it doesn't get free reign over BT or any other device feature. In order to use any hardware feature a native app has to request permission to use it.
I don't understand how a web app is any different in that regard. A PWA could specify the features it wants to use in the manifest.json just like a native app does with the Info.plist. Then iOS could prompt the user in the exact same way. If the iOS permission system isn't a good design (I think it is) then why do they keep using it and expanding it for native apps but not use it for PWAs.
Apple has the ability to remove apps which abuse their permission requests, e.g. by lying to the user about what they are going to use the permission for.
Not so with websites. The bar for including new functionality in browsers is way higher than it is for native apis because there is no way to police abuse.
But at the same time Apple was kicking out templated apps claiming these apps could be built using web instead [0], although Apple retracted it later [1].
Web-based applications on iOS are already very dangerous to the app store when developed properly. Apple would have to intentionally sabotage safari in horrific ways to get the cat back into the bag on this one. PWA is just a tiny distraction in the grand scheme of things, but it is a good place to have this conversation regardless.
The problem right now is that you need to go outside the sandbox in order to make a web app feel first class.
Chrome has solved it with a modal/dialog that ask users to add the app to the home screen, but I think the modal/dialog in Chrome is too spammy. It's better if users can do it manually, but its currently hidden too deep in the Safari UI, and Im not even sure you can reach it in mobile safari UI.
This title is a bit misleading. Progressive Web Apps are supported on Firefox mobile, on android at least.
The real issue people should be discussing is Apple not supporting PWAs, or in fact, any browser engine other than Safari on iPhones. It's the real blocker to wider adoption of PWAs (and many other features!)
Until that happens, whether Firefox desktop / other platforms support this specific behaviour (Single-Site Browser) is a bit moot as it's an edge case compared to 50% of mobile users.
> However, you can not trigger an installation prompt like on Android.
You can't trigger a native prompt automatically, but you can detect if your web app is installed as a PWA. With that information you can show instructions.
You also have a ton of limitations like no background updates, no location, no bluetooth, the app’s data gets deleted after 7 days, if you don’t use it, etc
This is not true, it's a misconception about how the seven-day-counter works when the app is installed on the home screen.
Nevertheless, persistent data is a concern, because the standards do not specify how long data must be kept, so it could get wiped at some point, for example when the device is low on disk storage.
This. Majority of both Apple’s and Mozilla’s stance are based on the lack of standards for the PWA. The final checkboxes for both browsers have unchecked usually reflect the lack of clear specs from Google (since they shipped publicly before draft in W3C) pushed to help their own agenda.
Bluetooth is widely used for user tracking. There are good reasons why a lot of arbitrarily introduced features haven’t been adopted by Apple or Mozilla.
I've removed a bunch of features over the years from Blink/Chromium so I get where they're coming from (and I've written basically the same rationale about the implementation being buggy and unmaintained/not on a path to shipping).
That said, while I don't have access to the user research they quote, I do wonder if this move is short sighted in the bigger picture of desktop apps being built with web tech.
Given the popularity of Electron and the recent gaming platforms built as PWAs, it seems likely apps will probably start being distributed as desktop PWAs in the near future. With this move Firefox have cut themselves out of the running though so they'll get caught off guard when some big name player releases a popular desktop app through this channel.
I can only hope that someone at Mozilla is taking business strategy into account and not only technical complexity.
This is a shame, I was waiting for this feature (and actually didn't realize it was already partially implemented). In the meantime I've been doing this with Epiphany, which is sadly a bit lacking in other ways - it still doesn't have WebRTC support for example.
Hoping Epiphany will get WebRTC support soon, it's the most promising browser on Linux phones UI-wise, and I plan to use one of those when there's one powerful enough to be a daily driver.
Of all the organizations out there to support web technologies, I would have expected Firefox to be at the forefront of this. Sure, the Chrome team at Google push PWAs, coin terms, and lead many new feature pushes. But that’s all opportunity for Firefox to help standardize the idea of PWAs and make them something more. Web apps with native functionality can help break up monopolistic practices...but only with support from a wide range of actors.
I wonder what Firefox can do to halt this negative feedback loop it seems to be in? Now more than ever we need multiple competing implementations of the Web APIs, so that the Web doesn't go the way the native apps have already gone.
Nothing much, it's like fighting the sea at this point. Internet comments run on a hype cycle. Firefox had its high relatively recently with the Quantum project. Now it's on the downward slope where everything big and small is not just wrong but the worst thing ever.
The upside is that eventually the hype cycle will again turn in their favour. Hopefully they can capitalize on that once it comes.
Could we, as users, do some fund raising and hire Igalia (or some other competent developer) to implement PWA support in Firefox? What would be the best way to organize it? Is Bountysource still a thing?
Getting major UI added to a browser is not Igalia/Tidelift/etc. forte. They provide development for engine level features like supporting a new CSS element or ECMAscript function. SSB needs OS integration on Windows, MacOS and Linux. It needs UI elements such as toolbar buttons and menu items. Getting that sorted is a non-trivial task. Then there is the ongoing maintenance. This is not something where a few unit tests are going to keep the feature functional as new code is developed.
that's very sad. Just yesterday I helped a family member install firefox for their android device, and installed an adblocker, to replace their news apps with "Add to home screen" PWAs (they were sick of the billions of ads in the apps).
Now it sounds like they're not killing the mobile PWA yet, but it's a big selling point of firefox as far as I'm concerned.
I was also just starting to switch to firefox on desktop (just installed my main plugins yesterday) for my main browser, but this is really making me reconsider.
Personally, yes, I enormously want this, and as a Firefox user I have various PWA apps that I have to run standalone via Chrome, purely because Firefox can't do it.
Being able to have a desktop window and traditional shortcuts per 'application' is 80% of why electron exists and is so big in the first place. Chromium powers that whole market. Moving all of that to PWAs that could share a runtime and use Firefox internally would be a huge step in a good direction.
Literally just switched a project site to a PWA because screw you AMP. PWA's are a great way to get around paying the 30% app store commissions and super useful as we get app fatigue. I have at max 4 apps on my phone, I delete more than I download and PWA's do more than enough to make me happy with my browsing experience.
Firefox seems hell bent on going down a deep dark path. A path only they seem convinced about. It will come a time where they'll have no takers. And we'll be left with chromium.
Controversial take: I want to see this happen sooner rather than later. So the internet can finally wake up. And we will be forced to build something that actually works for ALL the internet.
Again another controversial take: I want Firefox to die and burn so that we can build a new FOR ALL browser based on it from its ashes. It is open source after all.
The reason I'm arguing for the worst possible outcome is so that we can have the change we badly need. We cannot take back Firefox while Mozilla is still at the helm of the browser.
Not listening to your user base and making iron-fist decisions like this over & over again will make this a reality sooner rather than later.
What makes you assume anything would different if Firefox dies?
As far as I can either both Chromium and Firefox could be forked right now, just as easily as they could be in an objectively worse future that you seem to want.
The reason Firefox and chromium are supported is because it’s an insane amount of professional work to develop a browser, and they are both funded by money from Google search.
Where is the funding to develop an alternative going to come from?
I get it that you want to fight for Firefox. I really do. It's just that my fight is somehow for it and largely for the entirety of the internet.
> What makes you assume anything would different if Firefox dies?
At the very least we would be free from the clutches of Mozilla and it's gross incompetence.
Chromium & Firefox browsers have been forked plenty times by different developers/corps for different reasons.
The internet battle won't be won by a fork. The most famous of forks being Microsoft Edge, another evil player. Which is surprising close to surpassing FF btw [0] It's so bad even Safari is ahead of Firefox on the desktop market share.
As for funding Firefox, they can and should be actively pro-donation. I would be willing to pitch in even if it made a slight difference. Pocket & VPN should be marketed and developed upon. Am sure there's more the mother entity can come up with to add to its revenues. These alternative projects should be pursued using an R&D budget from its revenue. Firefox is still a large enough player in the browser game, its search engine default is a gold mine commanding hundreds of millions from top investors.
If they fire their top dollar guzzling CEO [1] and continue to trim down on non-essentials, I don't see any reason why Firefox couldn't get back on track to its former glory.
Simple Firefox dies Mozilla does too. I mean this doesn't require any explanation.
The point of trying out new products like VPN, relays SHOULD be to find alternative funding for Firefox's development. Also what makes you think it is only Google who can fund Firefox? This is a pretty shallow (and lazy) reasoning, pardon my language.
I'm suggesting we disband Mozilla as it is the core problem with Firefox. Clean browser from scratch or not, we need a chromium alternative.
Direct question that cannot be answered at one go. Though I sure do know I don't want Google directly involved with the funds to the browser engine alternative. This poses the biggest threat to internet freedom and privacy in general.
Dude. I've tried to point you to the answers of all your questions. Is it that you can't stand any FF/Mozilla criticism or you deliberately want to ignore the suggestions I've put across towards answering some of your questions?
Glad to see you can put emotions aside in your arguments though. Above remark on Google's funding wasn't meant to be an insult.
I have no special love for Mozilla, and I’d love for there to be a true alternative.
I don’t see any answer to the question of how an alternative browser would be funded in what you have said, only your statement about it being lazy to think that only Google could fund them.
Maintaining a browser is expensive. I think if Mozilla dies, either another major sponsor would be needed or we’ll just end up with the web becoming even more Google’s platform.
In the absence of an answer to who pays for the development, I don’t see how a new browser will emerge. Killing Mozilla doesn’t create funding for a new browser.
Why I have continued to ask you this question, is because you seem to be convinced that an alternative would arise if Mozilla died.
This leads me to think that you must be aware of someone who would be motivated to pay for it. Perhaps I’m wrong about this, and you just hope someone steps forward to pay for it.
I am utterly flabbergasted. Why is Mozilla being so dumb ? There should be no argument at all about delivering this feature. Are there people in Mozilla trying to kill Firefox ?
I've been watching Mozilla's actions because they often seem to be incongruous with what you would expect them to be from their publicity. In other words they often say one thing, but do something else.
Opening the user research would make this more obvious, so that's probably why they don't allow this visibility, even though it would make sense according to their published principles.
Why are they doing this? I've no particular inside information, but occam's razor says it's follow the money - that Mozilla's true reason for existing is as a protection for Google, and that Mozilla's published positions are virtue signalling, but their actions serve their real masters at Google.
It sounds controversial, right? But if you are ever interested in the red pill, explore this possibility by considering these facts.. (and if you're not - leave this post up so others get the chance to think about it for themselves)
- Google provides 95% of the money for Mozilla
- Mozilla is a lightning rod that attracts and focuses the user centric parts of the ecosystem/market, but ultimately fails to achieve the goals of giving users power and instead year after year the power remains with google
- Mozilla must play a fine line between virtue signalling to prevent competitors who would truly organize for users benefit, vs actually doing things that would tip the balance of power towards users
- Mozilla thus talks about lofty goals to capture the idealist mindshare, but consistently fails on good execution so the pragmatic choice remains to use google products instead
- This pattern has been so consistent over the years I've come to the conclusion it's deliberate .. and the reason is probably because: follow the money, ie Mozilla is funded by Google
- If Mozilla leadership isn't doing this intentionally then they are being used/played by Google, however Mozilla's CEO is now a corporate lawyer not an idealist, who's taking home big bucks, so that's an indication that Mozilla's leadership is in on the game
.
So in answer to your question, Mozilla's user research can't be open because that would increase visibility of situations where Mozilla's conflict of interests cause Moz to do things that benefit Google rather than general web users, and Moz's leadership don't want their hypocrisy to become known or their game will be up and the paychecks stop.
On the conversation they mentioned about higher priorities on the Firefox, I wonder if they have open roadmap for us to understand the priority in Firefox.
This is a feature that would save memory though. Instead of running N different copies of Electron or both Firefox and Electron, you could install PWAs to your desktop and have a single running browser on your system.
Damn, I use this feature everyday for the chat window at my job... It works wonders with i3WM/SwayWM and it's the best way to get a webapp in a independent wayland compatible window.
Though here it’s rather “we experimented with this thing, and it turned out to not be as useful as we expected, and it’s a maintenance burden, so we’re removing it”.
What are you talking about? XUL Runner didn't get a release in five years, and XUL is being removed from Firefox. And where did you see Mozilla wants to "ditch app sandboxing"?
Other Browsers have support for PWAs, including Safari/WebKit, which means that it's as simple as --pwa=url to ship your offline ready application.
In Firefox, however, it still requires an application.ini file and an xul:webview to do so. XUL cannot be removed as long as something like a simple webview isn't possible. And something like --pwa=url via CLI is pretty much the correct way to offer this type of featureset in my opinion; as all other Browsers (read as: really all, even Edgium) have support for PWAs.
WebKit, compared to Chromium, has due to the availability of its bindings (like webkit2gtk) even better sandboxing capabilities; with an isolated userdata cache and an isolated webdata cache that you can set to e.g. /tmp/websandbox.
Trident, the old engine behind Internet Explorer, also had this kind of featureset; similar to how WebKit's bindings are built...which is the reason why they still stick around on Windows WPF based apps, and probably is the reason why Edgium and Chromium are working so much on the CEF (Chromium Embedded Framework) in order to replace it.
Additionally, firefox's profile manager concept doesn't allow to fully sandbox a web application in /tmp - not even with an XUL based webview, because it'll always leak out settings in various ways (on Windows, on MacOS, and on Linux).
The unfortunate truth is that Firefox is irrelevant now. There’s just not enough value to users in a completely independently browser engine. And if there’s not enough value to users then there’s no sustainable business to build on top of it. Those of us that love the web should divert our energies to keeping Google and Apple honest IMO.
Just by being an independent browser engine, firefox is arguibly one of the most important open source software projects - since basically everything is web-based nowadays and they are the only thing making the web the web, instead of a fancy google chrome runtime.
Other than that, I pretty much value having actual privacy when browsing, and firefox is really really good at that with ad-blocking (which may easily go away with chrome and with the pace of development on it, forks will be in a pretty bad situation), containers, etc.
I'm a big fan of Firefox as well and appreciate some of its unique features like containers. It's improved a lot in the last few releases.
But none of my clients even ask about Firefox support anymore. They don't care and neither do 99% of their users. Supporting FF maybe be the morally correct and heroic thing but it's like being vegan. You're a rounding error on policy decisions that matter.
As a thought experiment - what has the existence of FF done to prevent Apple & Google from going their own ways lately on web features? Not much if anything at all.
So what? Everyone should just give up because it's too hard, and let Google run the show?
There is a couple of antitrust lawsuits going up in the US against Google. If we're lucky, one of them may break up the Android and Chrome arms of Google (or Alphabet, I guess) and/or require a ballot screen to choose a browser on Android, like the EU did for Windows and IE.
And there may be other opportunities in the future for Firefox to regain some equal footing with Chrome. But that can't work if we declare Firefox dead.
All anti trust against Google is going to to is strengthen Apple and accelerate the migration to proprietary app silos. It’s not going to drive a Firefox renaissance.
Most likely it will be executed so ineptly it will end up strengthening Google too.
> But none of my clients even ask about Firefox support anymore. They don't care and neither do 99% of their users. Supporting FF maybe be the morally correct and heroic thing but it's like being vegan. You're a rounding error on policy decisions that matter.
I don't know... my bank launched a new web interface for online banking and they seem to take my firefox bug reports seriously.
Show me another browser that runs uBlock Origin and has both a facebook and google container...
Mozilla could do whatever they want with their branch.
I'd trust a chromium based browser controlled by mozilla over google chrome. Even now when I want chromium on windows I choose edge over chrome. I'd love to be able to choose something from mozilla instead.
I've used firefox for years and will continue to use it. But at some point firefox will be a niche product trying to find it's niche.
You do know that one can publish PWA:s to Google Play Store by using TWA:s + that Google are experimenting with allowing plain PWA:s there + have recently launched a way to still allow in app purchases in such?
Also – on desktop many apps are Electron apps today, which is a user hostile workaround for lack of installable PWA:s.
Basically: It’s a way to verify that an app represents your site and then that app can open up the PWA inside it (a bit tricky to explain, but it’s great if one wants to be in the store and/or have an existing non-PWA app that one wants to upgrade to a PWA)
I can probably name 20 different websites that I use that have crappy apps (that they try and force on me).
Using a PWA for any of those (provided it gets rid of their terrible app banners) solves that problem for me as a user. I don't want to try and guess which app has broken their copy/paste or back button and have 20 different slightly broken UI's and experiences.
The advantage of the web is a consistent U.I. interface, with all the basics working (copy/paste, back button). This means there's a much higher chance of those working for the user, I don't see how you can say that's bad.
Even ignoring that, which do you think would be better, a platform that they put 3* the amount of time into or 3 separate platforms (if the devs are forced to build the same thing 3 times)?
You’re talking about poorly designed web apps, which are designed to get users to convert to native apps because installed apps have a higher retention rate and are easier to siphon data from.
PWAs don’t solve those problems for marketeers either. They just annoy end users by making them do some funny dance to get the app on their home page, which then barely works and doesn’t support all the features a native app can handle anyway.
So you end up in a world where developers say “we have a mobile app, it’s a PWA, just install that” and then no one installs it because they don’t know how, and the marketeers get frustrated that the current web app isn’t sticky enough on mobile and so they add banners in to make people download the “real” app and you’re back to square one.
The only real solution is cross platform development toolchains (like electron) as they reduce the development overhead but allow for native apps.
It sounds like you think the problem is discovery. There’s some disagreement between browsers as to whether the install button should be supported to make discovery easier, but that’s not a very large hill to climb, and would save us all from having 5 to 10 copies of chrome running at the same time.
Maintaining 2 different apps (a native one and a web one) is costly in terms of time/resources. The point its not that developers "don't want" to make both, is that many don't have the resources to make both.
The core problem with PWAs is that ultimately the success of the overall idea is held hostage by the level of consensus across the browser development teams. Whilst they "collaborate" on "common" web standards (they being many, btw), iOS and Android (note: only 2) have very well defined apis for how to create awesome native UX. The problem of creating a unifying native abstraction (like react native or flutter) that is actually effective from the User's POV, is far more attainable, than that of trying to create a consistently awesome PWA with such inconsistent browser support, across a far greater multitude of platforms than the iOS / Android bifurcation in native-land. My $.02.
PWAs have always seemed like one of those beautifully idealistic yet totally doomed to fail ideas (at least for several years relative to native-based-approaches). Don't get me wrong, I think the web will ultimately evolve into the new JVM (read: via WASM), and the beatific promise that was foretold by PWA will finally reach the masses.
Reality Check: We're not quite there yet. Firefox deleting a legacy, buggy, and dev-time-sink attempt at this, makes total sense to me so they can focus on the other awesome stuff they're doing that actually creates real value for the masses today.
To be fair - perhaps they could've handled the ticket on this a bit more gracefully...? But then again - they know their stuff, so I don't blame them entirely :)
My company’s payroll admin system uses a PWA as a mobile interface. I don’t need slick ui there, I need to view my payslips (click a link to open a pdf) and request time off (fill in a 4-field form). It’s perfectly fine for this usecase and there is no conceivable business value in pouring more resources into it.
News flash: a majority of applications is simple CRUD like this. They don’t need a native UI or performance. They just need an icon on your homescreen.
Rude is telling developers their business model is not good, because they cannot affort to build native apps for Windows, Mac, Gnome, Kde, Android, iOS and web. If you cannot work with PWAs maybe you just aren't in the targeted user group.
Not everyone is building a next Instagram for hundreds of millions users. There's a long tail of smaller business niches which might sustain a solo developer / small company and there having one codebase is obviously critical.
Actually I find that the user experience on PWAs and Electron apps is better than that on native desktop apps. Developers have always been challenged in building desktop apps because the available toolkits are generally crusty, limited, and complex. GTK, TK, QT, Windows Forms, don’t compare well against what can be done in the DOM.
Nobody is telling users to install a PWA. Just because a site has all the features to be considered a PWA doesn't mean your user must use them.
But they are telling users to install apps. Sites that depend on advertising want to force the app down your throat to eliminate ad blockers and to better track you.
I think you have it the wrong way around. The app stores are user hostile. Building applications on the web rather than locking them down on platforms is a really good idea. And if anything developers should move towards them to break the store dominance whenever possible.
I've had a perfectly good MP3 player on my phone get deleted because Google can't be arsed to leave it alone, they want to force me to a subscription based app to play songs when it's in my pocket!
That thing is 100% native code, don't act like web apps are the only thing to do this. You can be a bad actor regardless of the tech stack.
But try to use them, and you get dumbed-down ‘mobile sites’ with massive ‘use the app instead!’ nags. The web on a mobile device is an unnecessarily lousy experience.
It’s been very long since they promised us that web apps that use systems such as Cordova would work as well as native apps. That hasn’t happened yet, and will never happen I guess.
Apps are actually user hostile by far. They're also developer hostile.
Web apps are all about freedom. They're free for the developer to distribute, they allow the user freedom to run on any device they own and they also allow the user some freedom to alter the app via extensions/ad blocking/etc.
I was going to reverse that: who cares about PWAs. Sure in some edge cases I can see PWAs being a temporary solution. If you want to create a desktop app, just do the work or don’t do it at all. Don’t pretend you have a standalone desktop app if you need to start Chrome to run, yes Google I’m looking at you and your retarded Chat app.
In other words - replace one horrible mess with another for what is ultimately only a web app.
Moreover, it is a complete red herring - there is not much advantage in a "much more up to date browser" in an app that will ever open/download a single page (so security or newer standard support is rarely a problem). Never mind that even the Electron apps can be (and are) updated frequently.
Also, PWAs are unable to do many things that Electron apps can as PWA is still ultimately in a browser sandbox whereas Electron runs a Node.js backend that can do pretty much anything a regular desktop app can (networking, access hardware, etc.).
That said, I am certainly not advocating Electron, it is a horrible kludge leading to poorly designed applications that break desktop usability conventions constantly, are enormous resource hogs and require weird workarounds for doing basic stuff only for the sake of being able to do user interface in HTML and javascript.
>Also, PWAs are unable to do many things that Electron apps can as PWA is still ultimately in a browser sandbox whereas Electron runs a Node.js backend that can do pretty much anything a regular desktop app can (networking, access hardware, etc.).
This is precisely why I would prefer many of the Electron apps that I've used to be PWAs instead. For many apps I don't trust them with access to e.g. my entire filesystem; a PWA would get me the nice UI, notifications, etc of a native app while still keeping them in their sandbox.
The problem is that those apps are often Electron because they can't be done as a pure browser app. If the browser doesn't expose some system API then what do you want to do?
Is it? The prospect of a single standard is still pretty enticing to me. Granted, you have things like Cordova, Flutter etc that already solve the single codebase problem. But under the hood they all “convert” things to native XY and Z. Don’t you think that a single standard like PWA would be better for the industry in general?
It will kill a lot of monetization, which is probably why it failed to get much traction with Apple.
PWA are the only plausible way towards a more free internet and apps, too bad people don't see it. No matter how much it benefits google, it benefits us all in opening up a world beyond app stores.
1. The iOS App Store is popular because of safety and privacy. Obviously that involves trusting Apple which is undesirable even if they happen to be good custodians right now. The play store is no better. If we had a decentralized solution to these problems, it would be a lot easier for other platforms to emerge.
2. It seems like we are close to the point where you could build an ‘app player’ which is based on a small subset of web technologies such as webgl, wasm, websockets, and webrtc.
Implementing this could be done much more easily than supporting the giant stack required to browse the modern web, so it could be done by a genuine open coalition without a controlling corporate sponsorship as is required for a browser.
Possibilities aren't viable alternatives, the problem is that of all existing options PWA are the best because you can escape app store and play store while providing app-like experience to users. I think google is the greatest evil of our time, but in this case we have nothing better.
Seems like Firefox is afraid of retaliation from Apple. If you could sidestep App store then likely Apple would have banned FF altogether from their computers and phones.
Progressive Web Apps are not a standard. Rather, it is the idea that a an application - presented through a web browser - can use additional features provided by browser _if_available_. The term is based on the concept of "Progressive Enhancement".
Everyone's pet feature - service workers, single site browsers, offline mode, push notifications, video codec support - gets branded "PWA" in their rant that such and such browser is not keeping up. However, writing your web application to require a feature that not all of the common browsers support means fundamentally your application is _not_ written for progressive enhancement.
The reality is that the term "Progressive Web Apps" was coined by Google as they started pushing harder for web apps to perform like native apps - but at the time they had a strategic initiative to have web apps instead of native apps (ChromeOS and the ChromeBooks, pre Android support). None of the other browser or OS platform vendors have that level of strategic investment in supporting web apps as a new 'native' format - especially considering the security model is usually different than that of the native platform.