Deep architectural change of the GUI (discussion)

[hannaeko]

I think I mentioned this briefly on a meeting, I am opening an issue so we have a place to discus it.

The feeling I have from working with on GUI for more than a year now is that how it is made (single page application, doing everything on the browser) make certain things hard to do:

• customization, since the GUI is "assembled" at compile time, changing the structure of the document, the scripts, or the style is not straightforward without rebuilding the GUI;
• in a similar way, since last release and even more going forward after next release, adding / updating translation is not possible to do without recompiling;
• changing the base url to run the GUI from a sub path require manual update of the release files, after each release;
• after #349 language choice based on browser preference will be harder and error prone.

To that we also need to add the work required to maintain the project alive by upgrading our dependencies for each release, which can take some effort.

I am wondering if we could consider moving to a "server based GUI", with a server that would do the rendering / HTTP routing of the GUI. This way I think we could solve some of the issues mentioned before:

• customization would be achieve by having templates, which are decoupled from our application, only changing the template without recompiling is possible;
• same thing for translation, our translation file could live separately from the server and be rendered when page are served, this allow for a user to modify the translation and simply point the server to the modified translation folder;
• the base url could be a configuration of the server, no need to change the source files;
• if we have a server we can correctly parse accept-language headers.

What are you thoughts on that?

@matsduf @mattias-p @pnax @tgreenx @marc-vanderwal

[matsduf]

@blacksponge, is this something for the F2F?

[hannaeko]

Yes I think we could discuss that there.