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.
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.
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.
Comments
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.
Web apps can now have an icon on the desktop, their own top level windows, etc. That's what PWAs are all about.
A few years ago I wrote a framework for daemon-based native/browser apps: https://github.com/jdarpinian/web-ui-skeleton. I used it for a benchmark that I wrote: https://google.github.io/latency-benchmark/ This approach is underused for sure.
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.
... are there any people on earth who prefer to use the CUPS web console rather than their DE's printer settings ?
An example was provided, I wasn't asked to provide a Mona Lisa of the ultimate UI/UX design experience.
I do. The DE's printer settings rarely work. CUPS on the other hand always has some way of successfully configuring a printer.
And whatever its problems are, not being an Electron app is not one of them.
At least one!
> I have not seen many applications that take daemon + local browser approach. What are the examples?
Jupyter Notebooks.
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.
I made a framework for it a few years ago: 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.
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.