• DWin@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    13
    arrow-down
    18
    ·
    edit-2
    1 year ago

    There is valid performance based reasons to use an app over a browser based experience. Sure perhaps it’s just data collection, but being able to cache locally and have that information persistent between uses dramatically drops the initial page load time.

    But yeah, it’s annoying as hell to be bothered about it, and usually compromising the performance/load time is worth not having to go through the hassle of downloading an app.

    Edit: Seems like I was wrong. I remember reading about how in general native apps would make significantly fewer API calls than identical website based experiences, even with the user having navigated to the site before.

    • Jamie@jamie.moe
      link
      fedilink
      English
      arrow-up
      20
      ·
      1 year ago

      but being able to cache locally and have that information persistent between uses dramatically drops the initial page load time.

      This is already 100% possible through standard web methods. Heck, the web browsers often do resource caching for you.

      • TheSaneWriter@lemmy.thesanewriter.com
        link
        fedilink
        English
        arrow-up
        5
        ·
        1 year ago

        Indeed. Cookies for small data and web storage for larger data have made it completely feasible to cache data on a web browser, then combined that with web browser caching and I’m sure it can’t be that much better than the apps.

    • ⚡⚡⚡@feddit.deOP
      link
      fedilink
      arrow-up
      15
      ·
      1 year ago

      (The downvote is not from me BTW)

      I think, the main reasons to make you use the app are:

      • push notifications (they can’t do that in a web browser when the website is closed, but on your phone when the app is closed)
      • data mining (the web browser is a more restrictive sandbox than the OS of your phone)
      • background activities (even when apps are not open, they can run in the background and communicate with their servers, classic websites can’t do that)
        • ⚡⚡⚡@feddit.deOP
          link
          fedilink
          arrow-up
          3
          ·
          1 year ago

          The Push API gives web applications the ability to receive messages pushed to them from a server, whether or not the web app is in the foreground, or even currently loaded, on a user agent. This lets developers deliver asynchronous notifications and updates to users that opt in, resulting in better engagement with timely new content.

          Seems more like a way to send a message to the running web app. What I mean are the notifications that pop up on your phone… If I close the tab, the website can’t do anything.

          The only use case of actual push notifications on “websites” I can think about: Push notifications in PWAs…

    • SatanicNotMessianic@lemmy.ml
      link
      fedilink
      English
      arrow-up
      6
      ·
      1 year ago

      I understand how that might be a justification, but I’m really not sure about that. I can’t imagine using LinkedIn so many times per hour that caching would make any improvement in my experience, and I suspect that fixed asset caching in the browser would take care of a chunk of that anyway. Even if there were some headhunters using the phone version 8 hours+ per day, the amount of time wasted and the number of annoyed customers dealing with the app harassment would still have a negative overall cost. I’ve done these kinds of KPIs.

      It’s about

      1. Control over data mining at a much higher level than can be done from a browser including location tracking
      2. Monetization of the data via “third party partners”
      3. Making sure the app team is justified as an ongoing cost, because that’s just the way corporate organizations work