JavaScript free

[unixfox]

A JavaScript free version of the website would be great because in the Searx community it's pretty common to have users that doesn't enable JavaScript by default.
Moreover, Searx itself support searches without having JavaScript enabled and stats.searx.xyz display its results without having JavaScript enabled.

[return42]

A JavaScript free version of the website would be great because in the Searx community it's pretty common to have users that doesn't enable JavaScript by default.

I don't think so. I guess that most of the searx (end) users do not know how to disable Javascript in their browsers ... BTW nowadays it is hard to develop modern clients without JS .. we had the same discussion at the linux kernel development in 2016 when we converted the linux kernel documentation to the reST format. From the linux community only one votes for a non javascript solution .. but no one gives any contribution and at the end, this requirements dies.

To be clear; I prefer CSS solutions over JS, if I can avoid JS, I don't use JS .. but we should realistic and focus more on projects progress:

searx-stats2 is a diagnostic toll, sooner or later we will appreciate the little JS helpers by sorting and/or filtering the results in the client gui.

[unixfox]

The amount of users in the Searx community that disable JavaScript is quite superior to the overall amount of Internet users.
I have encountered quite a lot of people in the Searx & Privacy oriented communities that disable JavaScript by default because it's better for the privacy. It's not that hard to do, there are plenty of tutorials on the Internet and there is even a dedicated setting for that in Ublock Origin main settings page.
When JavaScript is disabled the amount of possible privacy abusive vectors is very highly reduced, that's mainly why I disabled JavaScript by default in uMatrix and I enable it only if the website start breaking.

Currently, searx-stats2 can be completely converted to a JavaScript free website. The results just need to be rendered on server side (like the actual stats.searx.xyz), the ability to filter is possible in pure CSS: https://nddt-webdevelopment.de/html-css/filter-html-table-without-javascript-just-css, sorting needs to be done in server side and finally the tooltip that is displayed when the user moves the mouse over an element is also possible in pure CSS: https://www.w3schools.com/css/css_tooltip.asp

If removing JavaScript is possible why not doing it? It just feels snappier, follow the same philosophy as Searx, make happy a part of the Privacy oriented community and reduce the amount of possible alteration of the searx-stats2 content because the policy script-src in the CSP can be set to none.

[dalf]

I will try to sum up my view point:

• The current main.js fall between two stools: it tries to follow "what you see is what you run" to make javascript acceptable ; but it ended up to huge ugly peace of js without the .vue files.
• the tooltip are displayed using CSS (but are created using js).
• javascript allows
  • to filter the instance and engines lists: for example when you filter the online instances, the engine list uses the filtered instance list, something not doable with pure css.
  • to sort the instance list : the UI is missing for now.
• There is a FIXME to replace vuejs code by Jinja2, but it will remove the filter and sort features (at least user won't be able to type inside the filter inputbox).
• Another path is server side rendering (or prerendering): javascript enhances the UI but it is not required. Note: searx already relies on uglify but not on webpack.
• Another path is a static page enhanced with CSS classes and Javascript: CSS can help for basic filtering, then js can enhance the UX but even links/w3m can display the HTML page.

Then there is this question : what are the user stories about this project ?

[unixfox]

Server side rendering is a good idea, at least having a page with the results (like the actual stats.searx.xyz) and if the visitor wants to sort/filter he will have to enable JS (a message is displayed to let it him know about that).

[return42]

if the visitor wants to sort/filter he will have to enable JS

This solution fits for both ... but also adds a lot of work & test. If someone is willing to take on this work, then it seems the best solution.

[dalf]

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.

[RokeJulianLockhart]

#9 (comment)

@unixfox, I disagree with any change that'll remove or degrade functionality or performance for privacy. I just use SearX because its ability to provide results from different search engines is brilliant. Those worried by that are usually able to self-host it themselves, anyway.

I'm all for JS if it makes development easier and the product better.

[glanham-jr]

Reading this issue, I think this is something I wouldn't mind trying to address as a project. Ideally, there should exist a non-JS enabled version of the site. My high-level plan of action would be what has already been mentioned - focus on server side rendering, then work with JS after a strong default has been completed.

[glanham-jr]

Also, the searx-space site is extremely simple. It boils down to 4 tables with filtering capabilities. Once the bulk of generation is handled by server side rendering, I don't really see a need to have an entire JavaScript framework dedicated to table filters.

[dalf]

@glanham-jr how do you want to implement that ? pre-rendered static pages ? a Python web server ? something else ?

[glanham-jr]

I was going create a separate discussion on different possibilities - but I can do so in this thread.

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.

[dalf]

I've opened the discussion for this project.

[glanham-jr]

Moved conversation to the following discussion: #196