28 ms·

Learn PWA

235 points by carride 4y ago

m33k44 4y ago
This is baffling to me, Google is promoting PWA and at the same time promoting Flutter for web development and native mobile development!
- detaro 4y ago
  Companies that size generally don't follow one set of perfectly aligned goals. Both make sense for Google to support, even if they occasionally contradict each other. And that's before you look inside who exactly benefits from which goal.
- fareesh 4y ago
  Think of it this way: If you are a small business / entrepreneur and you have a working product on one platform, you should be able to port to another platform with minimal effort, where you can at least have a MVP without having to recreate your front-end from scratch. - If you already have a website and you want to do an app, PWA is probably a simpler path compared to recreating your front-end in Flutter. - Likewise if you already have a working Flutter mobile app and your users start to ask for a web or desktop version, it's easy to get some sub-optimal version out with less effort if you can re-use a lot of your Flutter code. It also makes it easier to maintain if you structure your code in a way that separates out the logic that's specific to platforms. If you manage to achieve product-market fit and your business benefits from your users being first-class citizens on the web and on the phone, you can start to invest in those development teams.
- pjmlp 4y ago
  You forgot Kotlin/Native with Jetpack Composer. That is what happens when each business unit has their own agenda.
- dmitriid 4y ago
  Nothing baffling if you look at it this way: Within Chrome it's Chrome vs Android (and possibly a few other teams). To quote https://www.quirksmode.org/blog/archives/2021/08/breaking_the_we.html https://www.quirksmode.org/blog/archives/2021/08/breaking_th... --- start quote --- When performing Valley Kremlinology, it is useful to see Google policies as stemming from a conflict between internal pro-web and anti-web factions. We web developers mainly deal with the pro-web faction, the Chrome devrel and browser teams. On the other hand, the Android team is squarely in the anti-web camp. When seen in this light the pro-web camp’s insistence on copying everything appy makes excellent sense: if they didn’t Chrome would lag behind apps and the Android anti-web camp would gain too much power. While I prefer the pro-web over the anti-web camp, I would even more prefer the web not to be a pawn in an internal Google power struggle. But it has come to that, no doubt about it. --- end quote ---
- mhoad 4y ago
  A flutter web app is also a PWA. There’s nothing DOM specific about a PWA.
ainar-g 4y ago
Have we ever found out, why did Mozilla actually remove PWA support from Firefox? Apart from the buzzwordey stuff like “focusing on delivering real value to our users” that the C-levels have been spouting. Between this and their abandonment of Servo, it really seems like they keep shooting themselves in the feet, which, considering their position on the market, just really baffles me.
- easrng 4y ago
  They didn't. They support all the PWA APIs (ServiceWorkers, Manifests, Push, etc.), they just don't support having PWAs open without browser chrome on desktops only. On android they can be added to the homescreen and they open without browser chrome just like Chromium does.
  - politelemon 4y ago
    Your point is correct - they removed it from desktops - but it still doesn't answer the question about the why it was removed.
  - ainar-g 4y ago
    You are technically correct, but removing a feature for a large number of important platforms is still a weird move, especially in the context of PWAs becoming more and more widely used on all platforms.
  - kitsunesoba 4y ago
    It’s still a weird decision, because if I’m going to want a PWA anywhere it’s most likely to be on desktop, not mobile. On mobile OSes there’s usually mobile apps available for a given service, but that’s not the case on desktop, where it’s sometimes useful to eschew browser chrome and defer window management to the OS window manager.
- marcosdumay 4y ago
  I'm guessing they did it for similarity with the chromeless browser windows that created all kinds of security problems at the early 00's for every browser, except Firefox, that gave the control of the chrome appearance to the user instead of the site. Or maybe it's for similarity with the xul applications, that created security problems by the second half of the 00's because they got control of the chrome appearance. As a rule, every time browsers gave control of the chrome to the content, it went badly. It's the kind of problem that can certainly be solved by creating the right set of capabilities, but the Firefox developers decided to focus on some other problem.
duxup 4y ago
I love PWAs, I use them a lot. Some PWAs I prefer over regular apps, Outlook, Teams (although that doesn't mean I like either app generally...). But I feel like the only reason I know about PWAs is because I'm a developer, and I really don't think about providing them to customers / introducing them. Explaining a PWA, how to install it and all... it's not really apparent to end users what is going on / why they have to go through these steps. I feel like PWAs are this wonderful little secret ... but have been for so long I wonder if non technical folks will adopt them.
- intrasight 4y ago
  >through these steps You mean the single step of clicking "yes" when prompted to install.
  - duxup 4y ago
    I find that doesn't happen as consistently as I would expect / folks to notice. It's one thing to ask technical folks to do a thing, another less technical.
    - k__ 4y ago
      I think, one requirement is that the user has to interact at least 30sec with the app, which makes the whole thing feel a bit random. You need to design some intentional onboarding for this to work consistently.
    - intrasight 4y ago
      I do have to remind myself that a tech audience will approach things differently. Including one that I probably wrongly assume is true of everyone - that they will be very selective about what apps they install.
  - BackBlast 4y ago
    It's really two steps, one to initiate the installation and then to approve it ("yes"). You can wrap the initiation any way you like. I prefer to make it resemble an app store people are familiar with. Screen shots, user feedback, a description with a "download" button. This communicates the intention pretty well even though it adds an extra step to the process. I find the biggest hurdle is that people don't realize they can install an "app" so easily and so I try to bridge the knowledge gap.
politelemon 4y ago
Angular 14 made it dead easy to add PWA support to the application, the bulk of it just comes down to some JSON configuration. And good timing too. https://angular.io/guide/service-worker-intro https://angular.io/guide/service-worker-intro
pjmlp 4y ago
If you want to check how well PWAs are supported on your devices, https://whatwebcando.today https://whatwebcando.today
milkers 4y ago
Most of the apps on my phone could've been a simple PWA. We need better design and UX for improving communication to the end users in order to make PWA's more discoverable.
samwillis 4y ago
I think PWA and "packaged" versions in app stores are absolutely the right route for a significant majority of apps. Obviously anything "game like", apps that needs extensive native features or is incredibly performance critical would be better as a native app. However so many apps are just a version of the web experience anyway, whether it's a content consumption app, something like an online sore, or a business/enterprise data app. The old thoughts about the performance of PWAs and apps built with PhoneGap/Cordova are complexity superseded now. The performance of webkit/blink on mobile devices is so impressive a well made app will be indistinguishable from a native mobile app. If you are looking at packaging a PWA for app stores take a look at PWABuilder (https://www.pwabuilder.com https://www.pwabuilder.com) and Capacitor (https://capacitorjs.com https://capacitorjs.com). I particularly like Capacitor as it is so extendable, you can easily have extra functionality using native features for your packaged app. Combine Capacitor with NativeScript (https://capacitor.nativescript.org/introduction.html https://capacitor.nativescript.org/introduction.html) and you have one codebase in one language (JS or TypeScript) that covers all your font end, on all platforms, including all native apis. Packaging a PWA for app stores is also the best way to make them discoverable right now - he majority of users will default to looking there. On top of that, with WASM you can increasingly use things such as SQLite (https://sql.js.org/ https://sql.js.org/) as you local datastore for PWAs and then, with Capacitor, use native SQLite for the packaged version, unifying your entire front end.
- ravenstine 4y ago
  The problem with PWAs is they will never gain parity with the functionality of native development, even with WASM. Unless something changes both with mobile operating systems and their respective app stores, PWAs are a failure. I do agree, however, that PWAs have adequate performance. Even back 9 years ago, performance on mobile could be acceptable, but you just couldn't overload the frontend with countless UI modules.
  - __ryan__ 4y ago
    The problem with PWAs is they will never gain parity with the functionality of native development. Never? Why not?
tonerow 4y ago
I'm guessing push notifications coming to iOS next year[1] will make PWA's even more popular as a development strategy [1] https://www.izooto.com/blog/ios-safari-push-notifications#:~:text=Apple%20announced%20support%20for%20web,feature%20was%20coming%20to%20iOS https://www.izooto.com/blog/ios-safari-push-notifications#:~....
jiggywiggy 4y ago
We've been talking for over 8 years about it in the web developer community. But it's a pipe dream. We haven't been able to convince the consumer that a website and app are not so different. I've been setting up Saas tool for fitness apps and its such a pain to deal with the app stores, the reviews, updates, commissions and lack of control. It would be great if Google could direct their marketing budget to the consumers, not the devs :)
- samwillis 4y ago
  > We haven't been able to convince the consumer that a website and app are not so different. So don't! just build a PWA as your web front-end and package it as an app for the stores to distribute it (see PWABuilder - https://www.pwabuilder.com https://www.pwabuilder.com or Capacitor - https://capacitorjs.com https://capacitorjs.com). You get the best of both worlds, unified simple development and the App Store distribution model.
  - WA 4y ago
    Capacitor doesn’t free you from things OP mentioned: App Store updated, marketing material like screenshots, descriptions, App reviews by Apple, ratings, etc.
- tkahnoski 4y ago
  Couldn't agree more.... I can imagine the Apple keynote version of this. "Cross-platform apps have never been easier. All the features customers love from native now on the web... We call it iApps."
  - hulitu 4y ago
    > All the features customers love from native now on the web They tried. They dumbed down native programs to look more and more like web apps. The only success was Teams. /s
  - osrec 4y ago
    And all Apple users will claim it to be the best thing since sliced bread: "it's amazing - you don't need to install anything - just go on the website and the app is ready to go, while being perfectly sandboxed within the confines of your browser".
newhouseb 4y ago
What is the state of the art here in terms of reliable data persistence? Last I was seriously looking at the PWA route, I understood that they were best suited for apps with always-online access because anything stored locally could be more or less jettisoned as soon as the device felt disk pressure. Is that still the case or did I dream that up?
- BackBlast 4y ago
  It's generally still the case. I have two workarounds. Allow replication from the cloud in the event that it is cleared out. And provide a mechanism for the user to manually backup and restore.
- ies7 4y ago
  It's in controlled android devices but 10% of our sales force application operate almost offline. In the morning, it syncs pouchdb with couchdb server, cache all the pages then goes to offline first mode. Anytime they get internet signal, the serviceworker would send the data to postgresql. Pouchdb takes care of sync and all the multi browser storage problem.
  - samwillis 4y ago
    I love PouchDB, it's incredible, however I fear its a project that is loosing it momentum (I do think it has pick up a little over the last year though). It has a very aggressive stale bot closing issues (this search shows 700 closed stale issues https://github.com/pouchdb/pouchdb/issues?q=is%3Aissue+stale+is%3Aclosed https://github.com/pouchdb/pouchdb/issues?q=is%3Aissue+stale...), some which I really don't think it should have. It gives the impression of a very active but stable platform that I don't necessarily think is accurate. For example I found a version hash collision bug while working on a side project, the issue was closed as stale (https://github.com/pouchdb/pouchdb/issues/8257 https://github.com/pouchdb/pouchdb/issues/8257)
    - lytefm 4y ago
      I agree with the stale bot issue and with PouchDB maintenance activity being lower than it should. But the core features (store JSONs locally, sync them up with CouchDB) have been stable and reliable for many, many years and just work.
pier25 4y ago
Does Google finally allow to add a PWA to the Play Store? Just the domain, without having to package an Android app. Microsoft added that to their store years ago.
yanis_t 4y ago
stuckinhell 4y ago
Lol, Web Development is such a big big place. Just this morning, I was asked to rip out some popular javascript frameworks and advanced browser concepts like indexdb and PWA from our enterprise tech stack.
T3RMINATED 4y ago
fareesh 4y ago
The PWA space seems to be in a state where you still have to write a lot of boilerplate. Are there any good frameworks / syntactic sugar / wrappers that make life easier for folks who would like to have smart opinionated defaults that work for most common use-cases?
- pjmlp 4y ago
  Yes, something like https://www.pwabuilder.com/ https://www.pwabuilder.com/ https://developer.chrome.com/docs/workbox/ https://developer.chrome.com/docs/workbox/
  - fareesh 4y ago
    Thanks - more of the workbox direction is what I was looking for. I'll check it out
- valcron1000 4y ago
  Angular has great support for PWAs
  - fareesh 4y ago
    Last I used angular (around v4) you had to buy-in to everything and the hello world size was an enormous JS payload. This is partly why I stopped recommending it for anything other than interactive applications with a small userbase. It would be nice if you could bring your own site and add PWA support through a third party library.
  - depressedpanda 4y ago
    How is it compared to CRA and Vue CLI? I've done PWAs in both of those and it worked straight out of the box.
- kbst 4y ago
  https://pwabuilder.com https://pwabuilder.com https://workbox.com https://workbox.com https://progressier.com https://progressier.com https://superpwa.com https://superpwa.com
whartung 4y ago
I can't speak to mobile, I really don't know much about mobile development. But when it comes to the desktop, what's the motivation for a PWA over something like Electron? I appreciate the app size would be much smaller, but then you're back to fighting browser and platform compatibility issues (such as those browsers that have weak support for PWAs). Seems that inevitably you'll be doing "Yes, its a PWA, but it only works/only been tested on Chrome". Well, may as well go full Electron and lock that choice in, right? Or am I overblowing it?
- chromakode 4y ago
  Pros: - Low friction install process. Prompt user and you're done. - No extra distribution channel (same build as web, auto updates baked in) - Permissions sandboxed by browser. Cons: - Compat (though for some simple apps using mature APIs this is not a big issue) - Limited to browser features and performance. Can't integrate deeply with OS.
  - BackBlast 4y ago
    Additional Pros: - PWAs have much lower download requirements, whatever your SPA page weight is pretty much the download size. 1-3MB is pretty common. - PWAs will use lower memory overhead as you don't need a new copy of the browser - it shares with the likely default system browser. - Launch time can be very snappy even on lower end systems if the base browser is already loaded and you manage offline assets well. - Don't need to build for Windows, Linux, MacOS. One build serves Web, Windows, MacOs, and Linux users. Additional cons: - No guarantee of local storage remaining unmolested by the browser. In practice, it's fine unless a user's disk is filling up then you can get purged. - Most obvious OS integration limitation is the inability to control the menus on MacOS. You get a generic set that comes with the PWA.
    - depressedpanda 4y ago
      > - Don't need to build for Windows, Linux, MacOS. One build serves Web, Windows, MacOs, and Linux users. Don't forget that they also get Android and iOS, unlike an Electron app.
dmitriid 4y ago
Just imagine if instead of sinking hundreds of millions of dollars into poorly specced APIs with horrible usability like service workers[1] browser devs would instead implement something that apps actually need: proper UI controls and components. I keep saying: there's a reason all the CSS and UI frameworks on the web re-implement the same paltry dozen of the most primitive components and rarely if ever tackle anything complex. https://open-ui.org https://open-ui.org is too little too late. [1] To quote Dan Abramov, https://dev.to/ben/why-the-react-community-is-missing-the-point-about-web-components-1ic3 https://dev.to/ben/why-the-react-community-is-missing-the-po... --- start quote --- React users would love to not have to npm install a date picker and bloat their bundles! If they need to "use the platform" then why doesn't that platform ship the features they actually ask for? Instead of a carousel they get an aside. Features like service workers are touted as a solution to many problems in the web, but their ergonomics are so under-designed that people actually have to change domains to bust the cache from a broken build (I’m not making this up). --- end quote ---
ptrwis 4y ago
I don't understand why Google doesn't allow SPAs to be placed on Google Play, it would really be a game changer
- elforce002 4y ago
  Simple: Money.
  - ptrwis 4y ago
    I can't see where the money is. Tooling is available for free, you have to pay for the development account anyway.
cowmix 4y ago
I have not been following PWAs that closely but I do recall when Zoom starting using them for ChromeOS last year -- horrible stuff.
allan_s 4y ago
I think learning PWA is not worth the extra-work just create a web app (SPA or plain old multi-page app) and embed it in a react-native-webview. (or any equivalent) You will just need a thin layer of react-native-code to handle push notification/a nice splash screen/deeplinking and for 99% of your user it will be the same We've been doing that at Rosaly.com for now 2 years, and we've never have any issue from Apple/Google reviews and our "think layer" is now ~200 LOC of react native around a multi-page old website (plain html and link to other page, with a "app" design, no react/angular) and it's totally transparent for our users, while allowing us to deploy 10 times a day.
- beebeepka 4y ago
  What about non-react apps? Just use React?
  - BackBlast 4y ago
    The key is "webview", so ignore the "react-native" part and insert "capacitor" or "ionic". React-native doesn't let you easily reuse your webstack to build it. It's not a web view but a way to create a javascript controlled runtime for a native interface. In my experience it's a rewrite and every effort to share components between react-native and react-web hasn't panned out well.
  - allan_s 4y ago
    My "app" inside the webview is html+css and 2 lines of js here and there, so if that works, anything you like will work
- BackBlast 4y ago
  It's hardly any work at all. If you've made a webview you have icons and splash screens, you have what you need to make the manifest.json. You can create the simplest of service workers and your done. If you want better offline ability, you need more TLC in the service worker - which you would need anyway if you want your webview to work offline as well. The "extra work" takes a few hours. The boons of the PWA over the webview, updates are much much easier to roll out. You don't have a bunch of ancient versions running around. If you don't need access to native APIs this might be worth pushing users to use it.
coconut_t1 4y ago
Very cool stuff
itake 4y ago
One problem I face is native apps are too large for phones in developing countries that have limited storage and network capabilities. Most people can get WhatsApp on their phone, and that's it. Would a PWA make apps more accessible to low-end devices and networks?
- depressedpanda 4y ago
  Probably? It depends on what your app forces them to download. A PWA is basically a web app that can be 'installed' (cached) so it can run without a network connection.
  - itake 4y ago
    Yeah, I get that, but webapps aren't always small :-/. I guess having the transpiler on-device saves some costs. I guess this just depends on the application.
    - depressedpanda 4y ago
      Define small? I've rarely seen SPAs larger than ~5 MB. Most of my phone's apps take dozens if not hundreds of MBs for some inexplicable reason.
      - itake 4y ago
        The goal is to service people with limited space. We currently have a WhatsApp chatbot to reach these users, but it's not a great experience. Not only is storage a constraint, sending text is free on WhatsApp[0]. Even if an SPA was small, they still have to pay for data. [0] - https://prepaid-data-sim-card.fandom.com/wiki/Indonesia https://prepaid-data-sim-card.fandom.com/wiki/Indonesia
account-5 4y ago
I always search these threads for references to dart/flutter. I'm a beginner in this area. I'm going to be creating a simple app soon. I would like it to run on desktop and mobile, not the web, and don't want to have to create 2-3 different versions. I'm looking at dart/flutter. I'm not adverse to PWA but due to limited integration with the underlying OS I have kind of ruled out the web because I don't want to run a website for this. Dart/flutter hardly ever gets mentioned on HN and when it does its generally not well received. So my question is what's the issues? My probably naive view is dart/flutter is the way to go.
- butz 4y ago
  I was considering using Flutter for a simple Android app, but app size is just unreasonably huge, as it includes Dart runtime. Funny enough, the hybrid web app approach, e.g. using CapacitorJS to package web app to apk weighs a lot less, in some cases it might be even smaller than native app (considering it is using androidx dependencies). Another problem was, that I have to learn whole new language - Dart, which is not used anywhere else. YMMW, my own experiences should not stop you from trying out a new framework, maybe it will just work for you just fine.
  - account-5 4y ago
    One of my issues, as a beginner, with attempting to create a cross platform app with web technologies is: what to go for? Where do you start? Cordova, React native, Etc. Which ones are best? Dart/flutter seem to offer everything. Though I have heard there are size issues with the resultant program.
  - emptysongglass 4y ago
    There's Flet for Flutter apps written in Python: https://flet.dev https://flet.dev
- BackBlast 4y ago
  Google isn't known to be a good long term supplier of dev tools. Risks for adopting Flutter are fairly large. I've heard reports from some experienced devs that it has a "primary" vs "secondary" platform effect, and is simply less mature and involves more obstacles than an HTML5/CSS/JS based app.
butz 4y ago
Imagine the future, where you could replace all stock Android apps with PWA alternatives.
- vivab0rg 4y ago
  FirefoxOS tried but failed miserably. Mozilla is so dead to me.
anononaut 4y ago
If pushing updates to native apps was as simple and painless as pushing updates to a website/webapp, would you stick with native?
deleted 4y ago
[deleted]
exabrial 4y ago
They forgot the first step, which is you probably don't need or want a PWA, and neither do your users.
unnouinceput 4y ago
Quote: "Caution On desktop, Safari and Firefox do not support PWA installation. They do support offline capabilities, but the experience will always start within the browser user interface. It may get fullscreen, but never a standalone window on desktop." Oh yeah! That's a good feature of Firefox. I would hate your crappy web site to go full screen without me choosing that.

235 points by carride 4y ago

This is baffling to me, Google is promoting PWA and at the same time promoting Flutter for web development and native mobile development!

detaro 4y ago
Companies that size generally don't follow one set of perfectly aligned goals. Both make sense for Google to support, even if they occasionally contradict each other. And that's before you look inside who exactly benefits from which goal.
fareesh 4y ago
Think of it this way: If you are a small business / entrepreneur and you have a working product on one platform, you should be able to port to another platform with minimal effort, where you can at least have a MVP without having to recreate your front-end from scratch. - If you already have a website and you want to do an app, PWA is probably a simpler path compared to recreating your front-end in Flutter. - Likewise if you already have a working Flutter mobile app and your users start to ask for a web or desktop version, it's easy to get some sub-optimal version out with less effort if you can re-use a lot of your Flutter code. It also makes it easier to maintain if you structure your code in a way that separates out the logic that's specific to platforms. If you manage to achieve product-market fit and your business benefits from your users being first-class citizens on the web and on the phone, you can start to invest in those development teams.
pjmlp 4y ago
You forgot Kotlin/Native with Jetpack Composer. That is what happens when each business unit has their own agenda.
dmitriid 4y ago
Nothing baffling if you look at it this way: Within Chrome it's Chrome vs Android (and possibly a few other teams). To quote https://www.quirksmode.org/blog/archives/2021/08/breaking_the_we.html https://www.quirksmode.org/blog/archives/2021/08/breaking_th... --- start quote --- When performing Valley Kremlinology, it is useful to see Google policies as stemming from a conflict between internal pro-web and anti-web factions. We web developers mainly deal with the pro-web faction, the Chrome devrel and browser teams. On the other hand, the Android team is squarely in the anti-web camp. When seen in this light the pro-web camp’s insistence on copying everything appy makes excellent sense: if they didn’t Chrome would lag behind apps and the Android anti-web camp would gain too much power. While I prefer the pro-web over the anti-web camp, I would even more prefer the web not to be a pawn in an internal Google power struggle. But it has come to that, no doubt about it. --- end quote ---
mhoad 4y ago
A flutter web app is also a PWA. There’s nothing DOM specific about a PWA.

ainar-g 4y ago

Have we ever found out, why did Mozilla actually remove PWA support from Firefox? Apart from the buzzwordey stuff like “focusing on delivering real value to our users” that the C-levels have been spouting. Between this and their abandonment of Servo, it really seems like they keep shooting themselves in the feet, which, considering their position on the market, just really baffles me.

easrng 4y ago
They didn't. They support all the PWA APIs (ServiceWorkers, Manifests, Push, etc.), they just don't support having PWAs open without browser chrome on desktops only. On android they can be added to the homescreen and they open without browser chrome just like Chromium does.
- politelemon 4y ago
  Your point is correct - they removed it from desktops - but it still doesn't answer the question about the why it was removed.
- ainar-g 4y ago
  You are technically correct, but removing a feature for a large number of important platforms is still a weird move, especially in the context of PWAs becoming more and more widely used on all platforms.
- kitsunesoba 4y ago
  It’s still a weird decision, because if I’m going to want a PWA anywhere it’s most likely to be on desktop, not mobile. On mobile OSes there’s usually mobile apps available for a given service, but that’s not the case on desktop, where it’s sometimes useful to eschew browser chrome and defer window management to the OS window manager.
marcosdumay 4y ago
I'm guessing they did it for similarity with the chromeless browser windows that created all kinds of security problems at the early 00's for every browser, except Firefox, that gave the control of the chrome appearance to the user instead of the site. Or maybe it's for similarity with the xul applications, that created security problems by the second half of the 00's because they got control of the chrome appearance. As a rule, every time browsers gave control of the chrome to the content, it went badly. It's the kind of problem that can certainly be solved by creating the right set of capabilities, but the Firefox developers decided to focus on some other problem.

duxup 4y ago

I love PWAs, I use them a lot. Some PWAs I prefer over regular apps, Outlook, Teams (although that doesn't mean I like either app generally...). But I feel like the only reason I know about PWAs is because I'm a developer, and I really don't think about providing them to customers / introducing them. Explaining a PWA, how to install it and all... it's not really apparent to end users what is going on / why they have to go through these steps. I feel like PWAs are this wonderful little secret ... but have been for so long I wonder if non technical folks will adopt them.

intrasight 4y ago
>through these steps You mean the single step of clicking "yes" when prompted to install.
- duxup 4y ago
  I find that doesn't happen as consistently as I would expect / folks to notice. It's one thing to ask technical folks to do a thing, another less technical.
  - k__ 4y ago
    I think, one requirement is that the user has to interact at least 30sec with the app, which makes the whole thing feel a bit random. You need to design some intentional onboarding for this to work consistently.
  - intrasight 4y ago
    I do have to remind myself that a tech audience will approach things differently. Including one that I probably wrongly assume is true of everyone - that they will be very selective about what apps they install.
- BackBlast 4y ago
  It's really two steps, one to initiate the installation and then to approve it ("yes"). You can wrap the initiation any way you like. I prefer to make it resemble an app store people are familiar with. Screen shots, user feedback, a description with a "download" button. This communicates the intention pretty well even though it adds an extra step to the process. I find the biggest hurdle is that people don't realize they can install an "app" so easily and so I try to bridge the knowledge gap.

politelemon 4y ago

Angular 14 made it dead easy to add PWA support to the application, the bulk of it just comes down to some JSON configuration. And good timing too. https://angular.io/guide/service-worker-intro https://angular.io/guide/service-worker-intro

pjmlp 4y ago

If you want to check how well PWAs are supported on your devices, https://whatwebcando.today https://whatwebcando.today

milkers 4y ago

Most of the apps on my phone could've been a simple PWA. We need better design and UX for improving communication to the end users in order to make PWA's more discoverable.

samwillis 4y ago

I think PWA and "packaged" versions in app stores are absolutely the right route for a significant majority of apps. Obviously anything "game like", apps that needs extensive native features or is incredibly performance critical would be better as a native app. However so many apps are just a version of the web experience anyway, whether it's a content consumption app, something like an online sore, or a business/enterprise data app. The old thoughts about the performance of PWAs and apps built with PhoneGap/Cordova are complexity superseded now. The performance of webkit/blink on mobile devices is so impressive a well made app will be indistinguishable from a native mobile app. If you are looking at packaging a PWA for app stores take a look at PWABuilder (https://www.pwabuilder.com https://www.pwabuilder.com) and Capacitor (https://capacitorjs.com https://capacitorjs.com). I particularly like Capacitor as it is so extendable, you can easily have extra functionality using native features for your packaged app. Combine Capacitor with NativeScript (https://capacitor.nativescript.org/introduction.html https://capacitor.nativescript.org/introduction.html) and you have one codebase in one language (JS or TypeScript) that covers all your font end, on all platforms, including all native apis. Packaging a PWA for app stores is also the best way to make them discoverable right now - he majority of users will default to looking there. On top of that, with WASM you can increasingly use things such as SQLite (https://sql.js.org/ https://sql.js.org/) as you local datastore for PWAs and then, with Capacitor, use native SQLite for the packaged version, unifying your entire front end.

ravenstine 4y ago
The problem with PWAs is they will never gain parity with the functionality of native development, even with WASM. Unless something changes both with mobile operating systems and their respective app stores, PWAs are a failure. I do agree, however, that PWAs have adequate performance. Even back 9 years ago, performance on mobile could be acceptable, but you just couldn't overload the frontend with countless UI modules.
- __ryan__ 4y ago
  The problem with PWAs is they will never gain parity with the functionality of native development. Never? Why not?

tonerow 4y ago

I'm guessing push notifications coming to iOS next year[1] will make PWA's even more popular as a development strategy [1] https://www.izooto.com/blog/ios-safari-push-notifications#:~:text=Apple%20announced%20support%20for%20web,feature%20was%20coming%20to%20iOS https://www.izooto.com/blog/ios-safari-push-notifications#:~....

jiggywiggy 4y ago

We've been talking for over 8 years about it in the web developer community. But it's a pipe dream. We haven't been able to convince the consumer that a website and app are not so different. I've been setting up Saas tool for fitness apps and its such a pain to deal with the app stores, the reviews, updates, commissions and lack of control. It would be great if Google could direct their marketing budget to the consumers, not the devs :)

samwillis 4y ago
> We haven't been able to convince the consumer that a website and app are not so different. So don't! just build a PWA as your web front-end and package it as an app for the stores to distribute it (see PWABuilder - https://www.pwabuilder.com https://www.pwabuilder.com or Capacitor - https://capacitorjs.com https://capacitorjs.com). You get the best of both worlds, unified simple development and the App Store distribution model.
- WA 4y ago
  Capacitor doesn’t free you from things OP mentioned: App Store updated, marketing material like screenshots, descriptions, App reviews by Apple, ratings, etc.
tkahnoski 4y ago
Couldn't agree more.... I can imagine the Apple keynote version of this. "Cross-platform apps have never been easier. All the features customers love from native now on the web... We call it iApps."
- hulitu 4y ago
  > All the features customers love from native now on the web They tried. They dumbed down native programs to look more and more like web apps. The only success was Teams. /s
- osrec 4y ago
  And all Apple users will claim it to be the best thing since sliced bread: "it's amazing - you don't need to install anything - just go on the website and the app is ready to go, while being perfectly sandboxed within the confines of your browser".

newhouseb 4y ago

What is the state of the art here in terms of reliable data persistence? Last I was seriously looking at the PWA route, I understood that they were best suited for apps with always-online access because anything stored locally could be more or less jettisoned as soon as the device felt disk pressure. Is that still the case or did I dream that up?

BackBlast 4y ago
It's generally still the case. I have two workarounds. Allow replication from the cloud in the event that it is cleared out. And provide a mechanism for the user to manually backup and restore.
ies7 4y ago
It's in controlled android devices but 10% of our sales force application operate almost offline. In the morning, it syncs pouchdb with couchdb server, cache all the pages then goes to offline first mode. Anytime they get internet signal, the serviceworker would send the data to postgresql. Pouchdb takes care of sync and all the multi browser storage problem.
- samwillis 4y ago
  I love PouchDB, it's incredible, however I fear its a project that is loosing it momentum (I do think it has pick up a little over the last year though). It has a very aggressive stale bot closing issues (this search shows 700 closed stale issues https://github.com/pouchdb/pouchdb/issues?q=is%3Aissue+stale+is%3Aclosed https://github.com/pouchdb/pouchdb/issues?q=is%3Aissue+stale...), some which I really don't think it should have. It gives the impression of a very active but stable platform that I don't necessarily think is accurate. For example I found a version hash collision bug while working on a side project, the issue was closed as stale (https://github.com/pouchdb/pouchdb/issues/8257 https://github.com/pouchdb/pouchdb/issues/8257)
  - lytefm 4y ago
    I agree with the stale bot issue and with PouchDB maintenance activity being lower than it should. But the core features (store JSONs locally, sync them up with CouchDB) have been stable and reliable for many, many years and just work.

pier25 4y ago

Does Google finally allow to add a PWA to the Play Store? Just the domain, without having to package an Android app. Microsoft added that to their store years ago.

yanis_t 4y ago

stuckinhell 4y ago

Lol, Web Development is such a big big place. Just this morning, I was asked to rip out some popular javascript frameworks and advanced browser concepts like indexdb and PWA from our enterprise tech stack.

T3RMINATED 4y ago

fareesh 4y ago

The PWA space seems to be in a state where you still have to write a lot of boilerplate. Are there any good frameworks / syntactic sugar / wrappers that make life easier for folks who would like to have smart opinionated defaults that work for most common use-cases?

pjmlp 4y ago
Yes, something like https://www.pwabuilder.com/ https://www.pwabuilder.com/ https://developer.chrome.com/docs/workbox/ https://developer.chrome.com/docs/workbox/
- fareesh 4y ago
  Thanks - more of the workbox direction is what I was looking for. I'll check it out
valcron1000 4y ago
Angular has great support for PWAs
- fareesh 4y ago
  Last I used angular (around v4) you had to buy-in to everything and the hello world size was an enormous JS payload. This is partly why I stopped recommending it for anything other than interactive applications with a small userbase. It would be nice if you could bring your own site and add PWA support through a third party library.
- depressedpanda 4y ago
  How is it compared to CRA and Vue CLI? I've done PWAs in both of those and it worked straight out of the box.
kbst 4y ago
https://pwabuilder.com https://pwabuilder.com https://workbox.com https://workbox.com https://progressier.com https://progressier.com https://superpwa.com https://superpwa.com

whartung 4y ago

I can't speak to mobile, I really don't know much about mobile development. But when it comes to the desktop, what's the motivation for a PWA over something like Electron? I appreciate the app size would be much smaller, but then you're back to fighting browser and platform compatibility issues (such as those browsers that have weak support for PWAs). Seems that inevitably you'll be doing "Yes, its a PWA, but it only works/only been tested on Chrome". Well, may as well go full Electron and lock that choice in, right? Or am I overblowing it?

chromakode 4y ago
Pros: - Low friction install process. Prompt user and you're done. - No extra distribution channel (same build as web, auto updates baked in) - Permissions sandboxed by browser. Cons: - Compat (though for some simple apps using mature APIs this is not a big issue) - Limited to browser features and performance. Can't integrate deeply with OS.
- BackBlast 4y ago
  Additional Pros: - PWAs have much lower download requirements, whatever your SPA page weight is pretty much the download size. 1-3MB is pretty common. - PWAs will use lower memory overhead as you don't need a new copy of the browser - it shares with the likely default system browser. - Launch time can be very snappy even on lower end systems if the base browser is already loaded and you manage offline assets well. - Don't need to build for Windows, Linux, MacOS. One build serves Web, Windows, MacOs, and Linux users. Additional cons: - No guarantee of local storage remaining unmolested by the browser. In practice, it's fine unless a user's disk is filling up then you can get purged. - Most obvious OS integration limitation is the inability to control the menus on MacOS. You get a generic set that comes with the PWA.
  - depressedpanda 4y ago
    > - Don't need to build for Windows, Linux, MacOS. One build serves Web, Windows, MacOs, and Linux users. Don't forget that they also get Android and iOS, unlike an Electron app.

dmitriid 4y ago

Just imagine if instead of sinking hundreds of millions of dollars into poorly specced APIs with horrible usability like service workers[1] browser devs would instead implement something that apps actually need: proper UI controls and components. I keep saying: there's a reason all the CSS and UI frameworks on the web re-implement the same paltry dozen of the most primitive components and rarely if ever tackle anything complex. https://open-ui.org https://open-ui.org is too little too late. [1] To quote Dan Abramov, https://dev.to/ben/why-the-react-community-is-missing-the-point-about-web-components-1ic3 https://dev.to/ben/why-the-react-community-is-missing-the-po... --- start quote --- React users would love to not have to npm install a date picker and bloat their bundles! If they need to "use the platform" then why doesn't that platform ship the features they actually ask for? Instead of a carousel they get an aside. Features like service workers are touted as a solution to many problems in the web, but their ergonomics are so under-designed that people actually have to change domains to bust the cache from a broken build (I’m not making this up). --- end quote ---

ptrwis 4y ago

I don't understand why Google doesn't allow SPAs to be placed on Google Play, it would really be a game changer

elforce002 4y ago
Simple: Money.
- ptrwis 4y ago
  I can't see where the money is. Tooling is available for free, you have to pay for the development account anyway.

cowmix 4y ago

I have not been following PWAs that closely but I do recall when Zoom starting using them for ChromeOS last year -- horrible stuff.

allan_s 4y ago

I think learning PWA is not worth the extra-work just create a web app (SPA or plain old multi-page app) and embed it in a react-native-webview. (or any equivalent) You will just need a thin layer of react-native-code to handle push notification/a nice splash screen/deeplinking and for 99% of your user it will be the same We've been doing that at Rosaly.com for now 2 years, and we've never have any issue from Apple/Google reviews and our "think layer" is now ~200 LOC of react native around a multi-page old website (plain html and link to other page, with a "app" design, no react/angular) and it's totally transparent for our users, while allowing us to deploy 10 times a day.

beebeepka 4y ago
What about non-react apps? Just use React?
- BackBlast 4y ago
  The key is "webview", so ignore the "react-native" part and insert "capacitor" or "ionic". React-native doesn't let you easily reuse your webstack to build it. It's not a web view but a way to create a javascript controlled runtime for a native interface. In my experience it's a rewrite and every effort to share components between react-native and react-web hasn't panned out well.
- allan_s 4y ago
  My "app" inside the webview is html+css and 2 lines of js here and there, so if that works, anything you like will work
BackBlast 4y ago
It's hardly any work at all. If you've made a webview you have icons and splash screens, you have what you need to make the manifest.json. You can create the simplest of service workers and your done. If you want better offline ability, you need more TLC in the service worker - which you would need anyway if you want your webview to work offline as well. The "extra work" takes a few hours. The boons of the PWA over the webview, updates are much much easier to roll out. You don't have a bunch of ancient versions running around. If you don't need access to native APIs this might be worth pushing users to use it.

coconut_t1 4y ago

Very cool stuff

itake 4y ago

One problem I face is native apps are too large for phones in developing countries that have limited storage and network capabilities. Most people can get WhatsApp on their phone, and that's it. Would a PWA make apps more accessible to low-end devices and networks?

depressedpanda 4y ago
Probably? It depends on what your app forces them to download. A PWA is basically a web app that can be 'installed' (cached) so it can run without a network connection.
- itake 4y ago
  Yeah, I get that, but webapps aren't always small :-/. I guess having the transpiler on-device saves some costs. I guess this just depends on the application.
  - depressedpanda 4y ago
    Define small? I've rarely seen SPAs larger than ~5 MB. Most of my phone's apps take dozens if not hundreds of MBs for some inexplicable reason.
    - itake 4y ago
      The goal is to service people with limited space. We currently have a WhatsApp chatbot to reach these users, but it's not a great experience. Not only is storage a constraint, sending text is free on WhatsApp[0]. Even if an SPA was small, they still have to pay for data. [0] - https://prepaid-data-sim-card.fandom.com/wiki/Indonesia https://prepaid-data-sim-card.fandom.com/wiki/Indonesia

account-5 4y ago

I always search these threads for references to dart/flutter. I'm a beginner in this area. I'm going to be creating a simple app soon. I would like it to run on desktop and mobile, not the web, and don't want to have to create 2-3 different versions. I'm looking at dart/flutter. I'm not adverse to PWA but due to limited integration with the underlying OS I have kind of ruled out the web because I don't want to run a website for this. Dart/flutter hardly ever gets mentioned on HN and when it does its generally not well received. So my question is what's the issues? My probably naive view is dart/flutter is the way to go.

butz 4y ago
I was considering using Flutter for a simple Android app, but app size is just unreasonably huge, as it includes Dart runtime. Funny enough, the hybrid web app approach, e.g. using CapacitorJS to package web app to apk weighs a lot less, in some cases it might be even smaller than native app (considering it is using androidx dependencies). Another problem was, that I have to learn whole new language - Dart, which is not used anywhere else. YMMW, my own experiences should not stop you from trying out a new framework, maybe it will just work for you just fine.
- account-5 4y ago
  One of my issues, as a beginner, with attempting to create a cross platform app with web technologies is: what to go for? Where do you start? Cordova, React native, Etc. Which ones are best? Dart/flutter seem to offer everything. Though I have heard there are size issues with the resultant program.
- emptysongglass 4y ago
  There's Flet for Flutter apps written in Python: https://flet.dev https://flet.dev
BackBlast 4y ago
Google isn't known to be a good long term supplier of dev tools. Risks for adopting Flutter are fairly large. I've heard reports from some experienced devs that it has a "primary" vs "secondary" platform effect, and is simply less mature and involves more obstacles than an HTML5/CSS/JS based app.

butz 4y ago

Imagine the future, where you could replace all stock Android apps with PWA alternatives.

vivab0rg 4y ago
FirefoxOS tried but failed miserably. Mozilla is so dead to me.

anononaut 4y ago

If pushing updates to native apps was as simple and painless as pushing updates to a website/webapp, would you stick with native?

deleted 4y ago

[deleted]

exabrial 4y ago

They forgot the first step, which is you probably don't need or want a PWA, and neither do your users.

unnouinceput 4y ago

Quote: "Caution On desktop, Safari and Firefox do not support PWA installation. They do support offline capabilities, but the experience will always start within the browser user interface. It may get fullscreen, but never a standalone window on desktop." Oh yeah! That's a good feature of Firefox. I would hate your crappy web site to go full screen without me choosing that.