Hacker News Reader

Comment by thosakwe | Hacker News Reader

There are only two real things limiting PWAs in my opinion:

1. Lack of support on iOS. I presume it’ll stay this way for a while (years!). Mobile Safari finally has service workers, but really, that’s about it. No support for “Add to Home Screen” (technically it’s there, but doesn’t work the way it does in other browsers), and a lot of other APIs.

2. The Web is missing some APIs that would really let it compete with native apps. I know there was WebNFC at some point, but it was dropped. No standard/widely implemented API for reading contacts, sending texts, etc. Features like that would really push PWA over the edge and make it awesome.

View on HN

> I presume it’ll stay this way for a while (years!).

It turns out iOS 12.2 will be "one heck of a release for Progressive Web Apps…"[1]

[1] https://medium.com/dev-channel/progressive-web-app-progress-...

It’s a shame they haven’t budged much on push notifications. I know they have a reputation because they are used so much for spammy purposes, but I see that as a UI problem rather than a problem with push notifications themselves. I think if iOS got push notifications we’d start to see non-spammy use cases, e.g. one-click waitlist notifications and no-install turn-based games. One fun use I've found (I have an Android so push is supported) is getting messages with the loss at each training epoch in Keras (see the side project in my profile.)

I think a reasonable solution on mobile is to only allow push notification requests to PWAs that you have added to your home screen (i.e. "installed"), and removing the app from your home screen should remove the notifications. This way it will function pretty much like native apps, and you won't have to worry as much about random requests for spammy notifications - if I've gone through the trouble to "install" the PWA, then it's more likely I have a higher degree of connection to that app than just some random news site asking if it wants to send me notifications.

Things are slightly better in iOS 12.2 (e.g. web share, slightly better PWA restore to fore), but lots of things are still missing or broken [0].

[0]: https://medium.com/@firt/pwas-on-ios-12-2-beta-the-good-the-...

> 2. The Web is missing some APIs that would really let it compete with native apps.

absolutely this. i have no idea why the Contact api [1] work has been discontinued. my current conspiracy theory is that it would have allowed many communication apps to no longer require native apps and cloud-stored address books.

like selecting a file to upload, i dont see why i can't select a contact to use/upload from a locally available address book. So many web apps could use this.

[1] https://www.w3.org/TR/contacts-api/

Regarding your conspiracy theory, it sounds like this could be a realistic worry, of a conflict of interest among those influencial in developing web standards. The "missing APIs" may be those which would provide more competition to various walled gardens.

I'm not really a fan of conspiracy theories, BUT when you consider that 2/3 of the biggest browser vendors also control mobile platforms, you can kinda start to rationalize it.

For 2, this is the one I'm most looking forward to: https://developers.google.com/web/updates/2018/11/writable-f...

Entire classes of PWAs are essentially impossible to build right now because of the lack of ability to work with files directly, think offline editors, offline music players, etc.

FileWriter API existed in Chrome for a long time, but all attempts to push it mainstream failed due to Mozilla. I am curious if the latest attempt gets political backing from all members of W3C. Otherwise PWAs will stay pretty limited for toy apps; with WebAssembly and random local file access they could replace many desktop apps.

And if the standard on all this stuff is delayed, we're risking multiple incompatible APIs on all these features. Case in point: on Win10, PWAs get full access to the platform WinRT APIs (https://docs.microsoft.com/en-us/microsoft-edge/progressive-...). So they can do anything a native app can do - but that code isn't portable anywhere else.

Regarding 2, one point of distributing PAWs via the respective stores is that when their origin is validated, they are also native apps and have full access to all device APIs.

See PWAs on Windows 10, or the recent TWA support on Android.

I am very happy that the web has no more APIs. I'm already tired enough of telling my browser that I don't want any website to send me notifications, to access my location, to access my camera, my microphone. And God knows what goes behind my back. Enough is enough!

That is because of bad usability of the browsers, though.

Default should be for example some icon indicating that the website wants more permission ... and then if I feel like it, I grant more permission. Til the point of fully trusting and giving all access.

But a website is a website I just read and will never get more permissions from me. But a pwa ... like a game, I would grant more permissions. This is something that should be made easy from the browser to choose, whithout getting annoyed by permission popups all the time.

Isn't this usability issue on part of the website developer/ux designer too? What you point out is right, but it can also be implemented in a way where you're not outright just calling the function to pop up that little notification asking for [insert api] permission. It might be a better solution where the ux designer/developer has some sort of button the website that then calls that function for a slightly better experience.

" It might be a better solution where the ux designer/developer has some sort of button the website that then calls that function for a slightly better experience"

But this would be up to the websites then. They could do this now, but they aggressively push for all the permissions they can get in the hope at least some click (accidently) yes.

I do not want popups to click away all the time. I want to decide that I like notifications from site x if they offer that.

For comparison, there's old-school Flash, where the permission box for camera/microphone would be overlaid on the bit asking for said permission instead of modally blocking the page, and if you didn't give permission, it would still work fine, just with blank camera/microphone feeds.

I remember reading about USB access at one point, that'd be fun!

It is here, https://developers.google.com/web/updates/2016/03/access-usb...

Reply on news.ycombinator.com