From: Philip Kaludercic <philipk@posteo.net>
To: Richard Stallman <rms@gnu.org>
Cc: corwin@bru.st, 69132@debbugs.gnu.org, monnier@iro.umontreal.ca
Subject: bug#69132: [ELPA] Remove jQuery from elpa.gnu.org
Date: Sun, 25 Feb 2024 10:55:58 +0000 [thread overview]
Message-ID: <87msron77l.fsf@posteo.net> (raw)
In-Reply-To: <E1re4xX-0003fQ-Qn@fencepost.gnu.org> (Richard Stallman's message of "Sat, 24 Feb 2024 22:13:47 -0500")
Richard Stallman <rms@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
next prev parent reply other threads:[~2024-02-25 10:55 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-14 19:41 bug#69132: [ELPA] Remove jQuery from elpa.gnu.org Philip Kaludercic
2024-02-14 23:05 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-15 8:12 ` Philip Kaludercic
2024-02-15 11:07 ` Philip Kaludercic
2024-02-15 15:37 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-17 18:25 ` Stefan Kangas
2024-02-17 20:57 ` Dmitry Gutov
2024-02-17 21:04 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-17 22:26 ` Dmitry Gutov
2024-02-17 22:44 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-17 22:49 ` Dmitry Gutov
2024-02-18 4:05 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-18 12:14 ` Dmitry Gutov
2024-02-18 14:13 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-18 14:24 ` Dmitry Gutov
2024-02-18 14:37 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-18 14:38 ` Dmitry Gutov
2024-02-18 3:28 ` Richard Stallman
2024-02-18 4:07 ` Corwin Brust
2024-02-18 4:20 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-21 2:56 ` Richard Stallman
2024-02-22 12:00 ` Philip Kaludercic
2024-02-25 3:13 ` Richard Stallman
2024-02-25 10:55 ` Philip Kaludercic [this message]
2024-02-25 15:18 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-18 15:07 ` Philip Kaludercic
2024-02-18 18:19 ` Corwin Brust
2024-02-24 10:03 ` Philip Kaludercic
2024-02-25 10:06 ` Daniel Mendler via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-25 10:44 ` Philip Kaludercic
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87msron77l.fsf@posteo.net \
--to=philipk@posteo.net \
--cc=69132@debbugs.gnu.org \
--cc=corwin@bru.st \
--cc=monnier@iro.umontreal.ca \
--cc=rms@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.