Implementation of a no-JS searx-space

[glanham-jr]

Wanted to move the conversation from #9 into a dedicated thread, since implementation details don't seem necessary on the issue thread.

First, I'd like to review some technology choices we can use. Then, after having some agreement on the technology, I'd like to write a high level design of how I'd propose to work with the technology chosen + a rollout plan (if we want to go 100% new site, or have both sites running at the same time, we can discuss). After that, I'd try to start a prototype.

To review, dalf has provided an initial investigation on some possible technologies for frameworks.

Disclamer: I'm not a front dev, I'm may be wrong.

After investigation:
Jinja2: it will work expect if we want to sort / filter the list, choose the response time between (total, server, load) time, we will end up to reinvent the wheel.
vuejs SSR requires a node server.
NuxJS produces some huge javascript files.
preact with the prerenderUrls option seems to produce small output, working html page with JS disabled.

So:
preact seems to be a good option.
the other option:
one really simple output html + css nothing else.
another output with more features. In this case js can be mandatory.
requires more work since there are two versions.

Along with this, I've provided a suggestion for the technologies to choose.

I would believe that going with a Django Python server with server side rendered pages keeps the most flexibility. With that, I'd like to try to use django-distill which will let us generate a static site with some additional configuration. If we realize that the static site is not the way to go for some new features, we can strip it out and we still have the project set up for creating pages on the fly.

I think the two main benefits of using Django + Django Distill is that more of the code lives closer to Python (which seems to be the focused language of the overall project), and that we can likely omit using any JavaScript framework from the project. I see many benefits of reducing 3rd party client side code: will let us easily write JS that is LibreJS compatible, remove reduce attack surface of introducing possible errors and auditing imported source code, and also allow users to audit our source code with higher confidence.

The downside is that this will involve more up-front development work, as we will need to convert the site to work with Django Templates. But I also don't think the lift is huge - there are a total of 4 tables we need to populate, and these have not significantly changed over the years from what I've seen.

Some more things to consider is the current backlog of issues. Whatever is chosen, it should not add any additional friction in resolving issues. Ideally, these issues should become more approachable and easier to fix/update/maintain.

Finally, in my opinion, the goal is not to change the current design of the site to the extend that we can populate a no-JS site. We should try to maintain almost the same level of UI/UX. After migration to the new technology, then we can consider making more changes. However, a complete re-design + new technology framework is just a complete re-write at that point.

[glanham-jr]

Here is some more analysis from another standpoint

Metric	Django Distill Static Generation	Django Server Side Rendering
Serving Site Pages	Serve plain HTML/CSS/JS files	Requires Python + Django Running
Updating the site with new searx stat info	Need to regenerate HTML/CSS/JS files on a periodic job	Django fills HTML templates, no need to restart server
Filter Tables	Can only be done via JS, or we need to generate different pages for different filters (possible but cumbersome?)	Can be JS + create specific endpoints / parameters to return filtered results, allowing non-JS users to get filtering capability
Searx Stats Caching	n/a - done at Site Generation	Should cache in-memory (as its done today) + use HTTP caching with Django Caching
Frameworks	Django + Django Distill	Django
Points of Failure	HTTP Server + Site Generation Job	Python Server

With this, I'd actually say lets ditch the idea of Django Distill, and just use Django Server Side rendering and cache the results. Don't think there is a huge benefit to static generation unless there are some strict limiting requirements on the server I'm not aware of.