GNU bug report logs - #69132
[ELPA] Remove jQuery from elpa.gnu.org

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 69132 in the body.
You can then email your comments to 69132 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: bug-gnu-emacs <at> gnu.org
Subject: [ELPA] Remove jQuery from elpa.gnu.org
Date: Wed, 14 Feb 2024 19:41:50 +0000

[Message part 1 (text/plain, inline)]

I was recently surprised to see that elpa.gnu.org uses a jQuery library,
where it really isn't necessary.  Re-implementing the same functionality
can be done in a few more lines of plain Javascript, without the need
for any minified code.  Tested with relatively recent versions of
Firefox and Chromium, so perhaps it would be nice if someone with an
older browser could check if I didn't make any bold assumptions. 

[0001-Reimplement-search-without-jQuery.patch (text/x-patch, attachment)]

[0001-Update-HTML-generation-for-new-filter-implementation.patch (text/x-patch, attachment)]

Message #8 received at 69132 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 69132 <at> debbugs.gnu.org
Subject: Re: bug#69132: [ELPA] Remove jQuery from elpa.gnu.org
Date: Wed, 14 Feb 2024 18:05:47 -0500

> I was recently surprised to see that elpa.gnu.org uses a jQuery library,
> where it really isn't necessary.  Re-implementing the same functionality
> can be done in a few more lines of plain Javascript, without the need
> for any minified code.  Tested with relatively recent versions of
> Firefox and Chromium, so perhaps it would be nice if someone with an
> older browser could check if I didn't make any bold assumptions. 

Works for me, but I'm not using an "older browser" 🙁

> diff --git a/html/javascript/package-search.js b/html/javascript/package-search.js
> index 47134045eb..92f29703a3 100644
> --- a/html/javascript/package-search.js
> +++ b/html/javascript/package-search.js
> @@ -1,6 +1,35 @@
> -$(document).ready(function() {
> -	$('table').filterTable({
> -		label: '',
> -		placeholder: 'Search packages...'
> -	});
> +window.addEventListener("load", function (event) {
> +	const table = document.getElementById("packages");
> +
> +	const search = document.createElement("input");
> +	search.setAttribute("placeholder", "Search packages...");
> +	search.setAttribute("type", "search");
[...]

I know very little about Javascript, but I'm curious: can't we add the
`input` element directly in the HTML file, and skip those first 4 lines or so?

> diff --git a/html/layout.css b/html/layout.css
> index 4f5c50d393..434220f8c1 100644
> --- a/html/layout.css
> +++ b/html/layout.css

A rationale/description of this part of the change would be welcome.

> From 73a9335634f54b71e9723047f327cf782cfb7244 Mon Sep 17 00:00:00 2001
> From: Philip Kaludercic <philipk <at> posteo.net>
> Date: Wed, 14 Feb 2024 20:37:37 +0100
> Subject: [PATCH] Update HTML generation for new filter implementation
>
> ---
>  elpa-admin.el | 27 +++++++++++----------------
>  1 file changed, 11 insertions(+), 16 deletions(-)

Same here.


        Stefan

Message #11 received at 69132 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 69132 <at> debbugs.gnu.org
Subject: Re: bug#69132: [ELPA] Remove jQuery from elpa.gnu.org
Date: Thu, 15 Feb 2024 08:12:56 +0000

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> I was recently surprised to see that elpa.gnu.org uses a jQuery library,
>> where it really isn't necessary.  Re-implementing the same functionality
>> can be done in a few more lines of plain Javascript, without the need
>> for any minified code.  Tested with relatively recent versions of
>> Firefox and Chromium, so perhaps it would be nice if someone with an
>> older browser could check if I didn't make any bold assumptions. 
>
> Works for me, but I'm not using an "older browser" 🙁

I have a few older machines that I could try it out on.

>> diff --git a/html/javascript/package-search.js b/html/javascript/package-search.js
>> index 47134045eb..92f29703a3 100644
>> --- a/html/javascript/package-search.js
>> +++ b/html/javascript/package-search.js
>> @@ -1,6 +1,35 @@
>> -$(document).ready(function() {
>> -	$('table').filterTable({
>> -		label: '',
>> -		placeholder: 'Search packages...'
>> -	});
>> +window.addEventListener("load", function (event) {
>> +	const table = document.getElementById("packages");
>> +
>> +	const search = document.createElement("input");
>> +	search.setAttribute("placeholder", "Search packages...");
>> +	search.setAttribute("type", "search");
> [...]
>
> I know very little about Javascript, but I'm curious: can't we add the
> `input` element directly in the HTML file, and skip those first 4 lines or so?

Of course, I just replicated what the jquery plugin did.  I suppose the
idea was to not have a broken search field labelled "Search
packages...", if there is no Javascript to make it work in the first
place.

>> diff --git a/html/layout.css b/html/layout.css
>> index 4f5c50d393..434220f8c1 100644
>> --- a/html/layout.css
>> +++ b/html/layout.css
>
> A rationale/description of this part of the change would be welcome.
>
>> From 73a9335634f54b71e9723047f327cf782cfb7244 Mon Sep 17 00:00:00 2001
>> From: Philip Kaludercic <philipk <at> posteo.net>
>> Date: Wed, 14 Feb 2024 20:37:37 +0100
>> Subject: [PATCH] Update HTML generation for new filter implementation
>>
>> ---
>>  elpa-admin.el | 27 +++++++++++----------------
>>  1 file changed, 11 insertions(+), 16 deletions(-)
>
> Same here.

The idea is just to not use CSS classes to pinpoint specific Elements in
the DOM.  That is what IDs are for (ideally the "ID -> elements" map
should be injective).  I needed that to use document.getElementById in
the new script.

Should I update the commit messages to explain the change?

>
>         Stefan

Message #14 received at 69132 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 69132 <at> debbugs.gnu.org
Subject: Re: bug#69132: [ELPA] Remove jQuery from elpa.gnu.org
Date: Thu, 15 Feb 2024 11:07:59 +0000

[Message part 1 (text/plain, inline)]

Philip Kaludercic <philipk <at> posteo.net> writes:

> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>
>>> I was recently surprised to see that elpa.gnu.org uses a jQuery library,
>>> where it really isn't necessary.  Re-implementing the same functionality
>>> can be done in a few more lines of plain Javascript, without the need
>>> for any minified code.  Tested with relatively recent versions of
>>> Firefox and Chromium, so perhaps it would be nice if someone with an
>>> older browser could check if I didn't make any bold assumptions. 
>>
>> Works for me, but I'm not using an "older browser" 🙁
>
> I have a few older machines that I could try it out on.
>
>>> diff --git a/html/javascript/package-search.js b/html/javascript/package-search.js
>>> index 47134045eb..92f29703a3 100644
>>> --- a/html/javascript/package-search.js
>>> +++ b/html/javascript/package-search.js
>>> @@ -1,6 +1,35 @@
>>> -$(document).ready(function() {
>>> -	$('table').filterTable({
>>> -		label: '',
>>> -		placeholder: 'Search packages...'
>>> -	});
>>> +window.addEventListener("load", function (event) {
>>> +	const table = document.getElementById("packages");
>>> +
>>> +	const search = document.createElement("input");
>>> +	search.setAttribute("placeholder", "Search packages...");
>>> +	search.setAttribute("type", "search");
>> [...]
>>
>> I know very little about Javascript, but I'm curious: can't we add the
>> `input` element directly in the HTML file, and skip those first 4 lines or so?
>
> Of course, I just replicated what the jquery plugin did.  I suppose the
> idea was to not have a broken search field labelled "Search
> packages...", if there is no Javascript to make it work in the first
> place.
>
>>> diff --git a/html/layout.css b/html/layout.css
>>> index 4f5c50d393..434220f8c1 100644
>>> --- a/html/layout.css
>>> +++ b/html/layout.css
>>
>> A rationale/description of this part of the change would be welcome.
>>
>>> From 73a9335634f54b71e9723047f327cf782cfb7244 Mon Sep 17 00:00:00 2001
>>> From: Philip Kaludercic <philipk <at> posteo.net>
>>> Date: Wed, 14 Feb 2024 20:37:37 +0100
>>> Subject: [PATCH] Update HTML generation for new filter implementation
>>>
>>> ---
>>>  elpa-admin.el | 27 +++++++++++----------------
>>>  1 file changed, 11 insertions(+), 16 deletions(-)
>>
>> Same here.
>
> The idea is just to not use CSS classes to pinpoint specific Elements in
> the DOM.  That is what IDs are for (ideally the "ID -> elements" map
> should be injective).  I needed that to use document.getElementById in
> the new script.
>
> Should I update the commit messages to explain the change?

I have updated patches with a few more cases that I had initially
forgotten and split the one for the main branch into two:

[0001-Generate-HTML5-tags-instead-of-div-s-with-custom-cla.patch (text/x-patch, attachment)]

[0001-Use-more-HTML5-tags-instead-of-custom-CSS-classes.patch (text/x-patch, attachment)]

[0002-Replace-jQuery-filtertable-script-with-plain-Javascr.patch (text/x-patch, attachment)]

Message #17 received at 69132 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 69132 <at> debbugs.gnu.org
Subject: Re: bug#69132: [ELPA] Remove jQuery from elpa.gnu.org
Date: Thu, 15 Feb 2024 10:37:30 -0500

>> Works for me, but I'm not using an "older browser" 🙁
> I have a few older machines that I could try it out on.

I have plenty of old machines, but they're all running up-to-date
software 🙂

>> I know very little about Javascript, but I'm curious: can't we add the
>> `input` element directly in the HTML file, and skip those first 4 lines or so?
> Of course, I just replicated what the jquery plugin did.  I suppose
> the idea was to not have a broken search field labelled "Search
> packages...", if there is no Javascript to make it work in the
> first place.

FWIW this here user prefers to see the features that he's missing when
he's using a non-Javascript browser.  Anyway, it's only tangentially
related to your patch, so we can keep it for later.

Regarding your patch, I see you remove all the "reset" in the CSS.
I'm not really sure we did that, but it's also not described and
explained in the commit log of your patch.

> The idea is just to not use CSS classes to pinpoint specific Elements in
> the DOM.  That is what IDs are for (ideally the "ID -> elements" map
> should be injective).  I needed that to use document.getElementById in
> the new script.

> Should I update the commit messages to explain the change?

Yes, please.
While we're not picky about commit messages in (Non)GNU ELPA packages,
we should be careful to use good commit messages in the `main` (and
`elpa-admin`) branches.  Even more so for non-ELisp files since we can't
assume familiarity.


        Stefan

Message #20 received at 69132 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Philip Kaludercic <philipk <at> posteo.net>
Cc: 69132 <at> debbugs.gnu.org
Subject: Re: bug#69132: [ELPA] Remove jQuery from elpa.gnu.org
Date: Sat, 17 Feb 2024 13:25:18 -0500

Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> gnu.org> writes:

>>> Works for me, but I'm not using an "older browser" 🙁
>> I have a few older machines that I could try it out on.
>
> I have plenty of old machines, but they're all running up-to-date
> software 🙂

It's not the end of the world if this minor feature won't work correctly
on some older browsers, I think.

Message #23 received at 69132 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Philip Kaludercic <philipk <at> posteo.net>
Cc: 69132 <at> debbugs.gnu.org
Subject: Re: bug#69132: [ELPA] Remove jQuery from elpa.gnu.org
Date: Sat, 17 Feb 2024 22:57:47 +0200

On 15/02/2024 17:37, Stefan Monnier via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
> Regarding your patch, I see you remove all the "reset" in the CSS.
> I'm not really sure we did that, but it's also not described and
> explained in the commit log of your patch.

AFAIR, CSS reset is a means to equalize the default looks of the basic 
elements between different browsers.

Message #26 received at 69132 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Philip Kaludercic <philipk <at> posteo.net>, 69132 <at> debbugs.gnu.org
Subject: Re: bug#69132: [ELPA] Remove jQuery from elpa.gnu.org
Date: Sat, 17 Feb 2024 16:04:42 -0500

>> Regarding your patch, I see you remove all the "reset" in the CSS.
>> I'm not really sure we did that, but it's also not described and
>> explained in the commit log of your patch.
> AFAIR, CSS reset is a means to equalize the default looks of the basic
> elements between different browsers.

But was it just an arbitrary choice, or was there a particular reason
for it?


        Stefan

Message #29 received at 69132 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Philip Kaludercic <philipk <at> posteo.net>, 69132 <at> debbugs.gnu.org
Subject: Re: bug#69132: [ELPA] Remove jQuery from elpa.gnu.org
Date: Sun, 18 Feb 2024 00:26:57 +0200

On 17/02/2024 23:04, Stefan Monnier wrote:
>>> Regarding your patch, I see you remove all the "reset" in the CSS.
>>> I'm not really sure we did that, but it's also not described and
>>> explained in the commit log of your patch.
>> AFAIR, CSS reset is a means to equalize the default looks of the basic
>> elements between different browsers.
> But was it just an arbitrary choice, or was there a particular reason
> for it?

Not sure I understand the question. When you start from a CSS reset 
(which creates a bare-bones look), you more or less test in one browser 
and know how the website looks in others. Modulo engine bugs, of course.

Otherwise, to make the website look identical across browser, you have 
to make sure to enumerate all disparities in your own styles.

Message #32 received at 69132 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Philip Kaludercic <philipk <at> posteo.net>, 69132 <at> debbugs.gnu.org
Subject: Re: bug#69132: [ELPA] Remove jQuery from elpa.gnu.org
Date: Sat, 17 Feb 2024 17:44:33 -0500

>>>> Regarding your patch, I see you remove all the "reset" in the CSS.
>>>> I'm not really sure we did that, but it's also not described and
>>>> explained in the commit log of your patch.
>>> AFAIR, CSS reset is a means to equalize the default looks of the basic
>>> elements between different browsers.
>> But was it just an arbitrary choice, or was there a particular reason
>> for it?
>
> Not sure I understand the question. When you start from a CSS reset (which
> creates a bare-bones look), you more or less test in one browser and know
> how the website looks in others. Modulo engine bugs, of course.
>
> Otherwise, to make the website look identical across browser, you have to
> make sure to enumerate all disparities in your own styles.

But is there a reason we want it to look identical in all browsers?


        Stefan

Message #35 received at 69132 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Philip Kaludercic <philipk <at> posteo.net>, 69132 <at> debbugs.gnu.org
Subject: Re: bug#69132: [ELPA] Remove jQuery from elpa.gnu.org
Date: Sun, 18 Feb 2024 00:49:56 +0200

On 18/02/2024 00:44, Stefan Monnier wrote:
>>>>> Regarding your patch, I see you remove all the "reset" in the CSS.
>>>>> I'm not really sure we did that, but it's also not described and
>>>>> explained in the commit log of your patch.
>>>> AFAIR, CSS reset is a means to equalize the default looks of the basic
>>>> elements between different browsers.
>>> But was it just an arbitrary choice, or was there a particular reason
>>> for it?
>> Not sure I understand the question. When you start from a CSS reset (which
>> creates a bare-bones look), you more or less test in one browser and know
>> how the website looks in others. Modulo engine bugs, of course.
>>
>> Otherwise, to make the website look identical across browser, you have to
>> make sure to enumerate all disparities in your own styles.
> But is there a reason we want it to look identical in all browsers?

The end goal of a graphical design is usually a particular look.

A handful of minor deviations would work against that.

Message #38 received at 69132 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: philipk <at> posteo.net, 69132 <at> debbugs.gnu.org
Subject: Re: bug#69132: [ELPA] Remove jQuery from elpa.gnu.org
Date: Sat, 17 Feb 2024 22:28:38 -0500

[[[ 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. ]]]

There is no special harm in using jquery.  It is free software,
However, can we make elpa.gnu.org use NO Javascript?
That would be better.

-- 
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)

Message #41 received at 69132 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Philip Kaludercic <philipk <at> posteo.net>, 69132 <at> debbugs.gnu.org
Subject: Re: bug#69132: [ELPA] Remove jQuery from elpa.gnu.org
Date: Sat, 17 Feb 2024 23:05:13 -0500

>> But is there a reason we want it to look identical in all browsers?
> The end goal of a graphical design is usually a particular look.
> A handful of minor deviations would work against that.

The thing I hate most about the WWW is that it's running on *my*
computer but it's completely under the control of the web site.

So I don't see why we should consider obtaining "a particular look" to
be a good reason for doing a reset.

A good reason would be if without a reset the page can sometimes be
illegible, or something like that.


        Stefan

Message #44 received at 69132 <at> debbugs.gnu.org (full text, mbox):

From: Corwin Brust <corwin <at> bru.st>
To: rms <at> gnu.org
Cc: philipk <at> posteo.net, 69132 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#69132: [ELPA] Remove jQuery from elpa.gnu.org
Date: Sat, 17 Feb 2024 22:07:56 -0600

On Sat, Feb 17, 2024 at 9:28 PM Richard Stallman <rms <at> gnu.org> wrote:
>
> [[[ 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. ]]]
>
> There is no special harm in using jquery.  It is free software,
> However, can we make elpa.gnu.org use NO Javascript?
> That would be better.
>

In essence: No, it's not possible.

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.   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.  Threeish paragraphs on
that and the fine one back to OPs point, I think.

Currently the websites for the ELPAs provide the ability to filter the
full package list that is displayed initially when (e.g.) this page
loads:

As stated: I think it is *not* possible to perform this type of
"client-side" search without using Javascript.  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 (and way, way harder for them to change it, for
themselves).

The javascript must be sent to the user-agent to be evaluated, after
all.  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.  Using these it is often possible to redefine functions
and such before (e.g.) pressing a search button.

At present, users who don't allow javascript execution must use the
browser's search-within-page functions then iterate the results, which
is just what I typically do when I'm looking for something with the
`list-packages' UI, so it should be familiar even to those not using
an in-emacs browser such as eww.

So, I think the status quo is fine, notwithstanding removing jquery.
In that regard, I think the argument was we don't use it enough
considering it's a fairly big javascript library to send to every user
that loads the page; given I've understood properly, I do agree.

Message #47 received at 69132 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Corwin Brust <corwin <at> bru.st>
Cc: philipk <at> posteo.net, 69132 <at> debbugs.gnu.org, rms <at> gnu.org
Subject: Re: bug#69132: [ELPA] Remove jQuery from elpa.gnu.org
Date: Sat, 17 Feb 2024 23:20:05 -0500

>> There is no special harm in using jquery.  It is free software,
>> However, can we make elpa.gnu.org use NO Javascript?
>> That would be better.
> In essence: No, it's not possible.

Indeed.  In theory it's possible, but it'd be such a large amount of
work for us (plus extra work for elpa.gnu.org) that it's not worth the
trouble.  In contrast, the Javascript solution is really simple
and elegant.


        Stefan

Message #50 received at 69132 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Philip Kaludercic <philipk <at> posteo.net>, 69132 <at> debbugs.gnu.org
Subject: Re: bug#69132: [ELPA] Remove jQuery from elpa.gnu.org
Date: Sun, 18 Feb 2024 14:14:26 +0200

On 18/02/2024 06:05, Stefan Monnier wrote:
>>> But is there a reason we want it to look identical in all browsers?
>> The end goal of a graphical design is usually a particular look.
>> A handful of minor deviations would work against that.
> The thing I hate most about the WWW is that it's running on*my*
> computer but it's completely under the control of the web site.

I can see where you're coming from.

Most browsers allow user styles to override a web page. E.g. the Stylus 
extension (works in Firefox and Chromium). There's also userStyles.css.

A good CSS reset would not get in the way of those, if only because it's 
written not to conflict with developer's CSS. Rules with !important will 
have higher priority.

Message #53 received at 69132 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Philip Kaludercic <philipk <at> posteo.net>, 69132 <at> debbugs.gnu.org
Subject: Re: bug#69132: [ELPA] Remove jQuery from elpa.gnu.org
Date: Sun, 18 Feb 2024 09:13:17 -0500

>>>> But is there a reason we want it to look identical in all browsers?
>>> The end goal of a graphical design is usually a particular look.
>>> A handful of minor deviations would work against that.
>> The thing I hate most about the WWW is that it's running on*my*
>> computer but it's completely under the control of the web site.
>
> I can see where you're coming from.
>
> Most browsers allow user styles to override a web page. E.g. the Stylus
> extension (works in Firefox and Chromium). There's also userStyles.css.
>
> A good CSS reset would not get in the way of those, if only because it's
>   written not to conflict with developer's CSS. Rules with !important will
>   have higher priority.

I understand that you can circumvent such resets, but if all web-pages
need to start with a reset, then why don't all browsers start in the same
default CSS state?

In my world view, we should focus on the semantic content of our pages
to let the renderer decide how best to present it.

In any case, it seems that the only reason we currently have a reset is
so it looks the same everywhere.  If that's the case, I'm perfectly OK
with Philip's removal of the reset, since I don't think we should aim
for it to look the same everywhere (I'm pretty sure it won't look the
same on paper or in audio or in braille as it does on my screen anyway).


        Stefan

Message #56 received at 69132 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Philip Kaludercic <philipk <at> posteo.net>, 69132 <at> debbugs.gnu.org
Subject: Re: bug#69132: [ELPA] Remove jQuery from elpa.gnu.org
Date: Sun, 18 Feb 2024 16:24:21 +0200

On 18/02/2024 16:13, Stefan Monnier wrote:

> I understand that you can circumvent such resets, but if all web-pages
> need to start with a reset, then why don't all browsers start in the same
> default CSS state?

Same reason why we don't just have one browser that's developed for the 
good of everyone and satisfies everyone's wishes.

> In my world view, we should focus on the semantic content of our pages
> to let the renderer decide how best to present it.

Then you wouldn't have any CSS rules pertaining to size or color.

> In any case, it seems that the only reason we currently have a reset is
> so it looks the same everywhere.  If that's the case, I'm perfectly OK
> with Philip's removal of the reset, since I don't think we should aim
> for it to look the same everywhere (I'm pretty sure it won't look the
> same on paper or in audio or in braille as it does on my screen anyway).

Paper is a different medium. But there are dedicated selectors for it, 
if we were interested in defining that look.

Message #59 received at 69132 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Philip Kaludercic <philipk <at> posteo.net>, 69132 <at> debbugs.gnu.org
Subject: Re: bug#69132: [ELPA] Remove jQuery from elpa.gnu.org
Date: Sun, 18 Feb 2024 09:37:58 -0500

>> In any case, it seems that the only reason we currently have a reset is
>> so it looks the same everywhere.  If that's the case, I'm perfectly OK
>> with Philip's removal of the reset, since I don't think we should aim
>> for it to look the same everywhere (I'm pretty sure it won't look the
>> same on paper or in audio or in braille as it does on my screen anyway).
>
> Paper is a different medium. But there are dedicated selectors for it, if we
> were interested in defining that look.

It you're selecting for different mediums, then you're specifying
presentation, not semantics.


        Stefan

Message #62 received at 69132 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Philip Kaludercic <philipk <at> posteo.net>, 69132 <at> debbugs.gnu.org
Subject: Re: bug#69132: [ELPA] Remove jQuery from elpa.gnu.org
Date: Sun, 18 Feb 2024 16:38:58 +0200

On 18/02/2024 16:37, Stefan Monnier wrote:
>>> In any case, it seems that the only reason we currently have a reset is
>>> so it looks the same everywhere.  If that's the case, I'm perfectly OK
>>> with Philip's removal of the reset, since I don't think we should aim
>>> for it to look the same everywhere (I'm pretty sure it won't look the
>>> same on paper or in audio or in braille as it does on my screen anyway).
>> Paper is a different medium. But there are dedicated selectors for it, if we
>> were interested in defining that look.
> It you're selecting for different mediums, then you're specifying
> presentation, not semantics.

That's right.

HTML is for semantics, CSS is for presentation.

Message #65 received at 69132 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Richard Stallman <rms <at> gnu.org>
Cc: 69132 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#69132: [ELPA] Remove jQuery from elpa.gnu.org
Date: Sun, 18 Feb 2024 15:07:54 +0000

Richard Stallman <rms <at> gnu.org> writes:

> [[[ 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. ]]]
>
> There is no special harm in using jquery.  

What I didn't like about it is that it is two large, "minified"
(i.e. obfuscated) files that provide much more than is necessary for
this simple feature:

  https://elpa.gnu.org/javascript/jquery.min.js
  https://elpa.gnu.org/javascript/jquery.filtertable.min.js

>                                            It is free software,
> However, can we make elpa.gnu.org use NO Javascript?
> That would be better.

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.

Corwin Brust <corwin <at> bru.st> writes:


[...]

> So, I think the status quo is fine, notwithstanding removing jquery.
> In that regard, I think the argument was we don't use it enough
> considering it's a fairly big javascript library to send to every user
> that loads the page; given I've understood properly, I do agree.

So to be clear, you don't object to my jQuery replacement?

-- 
Philip Kaludercic

Message #68 received at 69132 <at> debbugs.gnu.org (full text, mbox):

From: Corwin Brust <corwin <at> bru.st>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 69132 <at> debbugs.gnu.org, Richard Stallman <rms <at> gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#69132: [ELPA] Remove jQuery from elpa.gnu.org
Date: Sun, 18 Feb 2024 12:19:43 -0600

On Sun, Feb 18, 2024 at 9:07 AM Philip Kaludercic <philipk <at> posteo.net> wrote:
> So to be clear, you don't object to my jQuery replacement?
>

No, I do not.  It's a good suggestion and may help low-bandwidth users
get more use from ELPA web.

Message #71 received at 69132 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Corwin Brust <corwin <at> bru.st>
Cc: philipk <at> posteo.net, 69132 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#69132: [ELPA] Remove jQuery from elpa.gnu.org
Date: Tue, 20 Feb 2024 21:56:24 -0500

[[[ 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)

Message #74 received at 69132 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Richard Stallman <rms <at> gnu.org>
Cc: Corwin Brust <corwin <at> bru.st>, 69132 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#69132: [ELPA] Remove jQuery from elpa.gnu.org
Date: Thu, 22 Feb 2024 12:00:52 +0000

Richard Stallman <rms <at> gnu.org> writes:

>   > 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.

In this case, both options would be overkill.  The search functionality
does little more than just hiding a few elements from a table.  In
practice, it don't offer much more than using the built-in C-f search
functionality, that every browser provides.

[...]

> 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.

ELPA already has a format for listing packages in an archive, and just
like with browsers, it wouldn't really provide anything that M-x
list-packages and C-s doesn't already do.

> (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.

We should be talking about the same code; I am not sure what you mean by
instructing users to install the code themselves?  Are you talking about
user-scripts?

> 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.

Message #79 received at 69132-done <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: 69132-done <at> debbugs.gnu.org
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#69132: [ELPA] Remove jQuery from elpa.gnu.org
Date: Sat, 24 Feb 2024 10:03:34 +0000

Philip Kaludercic <philipk <at> posteo.net> writes:

> I was recently surprised to see that elpa.gnu.org uses a jQuery library,
> where it really isn't necessary.  Re-implementing the same functionality
> can be done in a few more lines of plain Javascript, without the need
> for any minified code.  Tested with relatively recent versions of
> Firefox and Chromium, so perhaps it would be nice if someone with an
> older browser could check if I didn't make any bold assumptions. 

I have pushed updated versions of these patches to elpa.git, does the
same have to be done for nongnu.git?

Message #82 received at 69132 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: corwin <at> bru.st, 69132 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#69132: [ELPA] Remove jQuery from elpa.gnu.org
Date: Sat, 24 Feb 2024 22:13:47 -0500

[[[ 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. ]]]

  > > 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.

  > In this case, both options would be overkill.

Do you mean, they would be more complex than is _technically_
necessary?  I believe you, but this issue is about a choice that is
mainly moral, not technical.  This moral issue is about showing
leadership in avoiding Javascript (even free Javascript) when that is
possible.

  >   The search functionality
  > does little more than just hiding a few elements from a table.  In
  > practice, it don't offer much more than using the built-in C-f search
  > functionality, that every browser provides.

That browser feature does not use Javascript sent by the server.  All
of the code for the browser search feature is installed by the user,
who can choose which browser version to install.  So it does not raise
this moral issue at all.

Do you see why Javascript raises a distinct moral issue?

  > We should be talking about the same code; I am not sure what you mean by
  > instructing users to install the code themselves?  Are you talking about
  > user-scripts?

Yes, that's the term I should have used.  Thanks.

This issue is about who controls what code you run -- not about what
the code _does_.  The Javascript code, sent by the web site, gives
that site control.  The very same code, installed by the user, does
not.

But if the code is simple, perhaps the API is not worth the trouble.


-- 
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)

Message #85 received at 69132 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: 69132 <at> debbugs.gnu.org
Cc: philipk <at> posteo.net
Subject: Re: bug#69132: [ELPA] Remove jQuery from elpa.gnu.org
Date: Sun, 25 Feb 2024 11:06:19 +0100

Philip Kaludercic <philipk <at> posteo.net> writes:

Hello Philip!

>> I was recently surprised to see that elpa.gnu.org uses a jQuery library,
>> where it really isn't necessary.  Re-implementing the same functionality
>> can be done in a few more lines of plain Javascript, without the need
>> for any minified code.  Tested with relatively recent versions of
>> Firefox and Chromium, so perhaps it would be nice if someone with an
>> older browser could check if I didn't make any bold assumptions. 
>
> I have pushed updated versions of these patches to elpa.git, does the
> same have to be done for nongnu.git?

I just tried the updated website on elpa.gnu.org and I observed the
following issues:

- The filtering feels less responsive. I don't know where the problem
  lies, maybe Jquery uses some kind of debouncing, a more efficient
  matching or a more efficient way to manipulate the DOM?

- When deleting the input string after filtering, such that the input
  field becomes empty again, all packages are highlighted.

- The jslicense.html website has not been updated yet. Maybe this
  website is also not necessary given that no third-party packages are
  used?

Daniel

Message #88 received at 69132 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 69132 <at> debbugs.gnu.org
Subject: Re: bug#69132: [ELPA] Remove jQuery from elpa.gnu.org
Date: Sun, 25 Feb 2024 10:44:45 +0000

[Message part 1 (text/plain, inline)]

Daniel Mendler <mail <at> daniel-mendler.de> writes:

> Philip Kaludercic <philipk <at> posteo.net> writes:
>
> Hello Philip!
>
>>> I was recently surprised to see that elpa.gnu.org uses a jQuery library,
>>> where it really isn't necessary.  Re-implementing the same functionality
>>> can be done in a few more lines of plain Javascript, without the need
>>> for any minified code.  Tested with relatively recent versions of
>>> Firefox and Chromium, so perhaps it would be nice if someone with an
>>> older browser could check if I didn't make any bold assumptions. 
>>
>> I have pushed updated versions of these patches to elpa.git, does the
>> same have to be done for nongnu.git?
>
> I just tried the updated website on elpa.gnu.org and I observed the
> following issues:
>
> - The filtering feels less responsive. I don't know where the problem
>   lies, maybe Jquery uses some kind of debouncing, a more efficient
>   matching or a more efficient way to manipulate the DOM?

According to the profiler, most of the CPU time went to reflowing CSS.
It appears that if I move around the classList manipulation calls, then
the performance improves.

> - When deleting the input string after filtering, such that the input
>   field becomes empty again, all packages are highlighted.

Apparently the issue here is that while an empty string is false-y in
Javascript

  "" ? true : false => false

an empty regular expression is true-thy

  new RegExp("") ? true : false => false

I updated my patch before pushing it to use RegExp for performance
reasons.  Due to the above, my "empty-input" check breaks, and the table
fields are all highlighted, since the empty regular expression matches
every string.  That can be easily fixed.

A different issue I noticed is that if I input a malformed regular
expression, say "+", the site freezes due to an exception.  I cannot
find any simple analogue for `regexp-quote', but there is a .includes()
method on strings that could be used instead (appears to be well
supported).

> - The jslicense.html website has not been updated yet. Maybe this
>   website is also not necessary given that no third-party packages are
>   used?

The file has been changed[0], perhaps it also has to be manually updated.

[0] https://git.savannah.gnu.org/cgit/emacs/elpa.git/diff/html/jslicense.html?id=4c73cd608e8da3e614aabc083e2a6078c1e631bb

> Daniel

In effect, I propose these changes:

[Message part 2 (text/plain, inline)]

diff --git a/html/javascript/package-search.js b/html/javascript/package-search.js
index e603853eda..c690632938 100644
--- a/html/javascript/package-search.js
+++ b/html/javascript/package-search.js
@@ -21,27 +21,38 @@ window.addEventListener("load", function (event) {
 	search.setAttribute("placeholder", "Search packages...");
 	search.setAttribute("type", "search");
 	search.addEventListener("input", function(event) {
-		const query = new RegExp(event.target.value, "i");
+		let query = event.target.value;
+		
+		if (!query) { // empty input
+			for (let i = 1; i < table.rows.length; i++) {
+				const row = table.rows.item(i);
+				const name = row.childNodes.item(0);
+				const desc = row.childNodes.item(2);
+				name.classList.remove("alt");
+				desc.classList.remove("alt");
+				row.classList.remove("invisible");
+			}
+			return;
+		}
 
+		query = query.toLowerCase();
 		for (let i = 1; i < table.rows.length; i++) {
 			const row = table.rows.item(i);
-			row.classList.remove("invisible");
 
 			const name = row.childNodes.item(0);
-			const name_matches = name.innerText.match(query);
+			const name_matches = name.innerText.toLowerCase().includes(query);
 			name.classList.remove("alt");
 
 			const desc = row.childNodes.item(2);
-			const desc_matches = desc.innerText.match(query);
+			const desc_matches = desc.innerText.toLowerCase().includes(query);
 			desc.classList.remove("alt");
 
-			if (query) { // avoid matching the empty string
-				if (name_matches || desc_matches) {
-					if (name_matches) { name.classList.add("alt"); }
-					if (desc_matches) { desc.classList.add("alt"); }
-				} else {
-					row.classList.add("invisible");
-				}
+			if (name_matches || desc_matches) {
+				row.classList.remove("invisible");
+				if (name_matches) { name.classList.add("alt"); }
+				if (desc_matches) { desc.classList.add("alt"); }
+			} else {
+				row.classList.add("invisible");
 			}
 		}
 	});

[Message part 3 (text/plain, inline)]

-- 
Philip Kaludercic

Message #91 received at 69132 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Richard Stallman <rms <at> gnu.org>
Cc: corwin <at> bru.st, 69132 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#69132: [ELPA] Remove jQuery from elpa.gnu.org
Date: Sun, 25 Feb 2024 10:55:58 +0000

Richard Stallman <rms <at> gnu.org> writes:

> [[[ 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. ]]]
>
>   > > 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.
>
>   > In this case, both options would be overkill.
>
> Do you mean, they would be more complex than is _technically_
> necessary?  I believe you, but this issue is about a choice that is
> mainly moral, not technical.  This moral issue is about showing
> leadership in avoiding Javascript (even free Javascript) when that is
> possible.

No, I'd say functionally.  The would work just as well without
Javascript, but if available it provides a minor quality-of-life
enchantment -- just as Javascript was intended to be used.

>   >   The search functionality
>   > does little more than just hiding a few elements from a table.  In
>   > practice, it don't offer much more than using the built-in C-f search
>   > functionality, that every browser provides.
>
> That browser feature does not use Javascript sent by the server.  All
> of the code for the browser search feature is installed by the user,
> who can choose which browser version to install.  So it does not raise
> this moral issue at all.
>
> Do you see why Javascript raises a distinct moral issue?

No, but I don't think we have to discuss this here.

>   > We should be talking about the same code; I am not sure what you mean by
>   > instructing users to install the code themselves?  Are you talking about
>   > user-scripts?
>
> Yes, that's the term I should have used.  Thanks.
>
> This issue is about who controls what code you run -- not about what
> the code _does_.  The Javascript code, sent by the web site, gives
> that site control.  The very same code, installed by the user, does
> not.
>
> But if the code is simple, perhaps the API is not worth the trouble.

I think it is absurd to talk about "control" in this case, as the
functionality that we are discussing barley qualifies as a program.  If
elpa.gnu.org would depend on Javascript to even display a single page,
then I would agree with you that this would be a problem, but what we
have here falls safely in the domain of progressive enchantment[0] and
graceful degradation[1], since everyone gets as much functionality as
their browser provides (which includes customised browsers, that disable
Javascript by default, as I do too), while making use of what the user
decides to enable.

[0] https://developer.mozilla.org/en-US/docs/Glossary/Progressive_Enhancement
[1] https://developer.mozilla.org/en-US/docs/Glossary/Graceful_degradation

-- 
Philip Kaludercic

Message #94 received at 69132 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Richard Stallman <rms <at> gnu.org>
Cc: Philip Kaludercic <philipk <at> posteo.net>, corwin <at> bru.st,
 69132 <at> debbugs.gnu.org
Subject: Re: bug#69132: [ELPA] Remove jQuery from elpa.gnu.org
Date: Sun, 25 Feb 2024 10:18:58 -0500

>   > > 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.
>
>   > In this case, both options would be overkill.
>
> Do you mean, they would be more complex than is _technically_
> necessary?  I believe you, but this issue is about a choice that is
> mainly moral, not technical.  This moral issue is about showing
> leadership in avoiding Javascript (even free Javascript) when that is
> possible.

It's funny that here you end up advocating for SaaSS: the users can very
easily do the filtering locally (using the small Javascript snippet we
now provide) but you're advocating for the replacement of this solution with
one that sends the work to the `elpa.gnu.org` server.

I'm not trying to play devil's advocate here.
The issue of having control over what happens in my web-browser is very
real, so I'm also weary of solutions that rely on the web server sending
me some Javascript to execute, but given the current technical
landscape, it does seem to be the best solution also for the end users
like us who want control.

I think that to do any better, we'd have to standardize such "lists that
one might want to filter" so that the filtering code could be provided
once and for all by the user's system (and (re)used on many different
web sites).


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.