I'm adding here a note about something to consider in terms of pros/cons: accessibility. As for the most part we are archiving textual information, we really want it to be accessible for all users. Right now we go further than that, ensuring that the Web UI can be browser with a textual browser: so, for instance, w3m https://archive.softwareheritage.org/swh:1:cnt:c839dea9e8e6f0528b468214348fee8669b305b2 just works out of the box. I'm not up to date on what's the accessibility impact of current JS frameworks, nor that we should have as a requirement that the archive is browsable without JavaScript enabled (as per today's standards "browsable with free javascript" is probably good enough for us, and we have a curl-able API anyway), but accessibility per se is definitely going to be a requirement.

@zack Thanks for the input. I will start thinking about accessibility as well.
Many pages, including 'swh search', will not function as expected without enabling JS. So, I would say JS is integral.

The issue with the current JS code is, it interacts a lot with the DOM elements (Using JQuery) and makes things complicated to extend or bug fix.
The modern frameworks like react or vue provides us with a wrapper that is easier to interact with. This lets us manage the UI state inside a data structure. You change the value of a variable, and you get to change that in the screen.

So, I am dropping the idea of a full SWH JS client but still feel using a UI state manager would be a good idea. I still need to think a bit about this and will edit the ticket accordingly.
The basic idea is, we load all the data from the server using a python template engine, and manage its state and allow client side operations (like filter, sort etc) using JS.
This can be achieved by instantiating a JS (React/home made JS lib) app in every page load. I suppose it would be possible to provide user the same data, irrespective of their client, but can offer extra for those with JS enabled.

• This will also reduce the server load by reducing API hits for search or sort. I think that is not important at this moment at least.

This will also let us think in terms of reusable widgets. I am not sure how important that would be in our case, but couple of use-cases are

• we can make swh search or the origin browser a public widget, it can be integrated in any external website with just two lines of HTML code.
• Many UI elements are in fact the same kind in SWH (eg: folder/file raw, list view etc). Most this can be re-used inside the system. This will make it efficient and easy to manage.