Not really that worried but rather curious about your opinions. Use what suits your demands best.

But for starters:

Electron is a framework based on Chromium used to develop desktop apps. Examples of apps that are built on Electron are Discord, Element Desktop, MS Teams, Slack, GitHub Desktop, Atom, VS Code and counting

  • @ShortFuse
    link
    5
    edit-2
    1 year ago

    About 8 years ago now I ditched .NET, Java (Android), and Objective-C (iOS) to JS in frontend and backend with NodeJS and PWAs and couldn’t be happier for a dev perspective.

    All frontend is just one code. Sure, you have to manage browsers compatibility, but it’s not a major issue. Mobile users and desktop use the same application. I didn’t know Firefox dropped PWA on Desktop, though most of my desktop users were using Edge or Chrome. I can only think of one client that used Firefox and it worked fine, except for Firefox has some out of spec EventSource bugs. Safari has gotten better (especially after 16.4) now where I would Firefox as the leading source of browser issues when developing. Also, Safari 17 looks to finally treat PWAs with some legitimacy. We even have Push notifications now!

    I don’t understand Firefox’s decision, but Firefox on Android still supports PWAs on Android. But if they no longer care about desktop PWAs then I’ll give Firefox less importance for desktop environments. Probably doesn’t mean much in testing, but that means if I find a Firefox exclusive bug related to desktop (eg: mouse), I might just ignore it.

    I would highly recommend PWA over Electron. There’s nothing better than getting clients to transition to your software from a competitor with just a simple PWA with no install. I also support as far back as Chrome 88, which means any EOL ChromeOS device is still supported.

    You might need newer APIs depending on usage, but I haven’t found anything that I need to tap into some sort of native runtime for core usage. Maybe WebRTC runs better on newer Chrome, but nothing really requires native code. It’s just easier to maintain one single codebase without locking out potential clients because of OS (desktop or mobile).

    • ZyratoxxOP
      link
      fedilink
      11 year ago

      Oh, cool. I’ve barely scratched the surface on that topic, therefore I got a few more questions concerning PWA and Electron apps:

      Are PWAs “only” websites that are shown as an app or do they have features that would distinct them from “normal websites”?

      Can PWAs reserve disk space for offline downloads for example (Spotify has got a PWA but that one is mainly their website shown as an app). And I probably can’t install a listener via PWA like Discord does for their Rich Presence, can I?

      I expect the last one to be a no because that’s probably not what you’d use a PWA for as far as I understand, but I’m especially interested about the first question

      • @ShortFuse
        link
        2
        edit-2
        1 year ago

        Are PWAs “only” websites that are shown as an app or do they have features that would distinct them from “normal websites”?

        In theory, they’re the same. In practice, user agents (read: browsers) can dictate extra, uh, privileges to PWAs. For example, Safari Mobile won’t allow push notifications for just websites. As a dev, we don’t control this aspect. We just code "isPushAllowed()` and continue from there. As a marketer or apps/software I learn what browsers and environments allow what, so I know they need to install as a PWA to get access to some APIs.

        Can PWAs reserve disk space for offline downloads for example (Spotify has got a PWA but that one is mainly their website shown as an app).

        Branching off the other point, it’s up to the user agents. For example, Safari Mobile will delete storage for websites after a certain time (I think 6 months). But PWAs have unlimited lifespan (a misconception years ago). It’s not what you asked (storage size vs lifespan), but it gives you a clue to how browsers manage this. I personally haven’t experienced much issue with storage, but I do know there’s even a File API which gives access to your actual drive. I would imagine if browsers are allowing us to access “unlimited” storage over the file system, the restrictions for the Local Storage aren’t that important.

        A short search brought me here which mentions 80% of total disc space for Chrome, 50% for Firefox, and 1GB for Safari. Nothing here talks about PWAs, but I’d imagine Safari is the only one worth concern. I can research more if you want, but it’s not in my use case to concern myself with local storage.

        Edit:

        And I probably can’t install a listener via PWA like Discord does for their Rich Presence, can I?

        As long as there’s an API, for better or for worse, we can do it in PWA. From what I read, there doesn’t seem like anything like this in the Web API. Background tasks are currently somewhat restricted in the interest of battery conservation of mobile devices. From a theoretically point, an app running in the same environment as the PWA could have somethig shared between them. There are API in addition to Web APIs, like extensions, but there’s probably a lack of normalization for detecting what is running on the device.

        The idea of making everything in the Chrome Addon/Extension API in to real API is part of Product Fugu and from looking Chrome never built anything to expose what native system processes are being run with a web site. It’s honestly such a specific (and invasive) prospect I doubt it’ll ever happens. The closest is chrome.tabs but there’s no web equivalent.

        Sharing of other PWAs running probably won’t happen because sandbox/isolation is pretty core to Web right now. Cross-app data sharing is something I don’t know about yet, but maybe if PWAs mature we’ll see that. Then games and media players can “broadcast” to other PWAs data like presence. I’d imagine that branch from the Web Share API.


        I’ll take this opportunity to state my bias. I believe in the Web standards, meaning it shouldn’t matter what browser or environment you use. They should all be the same. I want this for myself and express this to my clients.

        But because standards are “living” it’s always a moving target. What is supported today by your preferred setup may not take full advantage of what a Web App provides. But the idea is, after a while, you will gain those features later in your setup as browsers get better.

        This is something I’ve seen in practice since I wrote a lot in PWA and told my clients that eventually it’ll be in Safari, but I’m not going to write a native app for outdated browsers. And the investment paid off. Before, Safari users didn’t have Wakelock, Push, or good WebRTC experience, but today they’re mostly indistinguishable from Chrome Android. I didn’t have to change a single line of code to make that happen.

        • ZyratoxxOP
          link
          fedilink
          1
          edit-2
          1 year ago

          Woah, thanks so much for that detailed comment. I really learned a lot today (and my day has barely started yet).

          I had to write a small shop web app for my programming finals using C# and Razor pages. I then had an internship where my team and I developed a Blazor app using MudBlazor which was a really cool experience. It was back then when I when I really felt how Firefox and Chromium have their little differences since I developed it using Firefox and it was broken on Chromium.

          I’ve since not done much tho because I’ve focused more on the networking path but that info was really exciting me to try setting that up on my test project just for fun ^-^