I’ll admit I also didn’t really get what you were after, so the clarification was welcome. 
I don’t think anyone’s heavily invested in the idea of Electron itself if there is another approach with equivalent results. Electron does have the advantage that once the integration is done you get more or less free, working, application builds for Mac, Windows and Linux.
As long time silent syncthing user i agree with @jerryjacobs. I am actually using his excelent xor-gate/syncthing-macosx and i don’t think there is anything useful Electron could bring Syncthing.
I have a little experience with Electron. I’ve made unofficial Riot electron client before there was official one (when it used to be called Vector).
I think electron is misunderstood. It is not a website wrapper. The main feature is that it combines browser with Node.js in one package an you can call Node from the web view. Meaning you can do stuff browser can’t (run webserver, manipulate filesystem etc). This is useful when you already have some webapp that could use things like cashing, local database stuff like that. Or you make completely new desktop software (peer2peer is very common usecase).
It would make more sense to use something like https://github.com/zserge/webview or https://github.com/asticode/go-astilectron which bundles webview with Go instead of Node.
But it still is not useful since most of the time you just have syncthing running as service in the background. You don’t want to have to run Electron app so your syncthing works.
Webviews are expensive, they take lot of memory. Electron tray apps are stupid, people make them just for fun because it is very easy. Every webview takes like 150MB ram minimum imagine having 5 of them. xor-gate/syncthing-macosx takes around 20MB for me.
I believe the reason people use syncthing tray clients are:
- Easy install
- Quick if syncthing is running and is ok
- Shortcut to syncthing webapp
- Automatic updates (dunno if all of them do it or syncthing does this automatically but syncthing-macosx does and its most important feature)
But i guess i have 5-10 syncthing folders on my machines. If you are dealing with many more maybe there is need for better more responsive client. Then the problem is the legacy angular 1 client which is unfortunate but hard to replace.
3 Likes
Thanks for that informative response. I will have to check out that syncthing-macosx repo. Also kudos on your Riot development. That is another fantastic open source project that I use daily.
Thank you for your clear explanation of the differences in technology and memory usage between native and “cross platform” application!
So you’re saying that using Electron as a website wrapper would be an overkill if one does not make use of additional Node.js features?
Hence I consider decoupling the GUI and the background service the best approach - despite the fact that it might complicate the initial setup.
That is true. Therefore Syncthing Tray does not use a web view for the tray application itself. Instantiating any web view is postponed until the user actually opens the web UI. There’s also an option to destroy the web view again when the web UI window has been closed. That is the best solution (I can think of) for mixing “tray application” with “web UI”.
So the few seconds the web UI requires to show folders and directories come from the legacy version of Angular (and could be prevented by using another framework or doing more things by hand)? I’m just asking because the startup time is annoying indeed. The initial reason I developed Syncthing Tray was not having to wait a few seconds for a simple task like triggering a folder rescan or simply checking the overall status.
We are on the same page here @Martchus i think your tray is the right apporach.
I don’t know much about GTK or QT development but i imagine that it is much much harder to make it than web ui. Synthing is going to have lot of options and doing it weby way seems the most flexible.
I am not 100% sure but considering the fact that you’ve made the GUI fast using Qt then it is not a problem of the Syncthing or the api. It is problem of the UI. A while back I tried digging into the angular 1 project that syncthing uses and it is crazy. Angular 1 is unfortunately probably the slowest framework there is. It is also completely dead. Angular 2 is completely different framework requiring complete rewrite if you want to upgrade.
I am pretty sure the web ui would be way faster if it was written today with current tech.
Working on the webui now is probably huge pain and not fun. Rewrite is also a huge task. I guess project is just stuck with it. I am pretty sure core devs want (and should) to put time into the syncthing itself not into javascript ui.
You could probably find some webdev person who would rewrite the ui IF the UI was problem for them when using syncthing but… i believe majority of the people don’t use the webapp too much. It’s more like gui for text config.