On use of JavaScript within Forgejo frontend #73

KOLANICH commented 2023年10月18日 15:50:26 +02:00

I have encountered several issues (they are closed, I was asked to close them and discuss here first), severely crippling usability of Forgejo when JavaScript is disabled:

• forgejo/forgejo#1631
• forgejo/forgejo#1632
• forgejo/forgejo#1633
• forgejo/forgejo#1634
• forgejo/forgejo#1635

I was advised to create a general discussion on whether usability without JavaScript is a decent goal to achieve.

My arguments are:

• Running any Turing-complete code on client is a security and privacy threat.
  • It is impossible to prove that a certain Turing-complete program was not designed to do harm even if there is a perfect formal model what "harm" is.
  • Browser engines tend to expose JavaScript API that can be used to violate users' privacy and security. Even the basic unprivileged APIs like getBoundingClientRect or even math functions pose a threat, so are measureText and other canvas API, any APIs allowing to measure time (or that can be repurposed to measure time using ability to execute advanced algorythms on client), any API allowing low-level access like WebGL, WebGPU 1 2 and WASM
  • Monopolist browser vendors tend to design, implement and promote APIs that are designed harmful (negative used to be explicitly called harmful in the past) while benefiting their business interests in tracking users, and other browser vendors can have no other options but to implement those APIs too if too much websites start to depend on them.
  • Even if there is no harmful APIs in a browser
    • the mere access to memory by predictable alignment + precise enough timer are enough to do attacks on hardware like RowHammer or Spectre
    • it allows to do sophisticated algorythms to bypass mitigation techniques like DEP + ASLR when exploiting exploits not in JS code
• While some of the attack surface is available via CSS, disabling JS still protects from the most of attacks. This creates strong incentives to disable JavaScript.
• JS implementations of algorithms can work less efficiently than CSS ones.
• the model provided by frameworks doesn't interplay well with what browsers provide, which results in a significant overhead, though since Houdini (set of API allowing to plug own code into certain points in browser rendering pipeline) things should have become better. Though I feel like Houdini can open possibilities of fingerprinting.
• JS is a developing language and using the most shiny new features breaks the browsers not having them.
• as discussed within the issues linked, implementing the needed functionality without JS shouldn't be costly or take a lot of work. I feel like the same applies to all the essential functionality of a source code hosting.
• I suspect that the rationale mentioned above is obvious and that's why usability without JS is a requirement for A — Excellent score in GNU ethical repository criteria, though IMHO it doesn't make sense to divide features into tiers and also IMHO technical criteria are much more important than promotion of GNU/approved licenses, so IMHO no-JS is one of the most basic features.

So my proposal is to adopt a policy that

• it is a goal worth pursuing to have Forgejo usable without any client-side JavaScript working
• that if a functionality can be done in HTML and CSS (in this order, CSS can also be missing!), then it should be done that way
• if implementing functionality in HTML requires server-side support, then it should be implemented.
• that progressive enhancement approach should be used, so relying on new shiny features of browsers only if they are available and if it makes enough sense to use them
• that source code hosting is a serious business and that providing a shiny beautiful visual effect is not a rationale to introduce a dependency on a dangerous or too new API; that working, reliable, rock-solid, simple and clean is preferrable to new, shiny, posh and visually bloated. Animations and effects have the least priority possible and should be done without JS and the website should be usable and working and convenient even if the effects code is completely broken.
• that VanillaJS should be used instead of frameworks.
• JQuery should also not be allowed. We have the needed functionality within browsers for a very long time.

I have encountered several issues (they are closed, I was asked to close them and discuss here first), severely crippling usability of Forgejo when JavaScript is disabled: * [ ] https://codeberg.org/forgejo/forgejo/issues/1631 * [ ] https://codeberg.org/forgejo/forgejo/issues/1632 * [ ] https://codeberg.org/forgejo/forgejo/issues/1633 * [ ] https://codeberg.org/forgejo/forgejo/issues/1634 * [ ] https://codeberg.org/forgejo/forgejo/issues/1635 I [was advised](/forgejo/forgejo/issues/1634#issuecomment-1283633) to create a general discussion on whether usability without JavaScript is a decent goal to achieve. My arguments are: * Running any Turing-complete code on client is a security and privacy threat. * It is [impossible to prove](https://en.wikipedia.org/wiki/Halting_problem) that a certain Turing-complete program was not designed to do harm even if there is a perfect formal model what "harm" is. * Browser engines tend to expose JavaScript API that can be used to violate users' privacy and security. Even the basic unprivileged APIs like `getBoundingClientRect` or [even math functions](https://privacycheck.sec.lrz.de/active/fp_mr/fp_math_routines.html) pose a threat, so are [`measureText`](https://codeberg.org/KOLANICH-research/Article-2015-Dull-captaincy-or-the-way-Tor-Project-fights-brows) and other canvas API, any APIs allowing to measure time (or that [can be repurposed to measure time using ability to execute advanced algorythms on client](https://gruss.cc/files/fantastictimers.pdf)), any API allowing low-level access like WebGL, WebGPU [1](https://arxiv.org/pdf/2201.09956) [2](https://www.vusec.net/wp-content/uploads/2018/05/glitch.pdf) and WASM * Monopolist browser vendors tend to design, implement and promote APIs that [are designed harmful](https://github.com/mozilla/standards-positions) (`negative` [used to be explicitly called `harmful`](https://github.com/mozilla/standards-positions/pull/680) in the past) while benefiting their business interests in tracking users, and other browser vendors can have no other options but to implement those APIs too if too much websites start to depend on them. * Even if there is no harmful APIs in a browser * the mere access to memory by predictable alignment + precise enough timer are enough to do attacks on hardware like [RowHammer](https://github.com/IAIK/rowhammerjs) or [Spectre](https://github.com/alephsecurity/spectreBrowserResearch) * it allows to do sophisticated algorythms to bypass mitigation techniques like DEP + ASLR when exploiting exploits not in JS code * While some of the attack surface is available via CSS, disabling JS still protects from the most of attacks. This creates strong incentives to disable JavaScript. * JS implementations of algorithms can work less efficiently than CSS ones. * the model provided by frameworks doesn't interplay well with what browsers provide, which results in a significant overhead, though since Houdini (set of API allowing to plug own code into certain points in browser rendering pipeline) things should have become better. Though I feel like Houdini can open possibilities of fingerprinting. * JS is a developing language and using the most shiny new features breaks the browsers not having them. * as discussed within the issues linked, implementing the needed functionality without JS shouldn't be costly or take a lot of work. I feel like the same applies to all the essential functionality of a source code hosting. * I **suspect** that the rationale mentioned above is obvious and that's why usability without JS [is a requirement for `A — Excellent` score in `GNU ethical repository criteria`](https://www.gnu.org/software/repo-criteria.html#A), though IMHO it doesn't make sense to divide features into tiers and also IMHO technical criteria are much more important than promotion of GNU/approved licenses, so IMHO no-JS is one of the most basic features. So my proposal is to adopt a policy that * it is a goal worth pursuing to have Forgejo usable without any client-side JavaScript working * that if a functionality can be done in HTML and CSS (in this order, CSS can also be missing!), then it should be done that way * if implementing functionality in HTML requires server-side support, then it should be implemented. * that [progressive enhancement](https://en.wikipedia.org/wiki/Progressive_enhancement) approach should be used, so relying on new shiny features of browsers only if they are available and if it makes enough sense to use them * that source code hosting is a serious business and that providing a shiny beautiful visual effect is not a rationale to introduce a dependency on a dangerous or too new API; that working, reliable, rock-solid, simple and clean is preferrable to new, shiny, posh and visually bloated. Animations and effects have the least priority possible and should be done without JS and the website should be usable and working and convenient even if the effects code is completely broken. * that VanillaJS should be used instead of frameworks. * JQuery should also not be allowed. We have the needed functionality within browsers for a very long time.

earl-warren commented 2023年10月18日 18:59:51 +02:00

This is a compelling and well articulated argument. The resources to make that happen are significant (no less than one year full time from an experienced UI developer, most likely much more), that is my primary concern, even before debating if a agreement to pursue this goal can be reached. I can't see how the current workforce could achieve that goal. Do you have ideas on how to solve that particular bottleneck?

This is a compelling and well articulated argument. The resources to make that happen are significant (no less than one year full time from an experienced UI developer, most likely much more), that is my primary concern, even before debating if a agreement to pursue this goal can be reached. I can't see how the current workforce could achieve that goal. Do you have ideas on how to solve that particular bottleneck?

KaKi87 commented 2023年10月18日 19:52:49 +02:00

I strongly disagree and favor the opposite.

Server-side rendering is for websites that only display content, e.g. blog, portfolio, business showcase, etc.

Having the whole page reload during each navigation on that kind of site is acceaptable because it happens occasionally and only for reading purposes.

Meanwhile, Forgejo is an application, so interaction occurs frequently, therefore having the whole page reload after each action makes the experience slow.

Additionally, Forgejo has third-party clients and integrations. But when features are created using server-side rendering first, then making the feature available from the API takes too much time. On the other hand, developing features using client-side rendering first makes the feature available from API first, and therefore allows third parties to enjoy it as soon as first parties do.

To illustrate this, just have a look at the API dependency label of the GixNex app issue tracker.

Regarding frameworks, I don't think these should be avoided either, just the old ones, so I agree about jQuery, and the one that Forgejo and Gitea currently use is one of those as well. However, modern ones, such as Vue and Svelte, using client-side rendering, would be totally appropriate for this project.

I strongly disagree and favor the opposite. Server-side rendering is for websites that only display content, e.g. blog, portfolio, business showcase, etc. Having the whole page reload during each navigation on that kind of site is acceaptable because it happens occasionally and only for reading purposes. Meanwhile, Forgejo is an application, so interaction occurs frequently, therefore having the whole page reload after each action makes the experience slow. Additionally, Forgejo has third-party clients and integrations. But when features are created using server-side rendering first, then making the feature available from the API takes too much time. On the other hand, developing features using client-side rendering first makes the feature available from API first, and therefore allows third parties to enjoy it as soon as first parties do. To illustrate this, just have a look at [the *API dependency* label of the GixNex app issue tracker](https://codeberg.org/gitnex/GitNex/issues?q=&type=all&sort=&state=open&labels=3562&milestone=0&project=0&assignee=0&poster=0). Regarding frameworks, I don't think these should be avoided either, just the old ones, so I agree about jQuery, and the one that Forgejo and Gitea currently use is one of those as well. However, modern ones, such as Vue and Svelte, using client-side rendering, would be totally appropriate for this project.

KOLANICH commented 2023年10月18日 19:57:56 +02:00

I can't see how the current workforce could achieve that goal. Do you have ideas on how to solve that particular bottleneck?

1. First a decision is needed that noJS-breakage-related issues are real issues worth solving and not the ones that should be automatically wontfixed.
2. Solve the issues on case-by-case basis, starting with the most painful ones. It is opensource and so noone owes anyone anything.

The resources to make that happen are significant

In fact I don't think that they are so much significant for the issues mentioned, basically for some of them I had crafted my client-side surrogate solutions, the job to be done is to integrate them into the code base:

• forgejo/forgejo#1631 - generating a form and an iframe server-side like in the snippet from my surrogate should work fine

// I cannot do it with Fetch since cookies are unavailable to userscripts
let f = document.createElement("FORM");
let iF = document.createElement("iframe");
f.target = iF.name = "jdjdusisjdhdufjwj";
document.body.appendChild(iF);
f.action = u.href;
f.method = "POST";
let a = document.createElement("input");
a.name = "_csrf";
a.value = csrf;
f.appendChild(a);
a = document.createElement("input");
a.name = "topics";
a.value = topics.join(",");
f.appendChild(a);
document.body.appendChild(f);

the additions one need a CSS hiding the form and instructing a user to reload the page. Alternatively we can add an additional endpoint (or an additional param to the existing endpoint) and get rid of redirection of the result to an iframe. IMHO not so much of work.

• forgejo/forgejo#1632 - a problematic issue, since the JS-mediated lists are widespread, and so the fix needs testing. Also I haven't tried to implement a workaround for that yet because I have not read into UI framework code yet. IDK how much of work.

• forgejo/forgejo#1633 - requires an additional template, in principle the existing endpoint can be reused in the manner of 1631, but again, an additional endpoint or an arg to existing one should do better. IMHO not so much of work.

• forgejo/forgejo#1634 - I have not looked yet on how it is implemented, but probably requires some code doing rendering server-side

• forgejo/forgejo#1635 - an addition of a few rules to CSS can do the job. IMHO not so much of work.

>I can't see how the current workforce could achieve that goal. Do you have ideas on how to solve that particular bottleneck? 1. First a decision is needed that noJS-breakage-related issues are real issues worth solving and not the ones that should be automatically `wontfix`ed. 2. Solve the issues on case-by-case basis, starting with the most painful ones. It is opensource and so noone owes anyone anything. >The resources to make that happen are significant In fact I don't think that they are so much significant for the issues mentioned, basically for some of them I had crafted my client-side surrogate solutions, the job to be done is to integrate them into the code base: * [x] https://codeberg.org/forgejo/forgejo/issues/1631 - generating a form and an iframe server-side like in the snippet from my surrogate should work fine ```javascript // I cannot do it with Fetch since cookies are unavailable to userscripts let f = document.createElement("FORM"); let iF = document.createElement("iframe"); f.target = iF.name = "jdjdusisjdhdufjwj"; document.body.appendChild(iF); f.action = u.href; f.method = "POST"; let a = document.createElement("input"); a.name = "_csrf"; a.value = csrf; f.appendChild(a); a = document.createElement("input"); a.name = "topics"; a.value = topics.join(","); f.appendChild(a); document.body.appendChild(f); ``` the additions one need a CSS hiding the form and instructing a user to reload the page. Alternatively we can add an additional endpoint (or an additional param to the existing endpoint) and get rid of redirection of the result to an iframe. IMHO not so much of work. * [ ] https://codeberg.org/forgejo/forgejo/issues/1632 - a problematic issue, since the JS-mediated lists are widespread, and so the fix needs testing. Also I haven't tried to implement a workaround for that yet because I have not read into UI framework code yet. IDK how much of work. * [x] https://codeberg.org/forgejo/forgejo/issues/1633 - requires an additional template, in principle the existing endpoint can be reused in the manner of 1631, but again, an additional endpoint or an arg to existing one should do better. IMHO not so much of work. * [ ] https://codeberg.org/forgejo/forgejo/issues/1634 - I have not looked yet on how it is implemented, but probably requires some code doing rendering server-side * [x] https://codeberg.org/forgejo/forgejo/issues/1635 - an addition of a few rules to CSS can do the job. IMHO not so much of work.

KOLANICH commented 2023年10月18日 20:19:31 +02:00

Meanwhile, Forgejo is an application, so interaction occurs frequently, therefore having the whole page reload after each action makes the experience slow.

Only for no-JS clients. JS-clients can fetch the content via API. Also, IMHO not so frequently that a page reload is a significant delay.

BTW, the content fetched can be prerendered server-side, so the same impl can be reused. Yes, it consumes resources of the server to render them, the modern trend is to offload as much heavy tasks, like cryptocurrency mining, on clients :). As a way to optimize rendering, the prerendered content can be cached and just served from the cache.

However, modern ones, such as Vue and Svelte, using client-side rendering, would be totally appropriate for this project.

I'm not familiar to them (I have never used them in my projects), but I have already voiced my position - that IMHO the websites should be functional without JS and the majority of essential things can be achieved without frameworks the old school way it was done 20 years ago - by just using browser API to manipulate DOM.

But when features are created using server-side rendering first, then making the feature available from the API takes too much time

I think the both ways are must have. Server-side rendering is for browsers. API is for apps, scripts and so on. It doesn't exclude serving prerendered and/or preconverted content via some API endpoints. A decent forge needs all of them.

>Meanwhile, Forgejo is an application, so interaction occurs frequently, therefore having the whole page reload after each action makes the experience slow. Only for no-JS clients. JS-clients can `fetch` the content via API. Also, IMHO not so frequently that a page reload is a significant delay. BTW, the content fetched can be prerendered server-side, so the same impl can be reused. Yes, it consumes resources of the server to render them, the modern trend is to offload as much heavy tasks, like cryptocurrency mining, on clients :). As a way to optimize rendering, the prerendered content can be cached and just served from the cache. >However, modern ones, such as Vue and Svelte, using client-side rendering, would be totally appropriate for this project. I'm not familiar to them (I have never used them in my projects), but I have already voiced my position - that IMHO the websites should be functional without JS and the majority of essential things can be achieved without frameworks the old school way it was done 20 years ago - by just using browser API to manipulate DOM. > But when features are created using server-side rendering first, then making the feature available from the API takes too much time I think the both ways are must have. Server-side rendering is for browsers. API is for apps, scripts and so on. It doesn't exclude serving prerendered and/or preconverted content via some API endpoints. A decent forge needs all of them.

earl-warren commented 2023年10月18日 20:23:56 +02:00

In fact I don't think that they are so much significant for the issues mentioned, basically for some of them I had crafted my client-side surrogate solutions, the job to be done is to integrate them into the code base:

I did not realize you were proposing to work on this yourself, that changes the perspective significantly. In that case here is another question for when you implement the solutions you propose on top of the current codebase. They need to come with testing, that's the hard part because there is no testing at the moment. The codebase is heavily modified by Gitea contributors and whenever users discover regressions, they are fixed. The user base of Gitea is larger than the user base of Forgejo and they can afford that kind of human powered regression tests. Forgejo needs automated testing because there would otherwise be no way to figure out of the UI patches you propose keep working whenever a release is prepared.

Are you willing to implement that kind of testing to check that the alternate, non-JavaScript based implementation, provides the equivalent UX and UI?

> In fact I don't think that they are so much significant for the issues mentioned, basically for some of them I had crafted my client-side surrogate solutions, the job to be done is to integrate them into the code base: I did not realize you were proposing to work on this yourself, that changes the perspective significantly. In that case here is another question for when you implement the solutions you propose on top of the current codebase. They need to come with testing, that's the hard part because there is no testing at the moment. The codebase is heavily modified by Gitea contributors and whenever users discover regressions, they are fixed. The user base of Gitea is larger than the user base of Forgejo and they can afford that kind of human powered regression tests. Forgejo needs automated testing because there would otherwise be no way to figure out of the UI patches you propose keep working whenever a release is prepared. Are you willing to implement that kind of testing to check that the alternate, non-JavaScript based implementation, provides the equivalent UX and UI?

earl-warren commented 2023年10月18日 20:31:42 +02:00

@KaKi87 can we please wait until the proposed strategy to implement this is fully presented before debating on whether it is better or worst from a UX point of view? I have very rarely seen such a well articulated and detailed plan together with the skillset and willingness to implement such a plan. I am impressed and would like to fully understand what is proposed.

@KaKi87 can we please wait until the proposed strategy to implement this is fully presented before debating on whether it is better or worst from a UX point of view? I have very rarely seen such a well articulated and detailed plan together with the skillset and willingness to implement such a plan. I am impressed and would like to fully understand what is proposed.

KaKi87 commented 2023年10月18日 21:28:34 +02:00

not so frequently that a page reload is a significant delay

It is, because there's more information for the server to return, and because there's more information for the browser to display. Meanwhile, an API request can return just a small JSON and mutate just a few elements.

Yes, it consumes resources of the server to render them

Actually, I wouldn't criticize that, because I only care about user experience.

websites should be functional without JS

That's like saying "vehicles should be functional without motors", i.e. preventing progress.

JS (today's JS) is an awesome evolution of web browsing, and we should enjoy it.

the majority of essential things can be achieved without frameworks the old school way it was done 20 years ago - by just using browser API to manipulate DOM.

For blogs, yes. But for apps, with many features like Forgejo has, doing this would unavoidably end up in reinventing the wheel.

both ways are must have

That's theorically acceaptable, but practically impossible on a volunteer-based project : the reality is that server-first features get implemented by API late or never.

API is for apps

Precisely : Forgejo is an app. A web app, but an app nontheless.

can we please wait until the proposed strategy to implement this is fully presented before debating on whether it is better or worst from a UX point of view?

Should I propose the opposite strategy in a separate issue then ?

The drawbacks of this old UI code has been discussed several times as well.

And I too would volunteer at developing a modern alternative front-end for Forgejo, I'd only need the help of a graphic designer.

> not so frequently that a page reload is a significant delay It is, because there's more information for the server to return, and because there's more information for the browser to display. Meanwhile, an API request can return just a small JSON and mutate just a few elements. > Yes, it consumes resources of the server to render them Actually, I wouldn't criticize that, because I only care about user experience. > websites should be functional without JS That's like saying "vehicles should be functional without motors", i.e. preventing progress. JS (today's JS) is an awesome evolution of web browsing, and we should enjoy it. > the majority of essential things can be achieved without frameworks the old school way it was done 20 years ago - by just using browser API to manipulate DOM. For blogs, yes. But for apps, with many features like Forgejo has, doing this would unavoidably end up in *reinventing the wheel*. > both ways are must have That's theorically acceaptable, but practically impossible on a volunteer-based project : the reality is that server-first features get implemented by API late or never. > API is for apps Precisely : Forgejo is an app. A web app, but an app nontheless. > can we please wait until the proposed strategy to implement this is fully presented before debating on whether it is better or worst from a UX point of view? Should I propose the opposite strategy in a separate issue then ? The drawbacks of this old UI code has been discussed several times as well. And I too would volunteer at developing a modern alternative front-end for Forgejo, I'd only need the help of a graphic designer.

KOLANICH commented 2023年10月18日 21:43:55 +02:00

you were proposing to work on this yourself

Not quite. I prefer to stay away of code in Go, since I deeply dislike its package manager that loads tons of dependencies and rebuilds them, wasting my time, electricity and disk space (IDK about if go can execute code during building, but cargo crates can contain such code), its model centered around static linking and generating large binaries and its model of decomposition of software into goroutines that IMHO (from the PoV of a C++ programmer) is overengineering for the sake of NiH syndrome to just have something new in the language no matter if it is needed and useful or not.

But I can do something in HTML, CSS and JS code. Likely in the form of snippets ripped from my surrogate userscripts. It can be straightforward to rewrite them into Go, as well as create endpoints, but it is better to be done not by me, but by a person having a local Go toolchain, who is able make sure that the code compiles and works before sending a PR. The CSS code will likely need to be just copied into stylesheet files.

Are you willing to implement that kind of testing to check that the alternate, non-JavaScript based implementation, provides the equivalent UX and UI?

For now I cannot provide testing. I have to do certain things first. Not sure if I do them soon.

Also TBH I'd prefer the changes being upstreamed back to Gitea for users of it to benefit from them too. It is likely that the code in question is shared between Gitea and Forgejo. I probably could have raised the issue in Gitea bug tracker, if I did it earlier, but I just was forced out of GitHub (I can still push code into my existing repos via SSH using my SSH key as a single factor, but now I cannot do any actions via GitHub web GUI, like opening issues, without complying with their blackmail and enabling 2FA) so I have raised the issues here.

>you were proposing to work on this yourself Not quite. I prefer to stay away of code in Go, since I deeply dislike its package manager that loads tons of dependencies and rebuilds them, wasting my time, electricity and disk space (IDK about if `go` can execute code during building, but `cargo` crates can contain such code), its model centered around static linking and generating large binaries and its model of decomposition of software into goroutines that IMHO (from the PoV of a C++ programmer) is overengineering for the sake of NiH syndrome to just have something new in the language no matter if it is needed and useful or not. But I can do something in HTML, CSS and JS code. Likely in the form of snippets ripped from my surrogate userscripts. It can be straightforward to rewrite them into Go, as well as create endpoints, but it is better to be done not by me, but by a person having a local Go toolchain, who is able make sure that the code compiles and works before sending a PR. The CSS code will likely need to be just copied into stylesheet files. >Are you willing to implement that kind of testing to check that the alternate, non-JavaScript based implementation, provides the equivalent UX and UI? For now I cannot provide testing. I have to do certain things first. Not sure if I do them soon. Also TBH I'd prefer the changes being upstreamed back to Gitea for users of it to benefit from them too. It is likely that the code in question is shared between Gitea and Forgejo. I probably could have raised the issue in Gitea bug tracker, if I did it earlier, but I just [was forced out of GitHub](https://codeberg.org/KOLANICH/Fuck-GuanTEEnomo/wiki) (I can still push code into my existing repos via SSH using my SSH key as a single factor, but now I cannot do any actions via GitHub web GUI, like opening issues, without complying with their blackmail and enabling 2FA) so I have raised the issues here.

earl-warren commented 2023年10月18日 21:47:46 +02:00

@KaKi87 I think @KOLANICH efforts to communicate their ideas and plans deserve to be listened to in full before disagreeing on principle. If I was in their place I would find it unfriendly to be meet with such a strong rebutal even before I had a chance to explain.

That's all I'm asking. Just to be welcoming, keep an open mind and make an honest effort to understand.

@KaKi87 I think @KOLANICH efforts to communicate their ideas and plans deserve to be listened to in full before disagreeing on principle. If I was in their place I would find it unfriendly to be meet with such a strong rebutal even before I had a chance to explain. That's all I'm asking. Just to be welcoming, keep an open mind and make an honest effort to understand.

earl-warren commented 2023年10月18日 22:08:15 +02:00

@KOLANICH thanks for clarifying that you do not intend to carry out this work by yourself. But it is good that you are willing to participate in its implementation to the extent of your abilities. In that case the first blocker is to find someone who is willing to execute the plan you have in mind with you. It is going to require weeks of work over a period of months, even if executed perfectly.

My hunch is that it will take you a few months to find someone willing to do that.

Since the codebase you are targeting is moving rapidly, making detailed plans to implement your ideas is not necessary and would be wasting your valuable time because:

• the person who will carry out the implementation of a "no javascript" UI will most certainly have strong opinions about how to do that. And they will have the final word since they are the one holding the keyboard.
• the codebase on which such technical plans are to be made is changing rapidly and you will end up constantly revising they plans you made to catch up, without any benefit for doing so since there won't be anyone to implement your ideas.

Do you agree that finding someone willing and able to implement your plan is a blocker that needs to be resolved before doing anything else? Or do you see another way to go about this?

@KOLANICH thanks for clarifying that you do not intend to carry out this work by yourself. But it is good that you are willing to participate in its implementation to the extent of your abilities. In that case the **first blocker** is to find someone who is willing to execute the plan you have in mind with you. It is going to require weeks of work over a period of months, even if executed perfectly. My hunch is that it will take you a few months to find someone willing to do that. Since the codebase you are targeting is moving rapidly, making detailed plans to implement your ideas is not necessary and would be wasting your valuable time because: * the person who will carry out the implementation of a "no javascript" UI will most certainly have strong opinions about how to do that. And they will have the final word since they are the one holding the keyboard. * the codebase on which such technical plans are to be made is changing rapidly and you will end up constantly revising they plans you made to catch up, without any benefit for doing so since there won't be anyone to implement your ideas. Do you agree that finding someone willing and able to implement your plan is a blocker that needs to be resolved before doing anything else? Or do you see another way to go about this?

KOLANICH commented 2023年10月18日 23:07:10 +02:00

Do you agree that finding someone willing and able to implement your plan is a blocker that needs to be resolved before doing anything else? Or do you see another way to go about this?

I think that

• finding a person doing the actual work is absolutely needed to get the features actually implemented.

• But for now there is no decision that those features worth implemeting at all, and if I understand right, this discussion, #73, is not so much about when (the usual when it is done), how (at high level achieving a goal is just doing steps towards the needed direction, in our case those steps are fixed issues about critical functionality not working without JS) and by whom (it's opensource, so by the ones who volunteer) to achieve no-JS usability, but exactly about if those features should be worked on at all, instead of taking direction of intentionally dropping no-JS usability and removing all existing code doing server-side rendering (this way wasting all the effort invested into it, including the one that is already implemented by now).

So finding a person is not the first step.

1. the first step is to decide whether no-JS is one of long-term goals of this project. When I was creating the issues I assummed that it is:
   • since pretty a lot (I can create a repo, I can create a no-template issue, I can push, I can pull) already works without JS, but there are few issues spoiling the picture
   • given the obvious (at least for me) rationale mentioned in the beginning of this discussion
   • since the goal is clearly possible to implement.
2. if there is a goal, determine the steps to do to achieve it. At least the issues mentioned are.
3. find a person who is willing to do the work on each particular issue. Different issues require different tools to solve. Some require CSS, some require code in Go. Different people can have different will and capabilities to take part in each of them. Without the understanding what has to be done there will be no 3rd-parties willing to do the work.
4. When is it finished? As usual: when it is done. May be 1 day, may be millenia. No deadline. It is opensource and noone owes anyone anything.

>Do you agree that finding someone willing and able to implement your plan is a blocker that needs to be resolved before doing anything else? Or do you see another way to go about this? I think that * finding a person doing the actual work is absolutely needed to get the features actually implemented. * But for now there is no decision that those features worth implemeting at all, and if I understand right, this discussion, #73, is not so much about when (the usual `when it is done`), how (at high level achieving a goal is just doing steps towards the needed direction, in our case those steps are fixed issues about critical functionality not working without JS) and by whom (it's opensource, so by the ones who volunteer) to achieve no-JS usability, but exactly about if those features should be worked on at all, instead of taking direction of intentionally dropping no-JS usability and removing all existing code doing server-side rendering (this way wasting all the effort invested into it, including the one that is already implemented by now). So finding a person is not the first step. 1. the first step is to decide whether no-JS is one of long-term goals of this project. When I was creating the issues I assummed that it is: * since pretty a lot (I can create a repo, I can create a no-template issue, I can push, I can pull) already works without JS, but there are few issues spoiling the picture * given the obvious (at least for me) rationale mentioned in the beginning of this discussion * since the goal is clearly possible to implement. 2. if there is a goal, determine the steps to do to achieve it. At least the issues mentioned are. 3. find a person who is willing to do the work on each particular issue. Different issues require different tools to solve. Some require CSS, some require code in Go. Different people can have different will and capabilities to take part in each of them. **Without the understanding what has to be done there will be no 3rd-parties willing to do the work.** 4. When is it finished? As usual: `when it is done`. May be 1 day, may be millenia. No deadline. It is opensource and noone owes anyone anything.

rome-user commented 2023年10月18日 23:32:34 +02:00

I sense a contradiction in the first post.

JS is a developing language and using the most shiny new features breaks the browsers not having them.

but also

JQuery should also not be allowed. We have the needed functionality within browsers for a very long time.

To some people, document.querySelectorAll is indeed a shiny new feature if they are still using old operating systems and stuck on old browsers. Even if we ignore these people, there are a significant number of people in developing countries who still use Android 4.x, Opera Mini, etc. There is an equal amount of "shiny new features" in CSS and HTML, too. Most notably, custom elements, support for non-sRGB color spaces, media queries for preferring dark themes, reduced transparency, etc.

So my question: how do you determine a baseline level of support? If we care about mobile users, then the existence and high usage of Opera Mini in some developing countries means that we should actually prefer jQuery over "modern" JS functions.

implementing the needed functionality without JS shouldn't be costly or take a lot of work.

I used to believe this as well. One of my first web apps was intentionally no-JS on the whole client side. I quickly found that web browsers are pretty bad HTTP clients without the help of JavaScript and often require backends to implement workarounds from the Ruby on Rails days, like "hidden methods", where you POST with a _method parameter that indicates to the backend what the real method is.

Wherever the Forgejo frontend uses methods besides GET and POST will need Forgejo to maintain a middleware translating hidden methods and refactor existing code to behave as such in the absence of JS. This will probably make it increasingly difficult to keep Forgejo as a soft fork of Gitea.

---

With all of that said, as someone who still uses Power Mac G5 occasionally, I definitely love seeing websites (and web apps) that make an effort to support old hardware. But we also have to be pragmatic: there is non-trivial maintenance cost of no-JS workarounds for seemingly simple things like XMLHttpRequest (or fetch), especially when there are constraints like "stay as a soft fork" or "stay as a drop-in replacement" of Gitea.

For this reason, I see JavaScript as a "necessary evil" for some Forgejo functionality, even if with ample effort we can almost certainly create no-JS variants of existing functionality.

I sense a contradiction in the first post. > JS is a developing language and using the most shiny new features breaks the browsers not having them. but also > JQuery should also not be allowed. We have the needed functionality within browsers for a very long time. To some people, `document.querySelectorAll` is indeed a shiny new feature if they are still using old operating systems and stuck on old browsers. Even if we ignore these people, there are a significant number of people in developing countries who still use Android 4.x, Opera Mini, etc. There is an equal amount of "shiny new features" in CSS and HTML, too. Most notably, custom elements, support for non-sRGB color spaces, media queries for preferring dark themes, reduced transparency, etc. So my question: **how do you determine a baseline level of support?** If we care about mobile users, then the existence and high usage of Opera Mini in some developing countries means that we should actually prefer jQuery over "modern" JS functions. > implementing the needed functionality without JS shouldn't be costly or take a lot of work. I used to believe this as well. One of my first web apps was intentionally no-JS on the whole client side. I quickly found that web browsers are pretty bad HTTP clients without the help of JavaScript and often require backends to implement workarounds from the Ruby on Rails days, like "hidden methods", where you POST with a `_method` parameter that indicates to the backend what the real method is. Wherever the Forgejo frontend uses methods besides `GET` and `POST` will need Forgejo to maintain a middleware translating hidden methods *and* refactor existing code to behave as such in the absence of JS. This will probably make it increasingly difficult to keep Forgejo as a soft fork of Gitea. --- With all of that said, as someone who still uses Power Mac G5 occasionally, I definitely love seeing websites (and web apps) that make an effort to support old hardware. But we also have to be pragmatic: there is non-trivial maintenance cost of no-JS workarounds for seemingly simple things like XMLHttpRequest (or fetch), especially when there are constraints like "stay as a soft fork" or "stay as a drop-in replacement" of Gitea. For this reason, I see JavaScript as a "necessary evil" for some Forgejo functionality, even if with ample effort we can almost certainly create no-JS variants of existing functionality.

KaKi87 commented 2023年10月19日 00:27:55 +02:00

the first step is to decide whether no-JS is one of long-term goals of this project

That's also what I understood from the start and why I voiced my opinion from the start.

I wasn't trying to stop the discussion, I was trying to participate to the discussion.

> the first step is to decide whether no-JS is one of long-term goals of this project That's also what I understood from the start and why I voiced my opinion from the start. I wasn't trying to stop the discussion, I was trying to participate to the discussion.

KOLANICH commented 2023年10月19日 00:39:40 +02:00

I sense a contradiction in the first post.

There is. We have to throw away someone. There are tags and protocols not supported by Netscape 4.0. Fortunately pure HTML is supported by pretty a lot of browsers, including fringe ones like Konqueror/Otter and so on. CSS support decays faster. JS support decays even faster: they have introduced private properties and a few flags for regexps - and now if they are used, everyone who doesn't have them gets syntax error without any possibility to fallback other than using eval (which is evil!) That's why browsers themselves should be modular.

To some people, document.querySelectorAll is indeed a shiny new feature if they are still using old operating systems and stuck on old browsers.

It is true. Also getElementsByTagName, getElementById and getElementsByName should be slightlty faster, that's why I usually use them. Also in my code I use fetch API (no xmlHTTPRequest) and Promises, which also used to be a shiny new feature somewhen.

who still use Android 4.x

I personally use Android 4.4.4 "Kit Kat" with an obsolete version of Firefox that supports it. That's why I have those

JavaScript error: SyntaxError: expected expression, got '.' (https://codeberg.org/forgejo/discussions/issues/73#issuecomment-1284179 @ 2262:20). Open browser console to see more details.
JavaScript error: ReferenceError: globalThis is not defined (https://codeberg.org/assets/js/webcomponents.js?v=1.20.4~0-66-g325fb619e @ 1:26169). Open browser console to see more details.

in the top.

So my question: how do you determine a baseline level of support?

2015 for me should be fine. Untill noone comes and says "I have to use an earlier browser!"

we should actually prefer jQuery over "modern" JS functions.

Not JQuery. Polyfills having exactly the same interface as WebAPI. There is a library of them.

I used to believe this as well. One of my first web apps was intentionally no-JS on the whole client side. I quickly found that web browsers are pretty bad HTTP clients without the help of JavaScript and often require backends to implement workarounds from the Ruby on Rails days, like "hidden methods", where you POST with a _method parameter that indicates to the backend what the real method is.

Thanks for sharing this.

keep Forgejo as a soft fork of Gitea.

TBH I'd prefer upstreaming as much as possible (and when I need changes in libs I use, I usually try to upstream the changes, unfortunately too often maintainers are uncooperative). I have heard that there was some conflict between Gitea and the group of people that have founded Forgejo about the trademarks (IMHO all the so called "intellectual property" system (including copyrights, patents and trademarks) should be abolished as fundamentally incompatible to human rights). I understand that the group can have some incentives to keep improvements of Forgejo to itself and not to upstream to Gitea in order to punish that corporation by outcompeting it. But you got it right, maintaining an own fork is hard work, especially without a decent version control system (git is not, a decent version control system should operate semanticaly, maybe symbolically on AST level, or maybe even using embeddings and LLMs). So it should be evaluated whether retaining a change brings more benefit than the costs of not upstreaming it. I personally think that it'd have been much better that the only difference of Forgejo form Gitea was the name stored in a single place and not present in repos at all.

I see JavaScript as a "necessary evil" for some Forgejo functionality

Yes, it is, but the amount of evil should steadily shrink. I mean we cannot expect all the functionality be fixed into a progressively enhanced with a single clap of hands. But I feel like this should be a long-term goal.

>I sense a contradiction in the first post. There is. We have to throw away someone. There are tags and protocols not supported by Netscape 4.0. Fortunately pure HTML is supported by pretty a lot of browsers, including fringe ones like Konqueror/Otter and so on. CSS support decays faster. JS support decays even faster: they have introduced private properties and a few flags for regexps - and now if they are used, everyone who doesn't have them gets syntax error without any possibility to fallback other than using `eval` (which is evil!) That's why [browsers themselves should be modular](https://github.com/open-source-ideas/ideas/issues/115). >To some people, document.querySelectorAll is indeed a shiny new feature if they are still using old operating systems and stuck on old browsers. It is true. Also `getElementsByTagName`, `getElementById` and `getElementsByName` should be slightlty faster, that's why I usually use them. Also in my code I use `fetch` API (no `xmlHTTPRequest`) and `Promise`s, which also used to be a shiny new feature somewhen. >who still use Android 4.x I personally use Android 4.4.4 "Kit Kat" with an obsolete version of Firefox that supports it. That's why I have those >`JavaScript error: SyntaxError: expected expression, got '.' (https://codeberg.org/forgejo/discussions/issues/73#issuecomment-1284179 @ 2262:20). Open browser console to see more details.` >`JavaScript error: ReferenceError: globalThis is not defined (https://codeberg.org/assets/js/webcomponents.js?v=1.20.4~0-66-g325fb619e @ 1:26169). Open browser console to see more details.` in the top. >So my question: how do you determine a baseline level of support? 2015 for me should be fine. Untill noone comes and says "I have to use an earlier browser!" >we should actually prefer jQuery over "modern" JS functions. Not JQuery. Polyfills having exactly the same interface as WebAPI. [There is a library of them.](https://github.com/zloirock/core-js) >I used to believe this as well. One of my first web apps was intentionally no-JS on the whole client side. I quickly found that web browsers are pretty bad HTTP clients without the help of JavaScript and often require backends to implement workarounds from the Ruby on Rails days, like "hidden methods", where you POST with a _method parameter that indicates to the backend what the real method is. Thanks for sharing this. >keep Forgejo as a soft fork of Gitea. TBH I'd prefer upstreaming as much as possible (and when I need changes in libs I use, I usually try to upstream the changes, unfortunately too often maintainers are uncooperative). I have heard that there was some conflict between Gitea and the group of people that have founded Forgejo about the trademarks (IMHO all the so called "intellectual property" system (including copyrights, patents and trademarks) should be abolished as fundamentally incompatible to human rights). I understand that the group can have some incentives to keep improvements of Forgejo to itself and not to upstream to Gitea in order to punish that corporation by outcompeting it. But you got it right, maintaining an own fork is hard work, especially without a decent version control system (`git` is not, a decent version control system should operate semanticaly, maybe symbolically on AST level, or maybe even using embeddings and LLMs). So it should be evaluated whether retaining a change brings more benefit than the costs of not upstreaming it. I personally think that it'd have been much better that the only difference of Forgejo form Gitea was the name stored in a single place and not present in repos at all. >I see JavaScript as a "necessary evil" for some Forgejo functionality Yes, it is, but the amount of evil should steadily shrink. I mean we cannot expect all the functionality be fixed into a progressively enhanced with a single clap of hands. But I feel like this should be a long-term goal.

KaKi87 commented 2023年10月19日 01:33:11 +02:00

I personally use Android 4.4.4 "Kit Kat" with an obsolete version of Firefox that supports it.

I don't think Forgejo should support it, because it's dangerous to use. That said, even this version supports querySelector so it shouldn't be a problem to use it.

> I personally use Android 4.4.4 "Kit Kat" with an obsolete version of Firefox that supports it. I don't think Forgejo should support it, because it's dangerous to use. That said, even this version supports `querySelector` so it shouldn't be a problem to use it.

KaKi87 commented 2023年10月19日 02:12:57 +02:00

While I understand why you don't want to use big tech's closed or semi-closed authentication methods, saying that "mandatory 2FA is an antifeature" is a wrong generalization, because, TOTP, for one, is fully open, and I don't understand why you don't want to use that.

It's not like Google, who used to allow TOTP 2FA, but now only supports its closed Authenticator, FIDO and SMS.

However, I'm off-topic so I promise I won't say anything further about this subject here, but if you want, feel free to reach out on Matrix.

While I understand why you don't want to use big tech's closed or semi-closed authentication methods, saying that "mandatory 2FA is an antifeature" is a wrong generalization, because, TOTP, for one, is fully open, and I don't understand why you don't want to use that. It's not like Google, who used to allow TOTP 2FA, but now only supports its closed *Authenticator*, FIDO and SMS. However, I'm off-topic so I promise I won't say anything further about this subject here, but if you want, feel free to reach out on Matrix.

KaKi87 commented 2023年10月19日 02:40:37 +02:00

it's my phone, I know how much insecure it is. It's not up to anyone except me to decide what I should do with my phone.

Actually, you're not only risking your data, but also the data of everyone who trusts you with theirs : family, friends, etc.

(Technically I didn't break my promise, and I just couldn't let such a dangerous statement stand alone).

> it's my phone, I know how much insecure it is. It's not up to anyone except me to decide what I should do with my phone. Actually, you're not only risking your data, but also the data of everyone who trusts you with theirs : family, friends, etc. *(Technically I didn't break my promise, and I just couldn't let such a dangerous statement stand alone).*

KOLANICH commented 2023年10月19日 02:53:53 +02:00

How about cleaning our offtop in this thread?

UPD: cleaned some offtop.

How about cleaning our offtop in this thread? UPD: cleaned some offtop.

earl-warren commented 2023年10月19日 12:46:43 +02:00

@KOLANICH

So finding a person is not the first step.

I meant to say that it is the first step before anything has even a remote chance of happening in the coming years.

@KOLANICH > So finding a person is not the first step. I meant to say that it is the first step before anything has even a remote chance of happening in the coming years.

caesar commented 2023年10月22日 21:58:34 +02:00

I haven't been around much the last few days so only just saw this. I've read the first posts but just skimmed the rest.
I just wanted to note that the work I have funding to complete includes ensuring accessibility without JavaScript for the most frequently used pages. (My work is far behind schedule but I still intend to complete it.)

Regarding the debate about whether in general no-JS support is desired, I to some extent support the arguments of both @KOLANICH and @KaKi87. I strongly believe it is important that Forgejo is usable without JavaScript. However I also believe that via progressive enhancement, the experience can be significantly improved for those who do use JavaScript. The two options are not mutually exclusive.

I haven't been around much the last few days so only just saw this. I've read the first posts but just skimmed the rest. I just wanted to note that [the work I have funding to complete](https://codeberg.org/forgejo/sustainability/src/branch/main/2022-12-01-nlnet/2023-06-workplan.md#scope-ui-and-accessibility-improvements) includes [ensuring accessibility without JavaScript](https://codeberg.org/forgejo/sustainability/src/branch/main/2022-12-01-nlnet/2023-06-workplan.md#ensure-accessibility-without-javascript) for the most frequently used pages. (My work is far behind schedule but I still intend to complete it.) Regarding the debate about whether in general no-JS support is desired, I to some extent support the arguments of both @KOLANICH and @KaKi87. I strongly believe it is important that Forgejo is usable without JavaScript. However I also believe that via progressive enhancement, the experience can be significantly improved for those who do use JavaScript. The two options are not mutually exclusive.

KaKi87 commented 2023年10月22日 22:17:53 +02:00

The two options are not mutually exclusive.

That's right, but I also believe that the project does not has enough workforce to do both simultaneously.

And if one of those must be dropped in favor of the other, then I think it should be no-JS support, because dropping JS support is not only affecting UX but also features API availability.

> The two options are not mutually exclusive. That's right, but I also believe that the project does not has enough workforce to do both simultaneously. And if one of those must be dropped in favor of the other, then I think it should be no-JS support, because dropping JS support is not only affecting UX but also features API availability.

KOLANICH commented 2023年10月22日 22:58:12 +02:00

@caesar, thank you for mentioning that.
@KaKi87 BTW, AFAIK, JS-based GUI uses API endpoints different from the ones used by external apps. JS-based GUI uses own API that is immediately within website and that uses cookie auth + CSRF tokens, while the API used by apps/scripts is within /api/ and uses OAuth or manually generated or CI tokens.

@caesar, thank you for mentioning that. @KaKi87 BTW, AFAIK, JS-based GUI uses API endpoints different from the ones used by external apps. JS-based GUI uses own API that is immediately within website and that uses cookie auth + CSRF tokens, while the API used by apps/scripts is within `/api/` and uses OAuth or manually generated or CI tokens.