Building and updating next-gen-gui

Development
1

Originally I started out to update our next-gen-gui/README.md documentation. It mentions stuff from before the tech-ui was renamed to next-gen-gui and imported into the main repo. Its recommended install location contradicts what the build script actually does, though I think that should be fixed in the build script. And it points to an ancient repo for downloads of built versions.

Which brought me to the revelation that there are no automated builds of this code being done at all in our infrastructure. The original repo at https://github.com/kastelo/syncthing-tech-ui/ was moved to https://github.com/syncthing/tech-ui/, which in turn was archived after importing it into the main repo. The last built release can still be downloaded there at least. But the better thing to do would be integrating it into our main repo build actions. Maybe not by passing --with-next-gen-gui on every build, but having a separate job to build the ZIP file at least, for separate downloading.

So I started trying to build it myself, from the v1.28.0 sources. Which kind of worked, but gave a lot of deprecation and vulnerability warnings. Therefore I expect the CI build environment to choke on this pretty soon if we tried to include this build step. So the first step should be getting the “new” GUI into a better shape than the old one, regarding updated dependencies and keeping up with the pace of Angular and other components’ development. It currently uses Angular 9, while version 18 is the latest. Which probably means it will never be a basis to attract new Web developers for further GUI development or modernization.

So after a furious round of endless ng update ... and npm update --force ... calls, I managed to supposedly migrate the dependencies to more modern versions, namely Angular 18. But some deps I had to remove completely from package.json because they led to dependency conflicts. So in the end, the code does not build and I have little to no idea what the error messages mean or what all these dependencies actually do. Frankly, this whole Node.js world looks like the worst of all dependency hells to me, with so many packages and transitive dependencies accumulating even for the simplest development projects. I really wonder how professional JavaScript and Web developers can handle such things, with all dependencies being moving targets at a fast pace, and deprecations / incompatibilities being part of usual business.

I’d like to find some help with this from someone more knowledgeable in the Node.js world, as I have roughly zero experience with it. The end goal would be providing up-to-date builds of the next-gen-gui from our GitHub CI.

It might even be beneficial to move it out into a separate repo again, and only integrating built GUI code as part of the main Syncthing build. I always wonder how we never need to “build” anything related to AngularJS with the old GUI, but maybe that older framework just doesn’t need it?

Thanks for any pointers or opinions on a way forward.

1 Like
2

The planned changes to the README and build script can be seen here:

My current state of affairs for the dependency updates is available in this branch: GitHub - acolomb/syncthing at ngupdate

Some background info on what’s currently needed for the next-gen-gui to build at all (there’s an insecure way without dependency updates): node.js - Error message "error:0308010C:digital envelope routines::unsupported" - Stack Overflow

3

Hi ! I often wondered how to give back to syncthing what syncthing gave to me (I love it !) I could help with bringing the tech-gui dependencies hell to 2024, not immediately, but in the coming weeks.

If I understand correctly your report, I cloud start with GitHub - syncthing/tech-ui: Alternative, stripped down status UI for large setups as base for the update work, and your branch for hindsights ?

4

Hey thanks, that’s great to hear. Looking forward to some input whenever you find the time for it.

Regarding the development base, the code now lives in our main repository, which my branch is forked off from. It’s almost the same code as that old archived repository. You just need to look at the next-gen-gui subdirectory here: syncthing/next-gen-gui at main · syncthing/syncthing · GitHub

5

I feel like just updating for updating’s sake without a plan and purpose for that UI beyond it, is not very well invested time. As in keeping up with this additional build process and all the deps coming with it is a large ongoing/lasting workload. And the UI isn’t in a state where it’s usable on it’s own. Nor is there anyone intending to invest the significant effort needed to make it useful. Resp. if there is someone (eventually), I have my doubts that it will gain that person a lot to start from this. Both because getting into an existing code-base is always quite an effort in itself, and also because that person might prefer some other tech/tooling.

6

It’s not quite updating just for the sake of it. As I tried to explain, building it will only get harder with time if we’re still stuck on the ancient versions. Like we are basically in a dead-end with the old GUI now, it will never be updated incrementally again, but would need to be rewritten from scratch.

The tech-ui was developed in 2020, integrated into the main repo (and therefore distributed with Syncthing) since 2021, so putting in the effort to make it easily buildable again 3~4 years later doesn’t seem like a lot of wasted effort. I’d like to get it into a usable state, where our CI makes it easy to test the thing when we’re making changes to the API at least. We don’t need to keep updating it regularly without new feature development. But right now it’s really just bit-rotted.

I’d think it might not be the “next-generation GUI” as the name suggests, but it is still useful on its own, for status display only. And maybe some of it can be used in the future and the more modern the code base looks, the more likely it will attract developers with the right background IMO.

If however we decide that it’s not going anywhere, then removing it from the main repo back into a separate one would make more sense I think. Instead of the --with-next-gen-gui switch, our build could then just gain an option to import a given folder into the statically linked GUI assets. That would then allow pulling in a fully built release version of whatever comes from a different GUI development repository, without resorting to STGUIASSETS and loading it from somewhere else at runtime.

7

That mostly matches what I think and tried to express, except that I don’t believe that having that UI technically up-to-date makes us materially more attractive to potential contributors over just having an archive of it. How useful the UI is for users I really can’t judge, I am a set-and-forget user. Sorry for using the charged expression “just for the sake of it”, I didn’t want to say you didn’t think or explain why you want to do it, I only wanted to focus on the (opinionated of course) point that updating provides little rewards, while being a lot of work.

8

I myself can only think of two cases:

  1. For those with an enormous number of folders (e.g. thousand or more), where the normal GUI struggles to operate.
  2. For those that want to use it only to monitor their Syncthing state with no risk of messing anything up (as the “next-gen-ui” in the current state is basically “view-only”).
1 Like
9

I think that would be generally useful. I’m wondering whether I could use bits of the mobile UI developed for Syncthing Tray on Android also within a web browser (as Qt supports web assembly). (I’m currently focusing on Android but at some point this might be worth an experiment.)

1 Like