Re: FSD as a Git repository

[Narcis Garcia]

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

-- 
Narcis Garcia