directory-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FSD as a Git repository


From: Lorenzo L. Ancora
Subject: Re: FSD as a Git repository
Date: Tue, 20 Jul 2021 13:56:42 +0000
User-agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Firefox/78.0

The functionalities offered by JavaScript are not replaceable, there are no alternatives for public websites.

Unlike Adobe Flash and Java applets, JavaScript is part of the web standards and is always executed in a sandbox environment. JavaScript will not become obsolete, it will simply be updated as it has been until now; eventually, it will be simply replaced by a more advanced scripting language and the cycle will start again.

If a web developer uses JavaScript it means that it is necessary or that if they did without it the user experience would be worse; JavaScript is also required to implement advertising and statistics, without which most websites would not be able to offer free content and would not be able to personalize the user experience. The web without JavaScript is a web lacking interactivity, customization, and much less secure (e.g. banks need JavaScript to block brute force attacks and spoofing attempts). Also, without it many free online services would become paid, due to the workload moving from client machines to server ones.

The solution is not to convince people that "JavaScript is bad" but to educate them on the correct client-side implementation.

Il 20/07/21 11:15, Narcis Garcia ha scritto:
I run pages' JavaScripts as imposed by websites, but I prefer websites
without it and I would prefer to not run them.

I can't imagine a web service that compensates (for me) JavaScript
problems by advantadges. I see a similar situation as with Adobe Flash
in the past.
But I believe this should not mean to discard MediaWiki, that's a great
software.

https://www.mediawiki.org/wiki/No-JavaScript_notes


El 19/7/21 a les 21:29, Lorenzo L. Ancora via ha escrit:
I could reply to this email but my reply would have exactly the same
content as the previous email, because I don't see you've added anything
new or that readers might not have deduced autonomously. In any possible
scenario, removing JavaScript worsens the user experience (JavaScript is
by no means replaceable), making format conversions and adding a
repository and/or additional protocols leads to rapid obsolescence and
decay within a few years.

Acceptance of factual reality is the prerequisite of any lasting
technical project.
It is my way of telling you that everything you are insisting on,
despite being of noble principles from the point of view of an extremely
small group of potential end users ( 0,23% of all potential visitors and
even less end users ), is not only superfluous but also potentially
harmful both from a technical and reputational point of view. The
long-term risk and drawbacks significantly outweigh the short and
long-term benefits and ultimately your project proposal does not seem
maintainable without the use of a somewhat experienced organic of
(dedicated) paid developers, which you cannot afford and without whom
won't be able to keep a minimum stable level of quality and coherence.

My final advice is to accept that the FSD is already using an optimal
software solution in regards to the business purposes ( in this case,
efficiently index and categorize free software ) and hence commit on
improving the contents it already manages, using HTML 5, CSS 3,
JavaScript and any technology fit for the purpose, with the majority of
potential visitors as explicit target.

Il 17/07/21 19:07, Bone Baboon ha scritto:
Lorenzo L. Ancora via writes:

I suggest that it is useless and unmaintainable in the long term to
support text-only web browsers and/or those that do not implement
JavaScript. Not your fault, it is how the World Wide Web was designed
and will be developed.

HTTP can serve web pages that are just HTML and CSS with no JavaScript.

There are other protocols in addition to HTTP that do not use
JavaScript.  Such as Gemini and Gopher.

1. JavaScript is required ( -- technically unavoidable -- ) to
implement accessibility and interactivity in complex, modern
websites. Literally, at some point you will always be forced to use
it, because scripting is very often necessary;

A read only HTML and CSS version of the FSD could be served without
JavaScript.

Changes to the FSD contents could be managed with a Git repository and a
Git workflow using email and patches.

2. Server-side alternatives to some functionalities typically offered
via JavaScript do exist but, since HTTP/S is a stateless protocol,
they almost always cause high server load and extend the attack
surface. Furthermore, the security requirements of the FSF would
impede the FSD administrators from managing server-side code;

This concept of the FSD as a Git repository replaces the client side
JavaScript and equivalent server side code with the use of a Git
repository, Git workflow and rendering the source code to HTML.

3. Nowadays, text-only does not mean more accessible, quite the
opposite: HTML 5 conveys semantic information via semantic tags; CSS
conveys semantic information through visibility and appearance rules;
the combination of JavaScript and CSS 3 offers the ability to detect
the features of the web browser and adapt the web page dynamically.
That info is required by physically and/or mentally impaired users.
Text files does not offer any kind of aid in navigation, visualization
(no branching logic = no ability to adapt), SEO (nowadays search
engines interpret the meaning of the tags) and maintainability (no
Content Management System = more hard work). Using Markdown won't make
them more accessible, it will only make them awkward for TTS/Braille
software, which is very bad;

To clarify I am suggesting that the source code would be compiled to
HTML and served with CSS so that people can browse a read only version
of the FSD.  This preserves the semantic meaning for people browsing a
read only copy of the FSD that is being served.

Someone would have the freedom to browse the read only FSD HTML contents
with whatever software they want.

4. Not all users are command-line savvy and can use Git, Bazaar,
Breezy, CVS, ... without risking cause damage to their system or
personal data by overwriting files or accidentally storing hidden
directories alongside their backups.

To mitigate this a detailed tutorial on how to use Git to contribute to
the FSD could be provided.

Speaking of privacy, for a user it is more difficult to delete the
history of a terminal than to clear the browser history or use the
private browsing mode;

Someone would have the freedom to browse the read only FSD HTML contents
with whatever software they want.

5. The number one rule of SEO is to never duplicate your content,
because search engines are not made by idiots and will penalize all
domains and subdomains which host non-original/cloned contents,
especially text. This means that you will inevitably lose users each
time you decide to duplicate your content;

This point should be taking into consideration when planning the
structure of the FSD Git repository and how it is rendered to HTML
pages.

6. Git (and really any other VCS) can be used to aid in hosting entire
websites, but only if those websites are not managed by many
people. The reason is that those systems are designed to allow
per-file downgrade and will store a lot of ever-growing data. This
works like a charm for small websites (guess what, I use them too!)
but what happens when you need to store the continuous contributions
of hundreds of users? You have hundreds of commits and changes, which
will cause the size of the repository to grow rapidly, reducing the
performance, making it almost impossible to efficiently diagnose
problems and finally you will be forced to truncate the entire
repository;

Git seems to be working well for many free software projects including
large projects like the Linux kernel.

If this problem arose then an archive Git repository could be created
and a new repository (truncated) could be used moving forwards.  This
approach could also be used if in the future it was desirable to migrate
to another version control system.

7. ...you will then need to implement server-side checks for the
consistency of the repository, nullifying any performance gain and,
even worse, creating increasingly heavy loading spikes on the server;

In this concept I am describing the server would be required to:
* compile the source code to HTML
* serve a static website of the source code repository (stagit or cgit)
* serve a static website for browsing a read only version of the FSD
    * source code compiled to HTML

8. Because of the loss/approximation of positional (layout)
information caused by the triple format conversion (HTML [manual] ->
text [manual] -> folded CLI text [automatic) ) you may inadvertently
convey bogus information to end users, so you will need someone
competent to check every single file in the repository
continuously... and you cannot afford that, because this is not a work
for volunteers. This happens because all web pages are written with a
combination of the WYSIWYM and WYSIWYG approaches, not good for
downgrades;

I do not see the need for a triple conversion.

Source code compilation:
Plain text -> HTML

Where the plain text could be markdown or org-mode format for example.

9. Only trusted users should even ever have write access to a
repository because in general a VCS lacks the ability to manage user
rights, making user management, security audit and information
verification very complex.

Yes this concept of the FSD as a Git repository would have people who
have commit access the the FSD Git repository reviewing submissions.

Also, it should be noted that some users for the sole purpose of
"showing their support for free software" declare that they usually
use text-only browsers or disable JavaScript. However, this is
unrealistic, because all banking sites, most social networks and in
general most websites require the use of graphical browsers and
JavaScript. So these statements are solely due to social pressure and
such users certainly have the ability to use a modern graphical
browser.

Banking can still be done by walking into a bank branch.

Not everyone uses social media.

People can choose to avoid websites that do not work without
JavaScript.

Actually, MediaWiki is already the best choice and nothing more is
required to offer an excellent user experience to 98% of your end
users.

You should not dismiss people who are using text browsers because they
are outnumbered by people using graphical browsers with JavaScript.

The only correct way to allow access to the FSD for the narrow
minority of users using text-only web browsers is to create an ad-hoc
web service with the help of a good full-stack web developer.

Another option that is mention by Bill Auger in this thread is use the
MediaWiki API.

PS: Gopher and other exotic/ancient protocols require dedicated server
software and proper isolation to be used in production.

Yes other protocols require different servers.

A benefit of this FSD as a Git repository concept is that it is
flexible.  If in the future it was desirable to serve the FSD over
another protocol it could be done by compiling the source code to a
format that the new adopted protocol serves.




--
All messages from/to this account should be considered private.
Messages from/to newsletters should not be reshared.
TZ: Europe/Rome (Italy - CEST).

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]