Hacker News Reader

Comment by fictionfuture | Hacker News Reader

PWAs on iOS mean a huge shift in strategy for startups.

In many cases(including mine) it now makes more sense to go PWA first instead of native.

I think in terms of business apps (not games!) it's better to go PWA first. Check out this really good case study of the Starbucks PWA.

The PWA is 233 kb compared to 148 MB iOS native app.

https://formidable.com/static/Formidable-Case_Starbucks_PWA....

WebAssembly (plus PWA) is kind-of promising in terms of games, no?

Promising, maybe.

Still not practical. APIs available to the web ecosystem are always going to be one level abstracted or behind their fully native counterparts.

This case study is nonsense. There is no case in which a native app will be 148MB in size, while a web app with comparable functionality will be 233kB. None.

Quite aside from anything else, the Starbucks PWA is a strictly worse experience than the native application.

Interesting. So please let us know your about your experiences and strategies on maintaining applications across several platforms (iOS, Android, Tablet and Desktop) while keeping binary sizes small with comparable functionality and good user experience. I'm willing to learn and improve on that topic.

I worked on the PWA from its inception until the past few months. The size difference is real, and I'd wager that it was 75% at parity with the native featureset at the time I left :)

I'm not so sure. Developers may be excited at the chance to forgo the App Store / Play Store, but will users get onboard? They've had 10 years of training to download an app from a store. Will the flow for onboarding with a PWA be a complement to that, or just create confusion?

Windows has PWAs in the Windows Store. So the user goes through the install flow, same as any other app, but behind the scenes they're actually downloading a PWA.

https://www.thurrott.com/windows/windows-10/135665/pwas-comi...

But also, consider that people don't seem to really download that many apps. Less than one a month. So I agree with you, in that users may be conditioned to expect a certain workflow, but it's not like it's a deeply ingrained habit that people are doing daily. Also, when you visit a site multiple times, the browser shows a pop-up offering to add the app to your homescreen. So it's low-friction onboarding.

https://techcrunch.com/2017/08/25/majority-of-u-s-consumers-...

Disclaimer: I work on Google Web DevRel

In which cases are native still better than PWA?

In cases similar to desktops with electron vs. native (although with different requirements) where either you need access to significant native features that are not supported in the browser, or if your app is process intensive, i.e. graphics heavy games.

The analogy to Electron makes me wonder if a possible mass migration to PWAs will make the experience on already-slow low-end phones even more atrocious.

it would be the opposite actually, since you don't have to wrap the app in a heavy bundle. avg iOS app size is like 30mb. a web app shouldn't even come close.

Extreme example has been Twitter.

Twitter PWA: 600KB

Native Android Twitter: 23.5MB

https://developers.google.com/web/showcase/2017/twitter#lowe...

This has been a huge differentiator in countries where users are sensitive to data consumption, which is why you see many case studies about countries in India, Africa, etc. getting great traction with PWAs.

Disclaimer: I'm on Google Web DevRel team

Storage space isn't generally the bottleneck on older devices- it's the CPU/RAM. On that count, native apps are usually overwhelmingly preferable.

If these catch on a big way, it'll be catastrophic for more underpowered devices. Modern web pages are already starting to get acutely uncomfortable to use on older iPhones, let alone older Android devices- we aren't yet at the point where performance levels are high enough that we can slap the equivalent of an electron wrapper on everything, smirk at users' devices' vanishing battery life and call it a day.

Apples to oranges. The download size of a native app, while important to keep low, will have minimal effect of the actual user experience post-download. Web applications will in almost all cases be a strictly worse user experience.

If you need to store non-trivial amounts of offline data then native is your only option.

That's not necessarily true, depending on what your definition of "non-trivial" is.

I currently use IndexedDB to store over 500mb of data on phones successfully in a B2B application.

The biggest issue in my experience is access to native "well optimized" APIs. (If I want a video feed, it causes significantly more battery draw to do it in a webview vs a native camera feed).

Is that local data safe from 3rd-party javascript?

I'm not entirely sure what you are asking here.

IndexedDB is subject to the same origin policy, so only javascript executed on my domain can access the data for my domain.

Combined with a good Content-security-policy means I'm in control of exactly what code gets to access those resources.

Some discussion here: https://news.ycombinator.com/item?id=16250519

Ah, so in that case yes, it's safe from the extreme majority of XSS, because I use Content-Security-Policy headers.

Any cookies would also be subject to XSS, unless they have the HTTP-Only flag set, in which case the whole point is not worth discussing because JavaScript cannot access it or even know it exists, so it would obviously be useless to any javascript.

Localstorage (and friends like WebSQL and IndexedDB) and Cookies serve different purposes, and having data in IndexedDB is no less "secure" than having it displayed on the page. In both cases an XSS attack means game over.

Not true, many browsers give decent offline data storage quotas. Although one of the benefits of PWAs is that you often reduce your data footprint on your users devices. The extreme canonical example has been Twitter PWA compared to Twitter native.

See link below for per-browser storage quota: https://developers.google.com/web/ilt/pwa/live-data-in-the-s...

Disclaimer: I work on Google Web DevRel

All of them, in my opinion.

I have not encountered a single case where a web app offered a better experience than a native app.

There is a reasonable argument that it's cheaper to develop, allowing support for more platforms to be rolled out with less development time. That's the single reason that might be valid.

I strongly prefer the Twitter PWA to the Twitter app. It uses only 279 KB storage on my phone. When Firefox 58 finishes rolling out, I'll play around with using web extensions to customize the app, which is something that will likely never be possible with a native app.

Also the case where you have lots if transient users. Far better to have a first-rmtime visitor experience s mobile-friendly webpage that can act as an app than to throw a "download our app" message at them.

For companies with more reliable visitors, Native definitely has an edge in options, but if a company is trying to build feature and experience parity across platforms, much if that edge is dulled.

Other than install method, are there any significant differences in developer experience or capability between PWA's and old school webview apps?

assuming "old school webview app" means something built with cordova (or similar), you no longer have the ability to drop down into Obj-C / Java for extensions/functionality that the web doesn't have or safari doesn't support.

In many cases this doesn't really matter, but could very easily be a complete dealbreaker for someone trying to decide what to build.

Ya pretty much meant cordova. And just for fun lets throw react native into the comparison mix. Now have 5 levels deep of options on the Web App <--> Native scale, all 5 of them still relevant in 2 years?

I've been doing React professionally for 3 years now. I've messed with React Native out of curiosity and to see if it would fit my needs.

React Native remains a hard sell for me. The idea behind it is that knowledge of React is where the learning curve is. Which is a flawed premise. React, itself, is dead simple. But ditching years of CSS and DOM knowledge and learning the React Native component API and quirks regarding iOS and Android? That's a massive hill to climb. Even with JavaScript by your side. I'd rather try Cordova+React if I had to. And if I truly wanted native performance, then it's Obj-C for me. Might as well suck it up and do it right in the first place.

I've found the transition to the native components to be the easiest part. Really feels no different than using components just like you would on the web. Hard part is that the documentation for everything has tons of missing pieces and the error messages suck.

Reply on news.ycombinator.com