Status on new GUI

From the Angular website:

One of the keys to a successful upgrade is to do it incrementally, by running the two frameworks side by side in the same application, and porting AngularJS components to Angular one by one. This makes it possible to upgrade even large and complex applications without disrupting other business, because the work can be done collaboratively and spread over a period of time. The upgrade module in Angular has been designed to make incremental upgrading seamless.

So a typical AngularJS upgrade means simply copy all existing AngularJS code in Angular, and start porting over code step-by-step in multiple PR’s / releases.

Starting from scratch is still a much bigger task with higher risks of never finishing it.

I do estimate this is aprox 4 times as much work as the Bootstrap task I had in mind, since JS has to be rewritten to TS somewhere on the road and unit tested.

Ok guys let me get this baby to Angular. @tomasz86 the idea of keeping the old UI in there sounds good. Maybe give the people who can’t run Angular instructions how to use the older version, while making Angluar 15 hybrid the main.

Question: how do you guys do beta testing? Ideally you want to test it and roll it out to production soon.

We have release candidates which are released prior to the real release. For more closed testing, i.e. not all users should be exposed to the new thing, we’d need to have the new GUI as a separate selectable “theme”.

I’m skeptical that it’s possible to do a good job by porting the existing GUI component-for-component, but as the famous quote says, those who claim something is impossible shouldn’t get in the way of those who are actually doing it…

I liked the architectural design of the new-gui, but I agree that doing a from-scratch rewrite is a (maybe too) large job, hence it’s been stuck in limbo for a little while.

Support for non-current browsers shouldn’t be a main concern here, for all the reasons already mentioned.


Your’re doing charity work so I can’t really tell you what to do and what not to do, so do with this whatever you want, or just tell me to shut up.

I would not bother with “moving this baby to angular”. This baby has every disease under the sun and nobody wants to look at it. It’s a single large js file. There is no structure, no types.

I would take the modern ui that already uses modern frameworks, typescript, has skeletons for apis/services etc, upgrade it to latest and greatest of everything (which should be easy) and build on that to bring it to feature parity with the old thing.

Personally, to me, this proposition sounds like a lot less like septic tank diving (digging though a single 5k line file) and actual meaningful development, building things from the ground up.


This baby has every disease under the sun and nobody wants to look at it.

Nice way to explain it. :smiley: Since I’m a doctor, I might be able to fix the baby. We can also make a new one but the pregnancy takes a couple of months and maybe the new baby has it’s own imperfections that we have to solve after giving birth as well. Fixing the current baby requires a lot of medicines, but it can still be quicker and along the way we can deprecate / improve things while quickly bringing fixes to the userbase so they will experience improvements as the baby gets healed step-by-step.

Jokes aside, I value your opinion no need to shut up, you also do good work for the project. I think the ball is now on my side, the above topic was helpfull for me thanks everyone for participating. I do have other stuff ofc in my life so might take some weeks before I have something but let’s see, still very much motivated.


Not a dev, but a user… I don’t have any major problems with the existing GUI, and feel comfortable using it…

I DO get annoyed when people try to change to “New and Improved” just because it’s “Cool” or adds functionality that is only mildly helpful and forces one to learn a new interface or redo things that were working until the change broke them…

I really hate having ‘sleek new features’ added that change how things work… I hate Microsoft on principle, but am particularly annoyed by how every new version of Windows changes the UI, with no benefit if I don’t want the new crap…

Same thing even on GNU/Linux - every time they come out with a new improved version of KDE, I have to spend hours figuring out how to turn OFF all the new garbage that I didn’t ask for and don’t want…

So put me down as a user that is fine w/ changes under the hood, but does NOT want to see significant changes to the UI that I see in my browser…



Just to remove any potential doubts from @ssgtcookie or anyone else wanting to work on a new/revised GUI: I desire getting new/updated GUI. As long as it improves either maitainability or UX, without making the other worse, I welcome it, regardless of if the UI changes. Backwards compatibility is a concern to me, but not a deal-breaker. Especially given how easy it is to preserve a web UI either within syncthing itself or as a separate project.

(Personal note and completely unrelated, just a reactin to @ex-Gooserider’s comment above: KDE’s UX improved in huge strides in the past few years - most importantly because it got stabler. Also emacs is my main editor/IDE/… - just to defuse any sentiments of “young GUI-loving VS code using fools don’t know what’s good anymore nowadays”).


Sorry what do you mean exactly with this sentence?

“… anyone else wanting to work on a new/revised GUI: I want a new GUI.”?

You mean you don’t want to work iterative (agile) but you want to work on a big-bang release (waterfall) and bring all new functionality at once? Both is possible ofcourse.

I have a version running on my localhost currently that runs in hybrid mode (Angular 15 as base but all JS is still running in AngularJS 1.3.20). It works, but there are some changes I want to make to make it ready for a future PR. Got about 8 hours in it currently, I estimate my progress at 25%.

The KDE stuff you talk about I don’t fully understand. KDE is a desktop environment right, what has this to do with the web UI exactly? Maybe I’m missing knowledge on this subject.

Guessing, and putting words in Simon’s mouth, I think he just meant that any work in this direction is appreciated. A feeling I concur with.


What Jakob said. My comment apparently did do pretty much the opposite of it’s actual intention, which is to re-assure you that your contribution is welcome.

The KDE quip was entirely unrelated indeed, just a reaction to the post above me - sorry for the confusion.

1 Like

Just as a clarification, as the one that brought up KDE, I don’t think KDE has any direct relationship w/ Syncthing… I was only bringing it up as an example of what I consider to be BREAKING the UI by trying to create ‘new and improved’ features that take a great deal of effort to get rid of in order to get back to what worked… I don’t want to get more specific than that as it isn’t relevant to ST development.


I see the AngularJS $scope is a bit abused by storing data in it, retrieved from the BE. I can imagine this gets heavy for the UI when the data size of $scope increases. Something we can fix with redux later on the road.

  • Question: how does the RC thing works? Is there a RC branch I can set as target for a PR?

  • Question: I would like to have some mockdata to see the UI in all it’s glory. Do you guys have that by coincidence?

Current progress: aprox 40%. Current task: testing with the actual syncthing service + wiremock stubbed responses to test if all works ok.

Next up: figure out how to make the “new” hybrid UI the default including build script to build the angular production bundle.

Great to hear there’s progress!

Just target main. RC might become a branch, but generally it’s just a release cut directly from main and then there’s a delay for testing and bug-fixes only until general release (it’s a bit more nuanced but that doesn’t really matter). Whether RC is enabled is a setting. So it should be just possible to bundle your UI, but keep using the old one, and then first make it probably completely opt-in (setting, env var, …) and then later enable it for everyone with the RC setting enabled - something like that. I can help with navigating that if desired, first thing is to get it running any way possible :slight_smile:

There’s no mock data for the current ui. The next-gen-gui does have it I think (and it’s angular too, so maybe re-usable.

Also likely possible to just adapt whatever happens for next-gen-gui.

1 Like