Status on new GUI

Hey guys,

On the syncthing website there is this post on a new GUI. The post is from 2019, any updates on this one? I have quite some experience, maybe I can assisst?

edit: just noticed this folder: syncthing/next-gen-gui at main · syncthing/syncthing · GitHub

So more info on this new version? Timelines / progression etc. latest update is from 2020 I see

1 Like

It may be useful when viewing a very large setup. The normal GUI starts to struggle and becomes unresponsive with larger numbers (e.g. 100+) of folders and/or devices. However, “viewing” is the key word here, as currently that’s all you can do with, since there is no edit functionality whatsoever.

Also, the other GUI isn’t included in the standard Syncthing distribution, so you’d have to compile your own build if you want to test it out.

1 Like

Hi @tomasz86 thanks for the quick reply. Good to know that the GUI has some difficulties with large amounts of data, something to keep in mind.

Do you know if other developers worked on the front-end in the last year / months? The new front-end project looks good but it’s also quite ambitious to re-do the whole thing. I also wonder if that might be the reason why nobody worked on the new GUI for 2 years or so?

I’m more in favour of upgrading the “old” UI to something fancy in smaller steps. This way you can also release upgrades to customers with less impact as you only change things under the hood or small visual changes.

To give an example… the current version of the “old” UI is made in bootstrap 3. The current version is version 5. Migrating from 3 to 5 is not a lot of work, say 1-2 days. After this upgrade the UI will look very much the same, but under the hood it will be better.

I don’t know ecactly what the best next step would be but it could be the introduction of a framework like angular / react and port the old UI over to that framework with a copy-paste and release that to customers. Next in itterations, slowly “bake” the app more in the angular framework and make some UI improvements.

These are just some thoughts tho…

1 Like

Sure, the standard GUI has been worked on continuously (see the commit history at https://github.com/syncthing/syncthing/commits/main/gui). This includes both bugfixes and (from time to time) new features.

Please keep in mind that the GUI does use quite a few custom styles and scripts on top of Bootstrap, and also several other 3rd party components (see https://github.com/syncthing/syncthing/tree/main/gui/default/vendor) which we need to be sure that all work smoothly together as a whole. There is also the issue of specific browser compatibility which can be broken by such upgrades rather easily.

The Web GUI isn’t like any other website, it’s literally the interface that the vast majority of users rely on to access the program, so I believe it’s always important to make sure that everything works as intended and doesn’t suddenly break between program updates, unless there is a valid reason of course (e.g. see the last update for Android where Android 4 support had to be dropped) and not just because a new version is out.

You are very welcome with trying to upgrade the current UI. The reason why I’d propose to do something new is two-fold: The current one is a monolithic bit of JS written by people not very prolific in GUI and JS stuff, using an old version of a deprecated framework (angularjs). And there’s quite a few ideas how some fundamental aspects of the UI could be changed for better UX (there have been forum threads and propably also some GH issue on it, with mockups and stuff) - it’s much easier to do such changes if you don’t need to care about breaking the existing setup.

Anyway the original foundation grant mostly didn’t happen because it turned out to both be hard to manage on our end and find someone who wants and can work on it.

Yepp all very understandable.

Alright I checked all GUI files. Lot of HTML with if-statements going on I see so I have to be carefull to not break these flows. Overal it seems like a fun project and I do believe the bootstrap upgrade will benefit the project nicely. However let’s see the coming weeks how it goes. If you have some kind of more private communication server / channel, let me know.

A veryvery early mockup just so you guys get a little bit a feeling what I have in mind:

I configured the development environment and I can connect to my local syncthing rest API. I want the project to work exactly the same as it works now also with using the same AngularJS logic, but with upgraded bootstrap components and some UX improvements to make it look fresh and smooth. Bootstrap 5.3.x also has native dark theme support, with this changing to a dark mode only means changing one value in the html and all elements will support the dark / white mode. With onlly minor SCSS tweaks, I can change the components a little to give it a nice touch to give it a modern fresh look, while staying close to the bootstrap framework.

Let’s stay in touch, too early to really discus the work. I would like to keep getting feedback on the work because I want to prevent it from getting rejected in the end, rather change course early. :slight_smile:

1 Like

Honestly, upgrading to Bootstrap 5 would break compatibility with many old browsers (see https://getbootstrap.com/docs/5.0/getting-started/browsers-devices) like IE11 (which I’m probably the only one who still cares about :sweat_smile:) but also Android 5 WebView (which Syncthing officially supports) that is used to load the Web GUI internally. Bootstrap 4, on the other hand, should be much more feasible (see https://getbootstrap.com/docs/4.0/getting-started/browsers-devices), at least at this point in time.

I would also be very cautious about any radical changes to the current GUI as people usually aren’t fond of them (e.g. see the recent complaints about seemingly minor things like adding “connection type” icons or folder/device total number to headings, etc.).

Support for older devices and browsers is always a point of consideration. However, when renewing the GUI I’m not sure we should make it a hard requirement to support devices/browsers which are being used by 0.4-2% of the respective users (not Syncthing specific) and are, in one way or the other, severely out-dated. This is just something that should be decided beforehand.

People are going to comment on any change, correct. This is however not a good reason to not go forward with something new. In the end the current GUI is not maintainable in the long run and there are plenty of ideas about how to improve it.

This will however be a big project and probably require some alpha/beta release as an optional feature for awhile until it’s ready to replace the current GUI. Otherwise, if we don’t replace the existing GUI at some point forcibly, one keeps digging in the mud and maintaining two GUIs is not feasible either.

Alright, do you guys have insight in the usage of IE users on syncthing? On this website I see that roughly 0,28% users is on IE. On other websites I checked it goes up to 2%.

Regarding android webview, webView will auto-update for mobile devices with Android L (2014) and above. So only if you never do your updates or you have a device from before 2014, this can be an issue. You mention that syncthing supports Android 5 WebView officialy. I hear you, but ask yourself the question: will you keep supporting this version untill forever, or is there a point where you want to drop this and go with newer tech? If so, where is that point? I think using bootstrap 5.3 brings very nice improvements for the 98% of the users.

About the the radcical changes part… I do fully agree with you that bringing a lot of changes in the design is risky. Another reason to go with incremental changes if you ask me. Upgrading bootstrap instead of building a complete new version that looks completely different is a good way to keep the design changes and complaints at a minimum. In the design I have in mind I will not touch the existing javascript logic and I will rebuild the UI with the goal of having the UI look close to what it is now.

However if you guys want to keep things as they are that is also fine! I appreciate and respect your opinion, but than I’m not going to pull on a dead horse becaue I don’t like working with old tech like bootstrap 4 or upgrading to Angular versions that are not the latest versions to support 2% of the users. No offence here, just sharing my thoughts on this all. :slight_smile:

It’s a fine line between providing meaningful support for older devices and holding others hostage because of legacy systems owned by a few.

IE11 can and should be fully replaced by Chrome/Firefox. Dropping support for 8 year old smartphones isn’t too crazy either.

Why do you think so? The current GUI has been around for ~8 years and it seems to have been doing the job quite well so far. As far as I know, the browser support has also remained mostly the same until now. Is there any practical benefit for the end user in introducing breaking changes after all that time? By “practical benefit” I mean something that the end user will actually be able to feel and experience, not just pure code improvements under the hood, of course (as obviously the old code has its own problems too, but at least it’s been proven and battle-tested quite a bit).

For the record, I do support the idea that it would be useful to have an alternative that’s more modular and based on modern technologies. However, I do not believe that it’s worth to break the current GUI just for the sake of it, even if only 2% of users would be affected. The 2% are usually those that need help the most (e.g. people stuck with old hardware/software, schools with ancient computers, etc.). They normally don’t use the outdated devices and browsers because they want to, they do it because that’s all they’ve got access to…

1 Like

Just to bring some nuance in your statement, breaking changes for a very small percentage of users.

And yes, there is practical benefit in it. The fast majority of users like a modern user interface that doesnt look like it was made in the 90’s. Your argument that the current UI works and keeps working is true, but it doesn’t mean that users are happy with it or wouldnt like to see a more modern design. Let’s be honest… most people don’t want to work with old looking applications, people like smooth apps with nice animations and such. I don’t think a lot of people want to switch from Windows 10 back to Windows 95 in terms of UX. The current syncthing interface is outdated and not very apealing for the users, this is why I makes me want to work on it actually.

Are you familiar with the open-source project “Pi-Hole”? Many users switched to the a newer alternative “AdGuard”. Oone of the reasons I see for that on the dutch website tweakers.net forum, is that users like the interface of AdGuard better. There are more reasons ofcourse, but this is one that I see frequently.

What about a poll on the userbase? Maybe it is a good step to ask the users if they would like to see UX improvements or keep everything the same for the future?

1 Like

I personally don’t see supporting ancient systems as a requirement, but obviously it’s always a tradeoff. If the entire change is upgrading, but not improving the code-base (for maintainablity, extensibility, e.g. keeping the current single, huge controller JS blob :slight_smile: ) or UX otherwise then that’s probably not worth the change. However I don’t think that’s even an option, doing such a major upgrade likely requires pretty extensive changes on the code as well as the UI.

Also we can always make it a “new UI” and keep the old one around. That’s not much maintenance burden - we don’t break our API and we could just declare it deprecated in the sense that updates for new features aren’t guaranteed, but obviously can still be done by users of the old UI.

You are aware that angularjs (!= angular) is discuntionued? Of course you can update it to the latest release from last year, but it wont receive any updates after. So in terms of maintainability such an upgrade is not really a relevant win. If you just mean re-using the JS logic/code: There’s not that much logic there, and it’s a huge somewhat ugly blob. It can definitely be used as a reference but I doubt you can just plug it into a new framework.

Anyway, this discussion seems a bit pre-emptive. At least to me it’s not entirely clear what your, @ssgtcookie, endgame is here, just that you’d like to work on top of the existing UI and use modern tools. Is there any vision beyond that, i.e. some kind of change, extension, improvement, … you’d like to do on the UI?

Lets not go down that road of generic extremes, that’s not helpful. The expressed desire for a better, also more modern UI can be found in a vast history of topics, attempts, … in the project. At the same time we do care for not breaking users, but that doesn’t mean we can’t do upgrades. There’s a plethora of things to consider and also options to mitgitate some impact. Coming back to what I said before: I think it’s always dangerous to get too far into the weeds while a change/vision/… is still completely open and undefined. That just asks for projecting worries (or overblown hope) into it. So personally I’d love it if the discussion could focus a bit more on the “what” and broad strokes of “how” of the changes before jumping into the nitty gritty like supporting IE.

2 Likes

You are aware that angularjs (!= angular) is discuntionued? Of course you can update it to the latest release from last year, but it wont receive any updates after.

Yes I’m aware. I don’t see a lot of value in upgrading AngularJS. Upgrading AngularJS to Angular is something I can also do, but I can’t do both the Angular upgrade AND the bootstrap upgrade because that is simply too much at once. I rather work on one thing, bring it to the users and when that is done, start on the next thing.

So my endgame is to help you guys and the userbase by creating something cool in a relative short timeframe with new tech. These long forum talks is not what I joined in for, but it’s important because we have to be on the same line right. :smiley: If I’m spending days on development in Bootstrap 5 to see it getting dropped in a PR at the end because “we want to support IE”, I’m not happy hope you guys understand that.

So what I’m looking for now is a GO or NO GO. I want to spent some days in it and show you guys more what I have in mind. The maintainers can give feedback during this proces or even decide to drop the whole design I create if the maintainers don’t like it, no worries. When it’s more finished, we can do some beta testing and search bugs. However… I need to be sure you guys approve the bootstrap 5 strategy AND the strategy to upgrade the existing UI. There is no point of upgrading to bootstrap 5 if the PR is not making a chance to get merged to begin with.

2 Likes

100% this. Big bang migrations rarely work as intended.

2 Likes

To be honest, I think making the code maintainable/composable is of more value than upgrading some css stuff.

I’d take a plaintext ui that has sensible component abstractions and makes it possible to add new features without risking breaking everything, over some css upgrades that keep a single massive type-less js blob.

The fancy css can come later.

Ok fair point. I’m assuming you are referring to the upgrade of AngularJS to Angular? Problem here is that since Angular 13 the support for IE is dropped. Latest version is Angular 15.@tomasz86 said he rather not drop support and I’m not going to work with Angular 13 so I don’t think this upgrade is something I can work on.

Personally I have no sympathy for people on archeological devices. People can always install ffox, et al, even on a phone.

Old ui will stay, so they can continue limping on forever on it, until at somepoint it will lack enough things that people will naturally switch.

This is my personal opinion however, other maintainers might disagree.

I’d literally take latest and greatest angular, latest and greatest material, and not look back.

2 Likes

AngularJS is the very backbone of the current GUI. If you replace it, isn’t the process essentially equal to rewriting the GUI from scratch? If you do manage to do it and the new version is significantly better (e.g. using modular components instead of one large JS script to handle everything, etc.), then why not take the @imsodin’s suggestion about keeping the old GUI around?

This would allow to utilise the newer technologies while also not leaving behind those who can’t use them (for whatever reason). I can probably even offer to keep working on the old GUI myself (= mostly make sure that it still functions) if there’s need for that in the future.

1 Like

It doesn’t really matter if you look at it as a new UI done from scratch or just a big change of the current one. If necessary the old one could still be shipped alongside the new one either way.

Generally I agree with Audrius’ statement.

1 Like