bug#69132: [ELPA] Remove jQuery from elpa.gnu.org

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Given someone thought they'd use it, we could add an additional option
  > (radio button, or smth) that would case the search to happen on the
  > server instead of via client-side script.

In moral terms, we should avoid Javascript code entirely whenever
possible.  Avoiding it should be the default.

  >    That said, there are
  > several reasons I feel it would be tragic to /replace/ a client side
  > function with a server side one, in this case.

The word "tragic" is surely too strong.  It is rare that practical
inconveniences are so bad as to justify that word.  In computing we
are surrounded by injustices, by systems that do wrong to the users --
let's reserve the word "tragic" for them.

  > As stated: I think it is *not* possible to perform this type of
  > "client-side" search without using Javascript.

There are two fully moral ways to implement a search feature for a web
site.  One is to implement it inside the web server.  The other is to
communicate with a free program that the user has installed in per
computer, and could replace with any other.

When the server sends Javascript code to the user, even free
Javascript in the form of source code with comments, what normally
happens is that the browser runs the code that it was sent.  It is
possible for users to change that code, and even save their changed
versions, but it requires using obscure features and understanding a
language rarely used for anything but web development.  Also, this is
fragile -- if the site changes its search code, the patches are likely
to break.

  >   It would likely be
  > simple to create a search program on the web-server, however in this
  > case that actually makes it slightly harder for users to see the
  > search code involved

It is normal for servers to format and select data for presentation,
sometimes offering options about how to do it.  There is nothing wrong
with that.

  >   In fact, this often means a user can, in addition to viewing and
  > saving the sources, use the javascript console and other so-called
  > "developer tools".  Developer tools are provided in some form by a
  > variety of popular browsers such as Firefox and the Chromium line,
  > among others.

They can be useful if you know Javascript (I don't).  But it is always
fragile.  Site developers will change the layout of the contents and
change the Javascript code at the same time.  Users' saved patches
won't work after that.

If you patch Emacs, and the code in the next Emacs version is
different so your patch does not work in it, you can keep using your
patched old Emacs until you have time to rework the patch.  (Or
forever.)  But if the Javascript in a web page changes, along with its
data layout, there is normally no way to get the current data in the
old layout so your old patch will work.

We could overcome this wih a documented API that users could
optionally use for ELPA search.  It would provide the package list
data in a form convenient for programs.  Users could write their own
code, in Javascript or in some other language, to operate on the API
output to customize the search as they like.  This would provide the
benefit you call for, in an even more general way.

(Is there a semistandard web convention for specifying API versions so
you can say, "Give me this data in the format we used in June 2022"?)

Meanwhile, the rest of us, we who don't use that API, would not be
asked to run any code straight off the web server.

In a later message you said this:

  > As the entire functionality it provides is just an optional, superficial
  > enchantment (one that I almost never use), I don't think this is worth
  > pursuing.  All the ways I can imagine to achieve this would be less
  > convenient hacks.

Assuming you're talking about the same Javascript code, how about
directing users to install that code into their browsers themselves
(if they want this optional, superficial <what?>), and giving them a
link to it.

That would avoid the moral problem of Javascript sent implicitly to
browsers, and these few users would have only a little work to do to
set it up.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)