7 ms·

'People complain about Electron a lot, but the primary complaint just seems to be that its bloated – carrying an entire browser engine along with something smal

'People complain about Electron a lot, but the primary complaint just seems to be that its bloated – carrying an entire browser engine along with something small. But like, all of our computers are already bloated, and there’s at least a 40% chance that right now I am bloated, and it doesn’t mean you should love me any less, and I think the above points I’ve raised override the lack of svelt-ness of the program. People don’t care that an application is a streamlined 3MB or a big round 200MB boy – they care that it works for them and it makes them feel good about using it.' I think this is true in some cases, but the sorts of folk who run rsync may be more interested in performant hardware that can run on older machines than average. Then again, they'd probably opt for sticking to the command-line tool. Still a very cool project!

mbrumlow 7y ago
I avoid electron apps because it is almost anti web. I would use apps built more like electron if they simply removed the electron part and replaced the app with a name for a namespace and simply shipped tht js/html/images along with a api service. Installing would be binding tht app to tht name space and using the browser of choose and navigating to namespace.localhost. In this case rsync.localhost. The system would be a bit more complex for handling auth and a few things but let's not get bogged down in solvable details. Then I could access my apps from my phone. Another system (if I chose to expose them publicly).
- pjmlp 7y ago
  Same here, just give me a PWA, or if one so insists in using the Web stack for the UI, then deliver the application as a daemon/service that uses whatever is the standard browser.
- mattnewton 7y ago
  This is more or less how Jupyter notebooks work, and I agree this experience is pretty great. Make it a local web server and the browser becomes your UI.
  - mbrumlow 7y ago
    Like maybe we can build this out. A common daemon for registering with. The concept would be very simple to build. I might start a github project. - Global daemon to register apps with. Apps could be installed system wide or per use. Think plopping a zip/tar/ or directory structure in something like /usr/local/webap.d/(namespace) -- might be abetter directory. Then a manifest file that describes some things about the service, such as how to start the API service, and the default entry point (index.html). - The global service is responsible for bringing apps on line by way of instance activation on say visiting a name space, or just keep them running. - Services once launched pick random port from range to bind to and system service acts as a reverse proxy and common auth for validating the local user. Maybe even ensure each of the API services are run per user and jailed to the home directory IDK, just thinking off the top of my head, I have written bits and pieces of this for various work projects, but never glued the idea into one single system.
    - spirodonfl 7y ago
      It's not that hard, actually, I've done this with Node. Since you can install Node anywhere, include a binary, or whatever, you can have Node run as a server and it can run with elevated privileges, if needed. You have it scan a directory structure and auto generate a path that you can use in a browser, any browser, to view your newly install app. You can do this with APIs too so you can have internal tools with APIs via a Node server that do all kinds of things. Some simple port forwarding rules (ymmv) make this available to your LAN or to the WWW. Add a DNS layer on top and you have something really cool. I do this for all kinds of stuff, mostly PWAs, but it lets me have my own notes, todo, systems management and more.
      - johannes1234321 7y ago
        It is easy, till you get into the trouble of local Firewalls, Double use of port numbers and all those details, where the daemon runs unexpectedly or stops without good information to the user etc
        7y ago
- pandalicious 7y ago
  what about local filesystem access, os integration, and all the other things that you expect a desktop app to be able to do (like in this case executing a separate binary) which violate the security models of browsers?
  - arithma 7y ago
    App becomes a local backend server that has privileged access to the machine (with control over what it accesses, maybe give it a specific user), and a web UI to access the app. Someone in the tree of replies for your parent explained and was contemplating actually going through with it.
- tracker1 7y ago
  You can already use node + Carlo if you want something without the browser piece. Of course, then you need to worry about multiple versions of node and the browser, and distribution becomes more of an issue.
- bavell 7y ago
  You can't break out of the sandbox to run shell commands et al from a browser. That's where electron & friends come in.
rakoo 7y ago
The sort of folk who run rsync is a niche clique. Maybe this GUI is the perfect occasion to put rsync in the hands of more people ? We all know how powerful it is, there is no reason it should be used only by people who are happy testing the different flags, reading random blog posts about what combination to use, and trying to find salvation in a 3000-line manual page.
- haggy 7y ago
  Where and how are you coming to the conclusion that rsync is "niche clique"?
  - oblio 7y ago
    If you use any CLI you are already "niche clique".
  - rakoo 7y ago
    Ask a hundred person in the street if they've ever heard, let alone used, rsync.
    - haggy 7y ago
      What kind of crap response is that? Ask any 100 people on the street about any industry specific tooling or terms and you're likely to get nothing. Go ask people 100 people about "liquidated derivatives" and see what happens.
      - rakoo 7y ago
        > Ask any 100 people on the street about any industry specific tooling or terms and you're likely to get nothing. That's exactly my point: rsync is a UNIX-specific tooling, which makes it niche among people who use computers.
        haggy 7y ago
        Your "logic" here (which is probably just trolling) is not worth another response
grumdan 7y ago
While disk space may not often be an issue (though small SSDs are commonplace), RAM usage certainly is an issue if every little tool is an electron app.

mbrumlow 7y ago

I avoid electron apps because it is almost anti web. I would use apps built more like electron if they simply removed the electron part and replaced the app with a name for a namespace and simply shipped tht js/html/images along with a api service. Installing would be binding tht app to tht name space and using the browser of choose and navigating to namespace.localhost. In this case rsync.localhost. The system would be a bit more complex for handling auth and a few things but let's not get bogged down in solvable details. Then I could access my apps from my phone. Another system (if I chose to expose them publicly).

pjmlp 7y ago
Same here, just give me a PWA, or if one so insists in using the Web stack for the UI, then deliver the application as a daemon/service that uses whatever is the standard browser.
mattnewton 7y ago
This is more or less how Jupyter notebooks work, and I agree this experience is pretty great. Make it a local web server and the browser becomes your UI.
- mbrumlow 7y ago
  Like maybe we can build this out. A common daemon for registering with. The concept would be very simple to build. I might start a github project. - Global daemon to register apps with. Apps could be installed system wide or per use. Think plopping a zip/tar/ or directory structure in something like /usr/local/webap.d/(namespace) -- might be abetter directory. Then a manifest file that describes some things about the service, such as how to start the API service, and the default entry point (index.html). - The global service is responsible for bringing apps on line by way of instance activation on say visiting a name space, or just keep them running. - Services once launched pick random port from range to bind to and system service acts as a reverse proxy and common auth for validating the local user. Maybe even ensure each of the API services are run per user and jailed to the home directory IDK, just thinking off the top of my head, I have written bits and pieces of this for various work projects, but never glued the idea into one single system.
  - spirodonfl 7y ago
    It's not that hard, actually, I've done this with Node. Since you can install Node anywhere, include a binary, or whatever, you can have Node run as a server and it can run with elevated privileges, if needed. You have it scan a directory structure and auto generate a path that you can use in a browser, any browser, to view your newly install app. You can do this with APIs too so you can have internal tools with APIs via a Node server that do all kinds of things. Some simple port forwarding rules (ymmv) make this available to your LAN or to the WWW. Add a DNS layer on top and you have something really cool. I do this for all kinds of stuff, mostly PWAs, but it lets me have my own notes, todo, systems management and more.
    - johannes1234321 7y ago
      It is easy, till you get into the trouble of local Firewalls, Double use of port numbers and all those details, where the daemon runs unexpectedly or stops without good information to the user etc
      - 7y ago
pandalicious 7y ago
what about local filesystem access, os integration, and all the other things that you expect a desktop app to be able to do (like in this case executing a separate binary) which violate the security models of browsers?
- arithma 7y ago
  App becomes a local backend server that has privileged access to the machine (with control over what it accesses, maybe give it a specific user), and a web UI to access the app. Someone in the tree of replies for your parent explained and was contemplating actually going through with it.
tracker1 7y ago
You can already use node + Carlo if you want something without the browser piece. Of course, then you need to worry about multiple versions of node and the browser, and distribution becomes more of an issue.
bavell 7y ago
You can't break out of the sandbox to run shell commands et al from a browser. That's where electron & friends come in.

rakoo 7y ago

The sort of folk who run rsync is a niche clique. Maybe this GUI is the perfect occasion to put rsync in the hands of more people ? We all know how powerful it is, there is no reason it should be used only by people who are happy testing the different flags, reading random blog posts about what combination to use, and trying to find salvation in a 3000-line manual page.

haggy 7y ago
Where and how are you coming to the conclusion that rsync is "niche clique"?
- oblio 7y ago
  If you use any CLI you are already "niche clique".
- rakoo 7y ago
  Ask a hundred person in the street if they've ever heard, let alone used, rsync.
  - haggy 7y ago
    What kind of crap response is that? Ask any 100 people on the street about any industry specific tooling or terms and you're likely to get nothing. Go ask people 100 people about "liquidated derivatives" and see what happens.
    - rakoo 7y ago
      > Ask any 100 people on the street about any industry specific tooling or terms and you're likely to get nothing. That's exactly my point: rsync is a UNIX-specific tooling, which makes it niche among people who use computers.
      - haggy 7y ago
        Your "logic" here (which is probably just trolling) is not worth another response

grumdan 7y ago

While disk space may not often be an issue (though small SSDs are commonplace), RAM usage certainly is an issue if every little tool is an electron app.