6 ms·

Why bother shipping an entire separate browser? What would you actually gain vs bundling the daemon with a tiny launcher that just opened a new browser tab with

Why bother shipping an entire separate browser? What would you actually gain vs bundling the daemon with a tiny launcher that just opened a new browser tab with “http://localhost:4855” http://localhost:4855” or whatnot?

MattGaiser 5y ago
That is going to look strange and suspicious to anyone who is not a tech worker.
- fock 5y ago
  why? The installer could clearly show a picture that this is how it works? People are not that stupid.
  - jitix 5y ago
    It’s not about stupidity. Infact it’ll be the people who are proficient with computers but don’t work in tech that will find this fishy and lose trust over the software. Installation and management UX is a core part of any software. It’s the same as us programmers driving cars or using kitchen gadgets. If something is out of the ordinary or the UX is difficult, we’ll think it’s fishy and lose a bit of confidence.
  - jakelazaroff 5y ago
    I would much rather use a tool that works similarly to most other tools on my computer, rather one that works totally differently but it’s cool because the installer explains it.
    - tacotacotaco 5y ago
      "Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know." https://lawsofux.com/jakobs-law/ https://lawsofux.com/jakobs-law/ Jakob Nielson is a founding member of Nielson Norman Group that has studied UX for decades. https://www.nngroup.com/ https://www.nngroup.com/
      - MattGaiser 5y ago
        Except this is a file system, so to users it shouldn’t be a site at all.
        tacotacotaco 5y ago
        This applies to all interactions. E.g. "Users spend most of their time _opening_ other _door handles_. This means that users prefer your _door handle_ to work the same way as all the other _door handles_ they already know."
    - dragonwriter 5y ago
      This is somewhat sensitive to application posture [0] (sites are, for this purpose, effectively apps, even if they aren’t the kind of site that would be described that way usually.) A site that is effectively a sovereign app has more freedom to defect from general interaction patterns, whereas one that is more of a transient app has less. [0] https://en.m.wikipedia.org/wiki/Application_posture https://en.m.wikipedia.org/wiki/Application_posture
  - deleted 5y ago
    [deleted]
stu2b50 5y ago
Some things will be pretty annoying to implement because pages in browsers are sandboxed and limited in how they’re allowed to interact with the OS. You are also running that daemon so theoretically nothing is stopping you from doing those things by having the daemon do it. But it’s pretty annoying that even things like a file path picker would need to be custom made and done via the daemon.
egeozcan 5y ago
For one, you have a better control on the GUI (native file pickers, app actions, your own icon etc.). Don't get me wrong, I actually ship the tools I build also as little servers (example: https://github.com/egeozcan/json-tail https://github.com/egeozcan/json-tail) but there are also disadvantages to this.
ravenstine 5y ago
The best compromise would be to open a web view. Though it's a concept often neglected, most languages have a package that does this.
- mrtesthah 5y ago
  Right -- that was the other thing I was going to suggest. There's nothing stopping you from using WKWebView on macOS or Edge WebView2 on Windows. Some might argue that there are browser differences -- to them, I ask: what's difference between targeting a single browser and targeting a single GUI toolkit/framework? They both limit the platform your code runs on. So you might as well choose the latter and give your users a native experience without ~300MB of useless bloat to save yourself what is probably not more than two lines of Javascript (you useless inconsiderate louts).
krapp 5y ago
What if it were possible to host Electron apps on a remote server? That way, instead of shipping a browser, the user could use their preferred browser to somehow load the app from the remote server, and run it on their local machine? The only major technical hurdle I can think of would be a way to locate and classify remote assets and resources, so one knows what belongs to what. We'd need to come up with an address system, something like a "universal resource locator" that could assign an app to a "domain" (think Java namespaces) that maps to one or more IP addresses. Instead of installing the app, you could just type the "domain" into the browser and access the application. It could be a revolution in the way Electron apps are distributed. Someone write this down!
- Zardoz84 5y ago
  It's called a "Web app".
  - mrtesthah 5y ago
    Whoosh.
johannes1234321 5y ago
This adds another layer of potential security flaws. Other applications might try to connect to that daemon via network and exploit it. In turn you have to do all the security things in it, treating your frontend as potentially malicious. In an electron app you have secure communication channels. (Still have to be careful on data by the user, but all you get in the backend from the frontend is from your code)
- rapsey 5y ago
  Also various local firewalls and anti virus software are going to block it by default.
nitrogen 5y ago
I ran a bootstrapped non-IoT home automation startup from 2009 to ~2014. The hardware UI was presented as a web interface over the local network (backend was a mix of Ruby and C, some of which I have open sourced). Some customers had problems because they had malware browser toolbars installed that rewrote/altered the HTML.

MattGaiser 5y ago

That is going to look strange and suspicious to anyone who is not a tech worker.

fock 5y ago
why? The installer could clearly show a picture that this is how it works? People are not that stupid.
- jitix 5y ago
  It’s not about stupidity. Infact it’ll be the people who are proficient with computers but don’t work in tech that will find this fishy and lose trust over the software. Installation and management UX is a core part of any software. It’s the same as us programmers driving cars or using kitchen gadgets. If something is out of the ordinary or the UX is difficult, we’ll think it’s fishy and lose a bit of confidence.
- jakelazaroff 5y ago
  I would much rather use a tool that works similarly to most other tools on my computer, rather one that works totally differently but it’s cool because the installer explains it.
  - tacotacotaco 5y ago
    "Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know." https://lawsofux.com/jakobs-law/ https://lawsofux.com/jakobs-law/ Jakob Nielson is a founding member of Nielson Norman Group that has studied UX for decades. https://www.nngroup.com/ https://www.nngroup.com/
    - MattGaiser 5y ago
      Except this is a file system, so to users it shouldn’t be a site at all.
      - tacotacotaco 5y ago
        This applies to all interactions. E.g. "Users spend most of their time _opening_ other _door handles_. This means that users prefer your _door handle_ to work the same way as all the other _door handles_ they already know."
  - dragonwriter 5y ago
    This is somewhat sensitive to application posture [0] (sites are, for this purpose, effectively apps, even if they aren’t the kind of site that would be described that way usually.) A site that is effectively a sovereign app has more freedom to defect from general interaction patterns, whereas one that is more of a transient app has less. [0] https://en.m.wikipedia.org/wiki/Application_posture https://en.m.wikipedia.org/wiki/Application_posture
- deleted 5y ago
  [deleted]

stu2b50 5y ago

Some things will be pretty annoying to implement because pages in browsers are sandboxed and limited in how they’re allowed to interact with the OS. You are also running that daemon so theoretically nothing is stopping you from doing those things by having the daemon do it. But it’s pretty annoying that even things like a file path picker would need to be custom made and done via the daemon.

egeozcan 5y ago

For one, you have a better control on the GUI (native file pickers, app actions, your own icon etc.). Don't get me wrong, I actually ship the tools I build also as little servers (example: https://github.com/egeozcan/json-tail https://github.com/egeozcan/json-tail) but there are also disadvantages to this.

ravenstine 5y ago

The best compromise would be to open a web view. Though it's a concept often neglected, most languages have a package that does this.

mrtesthah 5y ago
Right -- that was the other thing I was going to suggest. There's nothing stopping you from using WKWebView on macOS or Edge WebView2 on Windows. Some might argue that there are browser differences -- to them, I ask: what's difference between targeting a single browser and targeting a single GUI toolkit/framework? They both limit the platform your code runs on. So you might as well choose the latter and give your users a native experience without ~300MB of useless bloat to save yourself what is probably not more than two lines of Javascript (you useless inconsiderate louts).

krapp 5y ago

What if it were possible to host Electron apps on a remote server? That way, instead of shipping a browser, the user could use their preferred browser to somehow load the app from the remote server, and run it on their local machine? The only major technical hurdle I can think of would be a way to locate and classify remote assets and resources, so one knows what belongs to what. We'd need to come up with an address system, something like a "universal resource locator" that could assign an app to a "domain" (think Java namespaces) that maps to one or more IP addresses. Instead of installing the app, you could just type the "domain" into the browser and access the application. It could be a revolution in the way Electron apps are distributed. Someone write this down!

Zardoz84 5y ago
It's called a "Web app".
- mrtesthah 5y ago
  Whoosh.

johannes1234321 5y ago

This adds another layer of potential security flaws. Other applications might try to connect to that daemon via network and exploit it. In turn you have to do all the security things in it, treating your frontend as potentially malicious. In an electron app you have secure communication channels. (Still have to be careful on data by the user, but all you get in the backend from the frontend is from your code)

rapsey 5y ago
Also various local firewalls and anti virus software are going to block it by default.

nitrogen 5y ago

I ran a bootstrapped non-IoT home automation startup from 2009 to ~2014. The hardware UI was presented as a web interface over the local network (backend was a mix of Ruby and C, some of which I have open sourced). Some customers had problems because they had malware browser toolbars installed that rewrote/altered the HTML.