Hacker News Reader

Comment by fidotron | Hacker News Reader

On a purely technical level the main thing stopping PWA adoption is the JS front end universe being addicted to front end frameworks which destroy the UX of websites and PWAs, but there is a key value add with app stores which PWAs will never have: trust, and much as the Apple haters will hate it it is much stronger on the iOS App Store because of the very things they hate about it.

Chrome, for all of Google's sins, is a modern miracle of software engineering. Safari is nothing like as far off as people make out either.

View on HN

> On a purely technical level the main thing stopping PWA adoption is the JS front end universe being addicted to front end frameworks which destroy the UX of websites and PWAs

I would hesitate to conflate PWA adoption with JS framework popularity olympics. On a purely technical level, the only thing stopping you from using a PWA is you.

Perhaps you should reconsider your product and business model if it doesn't work without App Store presence. The App Store cannot sell your product for you. At some point you will need to interact with your actual customers if you want to succeed.

Having an app "in the store" does not equate to trust for me.

> Having an app "in the store" does not equate to trust for me.

It's not about you, but the users. iOS users do trust Apple as a proxy in the App Store and consequently spend much more there than even Android users do in the Play Store (on a per user basis).

The great anomaly to this used to be Amazon where Kindle Fire users used to have even higher ARPUs than iOS, but I've been out of the loop too long to know if this is still the case.

Not too long ago I decided to push the limits to see what web apps can do now and did https://luduxia.com/reversi/ - there are no UI libs here, the whole thing bundles in under a second with esbuild, and it runs perfectly on iOS Safari.

"On a purely technical level the main thing stopping PWA adoption"

I rather think, the main thing stopping PWA are that browsers still can not decide how to treat them. In some ways you can just do anything unrestricted and in other areas your PWA gets treated and limited like a random untrusted website, with no way to get needed rights. At least that was my experience last time I messed with it.

It is of course a problem to do it right, as prompts for confirmation just gets clicked away, but there should be a way to get real user consent for a proper app, that people trust.

But Apple for example wants to keep their app store under their control, so they surely won't provide an easy way to bypass the normal app store by giving developers a way to ship full apps just through the browser.

Go to any webpage/PWA, hit the share button, hit “add to home screen“.

That’s it. It’s not complicated or restricted in any way.

Its not intuitive for the average user. "Share" does not usually imply "Install" , and the add to home screen option for me is way down in the menu.

You’re not wrong. But at this point Apple has buried EVERYTHING inside the share sheet.

Adding bookmarks, finding on the page, printing, triggering extension actions/scripts… it’s a junk drawer.

It’s not hard to explain to users at least. It certainly could’ve been much worse. Not high praise but it is what it is.

Not on the list of Apple's priorities I guess. If you have an app, you can include a meta tag on your web page and Safari will show users an Get from app-store banner at the top of the page. (https://developer.apple.com/documentation/webkit/promoting_a...) Would it be nice if they did that for PWAs.

Absolutely nobody expects to find installation options under layers of indirection in a share menu.

It’s an intentional choice by Apple that’s hostile to users but very aligned with their strategy to lock users into their own proprietary platform as much as possible.

What do you think the process should be? There are only five buttons on screen, should one of them be permanently dedicated to adding a webpage/PWA to your home screen?

For the record they are the back, forward, share, history/bookmarks, and tabs buttons.

As I explained in another reply, I don’t think Apple is being malicious here. I think they just shove everything that’s not a very common use in there.

I’d be much more inclined to believe that analysis if we were to look at this as a single thing but the moment you look at the consistency of their decisions that they have made regarding the web as a platform it’s close to impossible to impartially come to that same conclusion.

Hm, last time I checked and tried this, there were still limitations, but it has been a while and maybe something improved.

it has changed, at least on MacOS Sonoma. I can "add a website to dock" and it launches in fullscreen if the manifest.json is set up correctly.

On IOS, I can't install a PWA/add to home screen with a simple click. I think thats the bigger obstacle.

You can't install an app from the App Store with a single click.

Perhaps I should have chosen my words more carefully. The obstacle is that its not intuitive that you can install/save this PWA to my home screen via the Share Button. Someone is going to have to tell you the first time. If you open the original link on an iPhone, and click the "Install to Home Screen" button, it'll show you a popup with screenshots and instructions. The user will have to be somewhat determined to install the PWA.

As opposed to an obvious button that says click me to install/download. (The usual Get it on the Appstore buttons), or Smart Banners[1]. The banner/button makes it crystal clear that I can click it to install the app. (Yes, you are correct you may need additional clicks to actually install, but by that time, you are in a familiar workflow).

1. https://developer.apple.com/documentation/webkit/promoting_a...

Can't you? You just hit Share->Add to Home Screen, granted that's two clicks, but it seems pretty straight-forward.

Not really. Not for non-tech savvy users. Try it on an iPhone. First you'll have to find the share button on the browser bar, then scroll down and find the option 'Add to home screen'. I don't think its very obvious.

Most users don't know about it, and need a how-to guide - similar to what the posted link does.

The "share" button is massively overloaded on iOS and has been for ages. It does a bunch of stuff that isn't really related to sharing in any reasonable sense of the word. It's really IMO one of the worst UI elements in what overall is a pretty nice and consistent system

I like this website. I tap on the share button. That lets me do a bunch of things I can do with websites I like, like sharing them or bookmarking them or pinning them to the homescreen.

The front end framework mess is just a symptom of the actual problem, which is that the building blocks provided by browsers are too crude/limited to allow for consistent quality, and so Rube Goldberg machine frameworks arise to try to paper it all over.

I think browsers can be a good platform but for that to happen they need to be a bit more batteries-included, with built in APIs for UI and other essentials that rival those of desktop platforms so crazy frameworks are rendered unnecessary.

Honestly, I believe you have this backwards; the problem with browsers is they are too flexible and complicated. If you delivered a consistent MVC framework in the style of the classic NeXT APIs the major complaint would be the imposed look and feel, which from the point-of-view of a user is a feature, but for whatever reason people are drawn like moths to a flame towards that which is at the edge of reasonably possible and so devs and designers will forever be pushing at the limits until this state of chaos recurs.

It depends on what part of browsers are being spoken about. They’re plenty flexible and capable for the case of traditional pages and server-side apps, but it’s a totally different story for interactive widgets and especially full blown SPA’s.

For example, browsers don’t furnish a tableview/datagrid or even a basic single column recycler view, meaning one has to find a third party library to do those things that’s still maintained, fits into your stack, and has holes in functionality that are tolerable for the use case in question, or if none meet those criteria write it themselves. The result is a million reimplementations of the same thing nearly all of which have major shortcomings (some of which are present only because they aren’t implemented as a native browser control).

I totally get that styling is a pivotal part of web apps but I think that can be maintained without requiring devs to build castles from grains of sand instead of giving them more appropriate building materials to use.

> For example, browsers don’t furnish a tableview/datagrid or even a basic single column recycler view

<table> and <ol>? Or am I missing something?

The big question is how the table gets populated with the data and enables things like column based sorting all executed on the client side. (With the associated interactions with scrolling).

The point of recycling views is as row UI elements scroll off the top they are reused for those appearing at the bottom (or vice versa) which reduces system resources for these things a lot. This way the data table can contain 20 million rows but if the user can only see 100 the UI only pays the cost for 100.

This is standard practice in native app dev and I think is a good example for the case they are making. I would argue such a thing would be needed in the hypothetical NeXT type API of course.

Goes back to static vs. dynamic/interactive. That’s fine for static content but falls apart when you need a table view that can be edited, sorted, reordered, can have columns resized/rearranged, and can contain thousands of rows (necessitating recycling of table row DOM elements to maintain performance and efficiency).

This sort of view has been table stakes for desktop UI frameworks for decades and is a common need.

Reply on news.ycombinator.com