4 ms·

We ported our game development software Construct [1] from a Windows desktop app to the browser in 2017, and haven't looked back since - it's been great! The a

We ported our game development software Construct [1] from a Windows desktop app to the browser in 2017, and haven't looked back since - it's been great! The approach of "local app in the browser" works very well and is underrated IMO. It's the approach we use too - everything is downloaded via a Service Worker for offline support, and it's very responsive as nothing needs to wait on the network, unless the user chooses to (e.g. saving their work to Google Drive). Chrome 86 also introduces the File System Access API [2] which is the icing on the cake - you can get read/write access to actual local files and folders, bypassing any issues about IndexedDB limits or persistence. I think this is one of the last pieces of the puzzle to make tools like Electron and NW.js more or less redundant, as now you can just do it directly in the browser and not have to ship the whole runtime around to everyone as well. [1] https://www.construct.net https://www.construct.net [2] https://web.dev/file-system-access/ https://web.dev/file-system-access/

jlongster 6y ago
Looks awesome!
pjmlp 6y ago
Electron has always been redundant, the approach daemon + local browser has worked since browsers exist, and then there are web views anyway. The problem is that those approaches require the developers to actually care about what browser the user has installed instead of pushing Chrome everywhere.
- mynegation 6y ago
  I disagree. I have not seen many applications that take daemon + local browser approach. What are the examples? Yes, each Electron app ships a copy of node and Chromium engine, but user gets icon on a desktop, ability to manage windows with whatever window manager and utilities, hotkeys, tray icons, dedicated menu etc.
  - lovasoa 6y ago
    I was thinking about the browser+daemon approach for an application that I maintain, and would also be very interested if someone has done it and has feedback to give.
    - modeless 6y ago
      I made a framework for it a few years ago: https://github.com/jdarpinian/web-ui-skeleton https://github.com/jdarpinian/web-ui-skeleton You do have to be careful to avoid security issues. XSRF could be a problem if your server exposes sensitive APIs. But XSRF is not unique to this approach, and the techniques for defending against it are well known. And Electron has security issues of its own which are probably more serious. Overall I recommend the daemon + browser approach. The "benefit" to Electron of only having to support one browser is rarely realized in practice because you almost always want a hosted version of your app as well, and that needs to support all browsers anyway. For example Slack and VSCode both have web versions.
  - mav3rick 6y ago
    It is insane for a browser to be a runtime for every desktop app. This is why people complain about 16 GB memory being too little.
  - pjmlp 6y ago
    CUPS admin console, SharePoint admin console for example. Same can be done with web widgets, or a couple of utility daemons. Well, at the end of the day don't complain about Google owning the Web.
    - jcelerier 6y ago
      ... are there any people on earth who prefer to use the CUPS web console rather than their DE's printer settings ?
      - pjmlp 6y ago
        An example was provided, I wasn't asked to provide a Mona Lisa of the ultimate UI/UX design experience.
- zamadatix 6y ago
  Daemon+web results in exactly that, two apps. Electron allows a single app to be developed i.e. you dont have to think about how to ferry the data back and forth (or at least when you do you hace more options than "how can i shove this over http"). IMO that is infibitely more valuable than dealing with browser inconsitencies in 2020.
  - pjmlp 6y ago
    Webviews are the answer there. As I keep saying don't complain about Web == ChromeOS, when you push Electron everywhere.
olnluis 6y ago
I taught some summer game development classes for middle schoolers using Construct on the browser. It was a breeze.
seanwilson 6y ago
> Chrome 86 also introduces the File System Access API [2] which is the icing on the cake - you can get read/write access to actual local files and folders, bypassing any issues about IndexedDB limits or persistence. How likely is this to get deprecated like the file system API, web SQL API and Chrome apps? I'm excited about this too but support is still poor https://caniuse.com/native-filesystem-api https://caniuse.com/native-filesystem-api.

jlongster 6y ago

Looks awesome!

pjmlp 6y ago

Electron has always been redundant, the approach daemon + local browser has worked since browsers exist, and then there are web views anyway. The problem is that those approaches require the developers to actually care about what browser the user has installed instead of pushing Chrome everywhere.

mynegation 6y ago
I disagree. I have not seen many applications that take daemon + local browser approach. What are the examples? Yes, each Electron app ships a copy of node and Chromium engine, but user gets icon on a desktop, ability to manage windows with whatever window manager and utilities, hotkeys, tray icons, dedicated menu etc.
- lovasoa 6y ago
  I was thinking about the browser+daemon approach for an application that I maintain, and would also be very interested if someone has done it and has feedback to give.
  - modeless 6y ago
    I made a framework for it a few years ago: https://github.com/jdarpinian/web-ui-skeleton https://github.com/jdarpinian/web-ui-skeleton You do have to be careful to avoid security issues. XSRF could be a problem if your server exposes sensitive APIs. But XSRF is not unique to this approach, and the techniques for defending against it are well known. And Electron has security issues of its own which are probably more serious. Overall I recommend the daemon + browser approach. The "benefit" to Electron of only having to support one browser is rarely realized in practice because you almost always want a hosted version of your app as well, and that needs to support all browsers anyway. For example Slack and VSCode both have web versions.
- mav3rick 6y ago
  It is insane for a browser to be a runtime for every desktop app. This is why people complain about 16 GB memory being too little.
- pjmlp 6y ago
  CUPS admin console, SharePoint admin console for example. Same can be done with web widgets, or a couple of utility daemons. Well, at the end of the day don't complain about Google owning the Web.
  - jcelerier 6y ago
    ... are there any people on earth who prefer to use the CUPS web console rather than their DE's printer settings ?
    - pjmlp 6y ago
      An example was provided, I wasn't asked to provide a Mona Lisa of the ultimate UI/UX design experience.
zamadatix 6y ago
Daemon+web results in exactly that, two apps. Electron allows a single app to be developed i.e. you dont have to think about how to ferry the data back and forth (or at least when you do you hace more options than "how can i shove this over http"). IMO that is infibitely more valuable than dealing with browser inconsitencies in 2020.
- pjmlp 6y ago
  Webviews are the answer there. As I keep saying don't complain about Web == ChromeOS, when you push Electron everywhere.

olnluis 6y ago

I taught some summer game development classes for middle schoolers using Construct on the browser. It was a breeze.

seanwilson 6y ago

> Chrome 86 also introduces the File System Access API [2] which is the icing on the cake - you can get read/write access to actual local files and folders, bypassing any issues about IndexedDB limits or persistence. How likely is this to get deprecated like the file system API, web SQL API and Chrome apps? I'm excited about this too but support is still poor https://caniuse.com/native-filesystem-api https://caniuse.com/native-filesystem-api.