One of my more recent TODOs was to put together a draft document explaining and justifying this project's use of JavaScript. In the past 4-ish months we've added more JS to the tree, and implemented more client-side logic in JS, than in the whole prior history of the project combined. One aim of this document is to explain why that is.

Any interested readers and/or editors are encouraged to visit:

https://fossil-scm.org/fossil/timeline?r=js-policy-doc

From the introduction of that document (noting that it is a draft which must not be understood, in its current form, to be "official project-level policy"):

The topic of using ECMAScript (better known as JavaScript, abbreviated
JS) in fossil's UI has always been a mildly contentious point. On the
one hand, the site "can" get by fine with purely static HTML, and some
users consider that to be not only adequate, but preferable. On the
other, some level of client-side-only interactivity or UI enhancement
is often useful (some would say preferable), and the only option for
implementing such things in HTML-based interfaces is JS.

The purpose of this document is to explain and justify how JS is used
within the Fossil project.

Feedback on all aspects of it is welcomed and encouraged, either through the forums, direct email (if you prefer), or direct commits (or branches, if you prefer).

Why isn’t this just an extension to https://fossil-scm.org/fossil/doc/trunk/www/javascript.md?

Why isn’t this just an extension to https://fossil-scm.org/fossil/doc/trunk/www/javascript.md?

Because i was unaware of that doc :|. Ooops. i will get to integrating after checking in my current changes.

Edit: or had forgotten it, in any case. The "Evil is in actions, not nouns," part is certainly familiar.

I've merged the contents of js-policy.md into javascript.md, some of which is already on trunk, but most is still on the branch. (View it.)

I did a lot of rewriting, which I hope is okay with you, Stephan. The point of doing this on a branch is to hash out differences of opinion, to buff the sharp bits off of immoderate presentations, etc., yes?

Okay, I'm hands-off on this document for now, having completed a full read-through and edit pass on it.

I remember drh touching up every single commit containing Javascript code, to simplify it as much as possible, and to remove anything unnecessary.

When opposing against adopting a Javascript framework library for Fossil, and voting for Vanilla Javascript (not that I think my vote alone would have changed anything), what I had in mind was this kind of simple drh-style Javascript.

But instead, now we have a huge framework library, around 4K(!) worth of lines, created and maintained by one single developer (stephan). My guess is that nobody will be able soon to understand the library and produce reasonable code using it, due to its sheer complexity. So that one single developer (stephan) will remain the only one to be able to understand and work on Fossil's Javascript. With statements like "regardless of feedback, the final implementation decision lies with whoever is writing the code", stephan also makes clear that he will be the one to decide about the future of the Fossil UI -- likely further pushing his "mobile-first" (and sometimes almost "mobile-only") philosophy, which doesn't always fit nicely for people primarily working with desktop systems.

My feeling is that such a complex Javascript application should be split into a separate, enhanced Fossil web UI application, to keep the Fossil core simple and compact. For example, I don't understand why I'd want to run more than 800 lines of Javascript code each time I'm viewing a file in the web UI and would like to see the line numbers -- only to simplify a bit the trivial task of copying a hyperlink plus a line number to the clipboard. But people who like such features could run the enhanced Fossil web UI application on their servers.

If I wanted "blim blim" and "klicki-bunti" all over the place, I'd have created a GitHub account! But instead, I prefer the simplicity of Fossil, and I think this is something worth to take care of!

If I wanted "blim blim" and "klicki-bunti" all over the place, I'd have created a GitHub account!

Emotionally, I don't like the recent changes either, but so far I haven't been able to come up with a good logical argument that wouldn't come down to my values as an anti-JS camp member.

But let me play the Devil'sJavaScript advocate...

huge framework library, around 4K(!) worth of lines

Quite a lot of it is documentation, and for some functions the comments even exceed the code in size. 4K of typical Web3.0 JavaScript would give us cause for concern (especially if it's minified), but 4K of well-written and documented JavaScript is probably much less alarming.

My guess is that nobody will be able soon to understand the library and produce reasonable code using it, due to its sheer complexity

People flee in horror from smaller C codebases than SQLite and smaller C executables than Fossil (2.7M in Debian stretch-backports, around 3.4M of .text + .rodata + .data in 2.11.1 binary), especially if they are mostly written by one person, and yet this argument doesn't quite fit the C parts of Fossil. Should it apply to JS parts, then?

statements like "regardless of feedback, the final implementation decision lies with whoever is writing the code"

Despite finally getting my Contributor Agreement to D. Richard Hipp some time ago, I somehow haven't been able to find the time to resurrect the pre-AJAX Wiki editing page and offer a patch providing it as a <noscript> fallback. Would you be interested in maintaining fallback interfaces for Fossil together?

...an anti-JS camp member.

"Anti" is not an argument, no matter what it precedes.

This is an argument.

I welcome your response.

created and maintained by one single developer (stephan).

The things were created within the last few months. I'd assume anyone with a dev account is free to modify things. Just because no one has done that doesn't mean it will not get done. Does it?

stephan also makes clear that he will be the one to decide about the future of the Fossil UI -- likely further pushing his "mobile-first" (and sometimes almost "mobile-only") philosophy, which doesn't always fit nicely for people primarily working with desktop systems.

I certainly see no evidence of this.

I prefer the simplicity of Fossil, and I think this is something worth to take care of!

Has Fossil become less simplistic with the enhancements?

Command line browsers can't be used for update anymore (no js). One feature phone I have hangs trying to edit a wiki page that I was able to edit before I upgraded fossil (probably missing js function, there is no debugging console so...).

Huge issue, well no. I have alternatives and can copy files back to my primary desktop to post. Data costs where it $ per kb have gone up due to transfer of js plus data to be edited as opposed to only the data that has to be edited. Again not a big issue for me.

So it has raised the bar on the clients that can access/use key elements of fossil.

I have no opinion on any of the issues raised here, except to make one correction. Yes there is a commandline browser that has JS: http://edbrowse.org/ . It isn't Lynx (which is a screen browser, not a commandline browser) but it does have JS, which is impressive.

Accessibility matters to me and is one of the most egregious fails of Github (to their credit, they are actively talking to me about the multi-level failures and they want to fix it.)

Dan

Accessibility matters to me and is one of the most egregious fails of Github (to their credit, they are actively talking to me about the multi-level failures and they want to fix it.)

An accessibility review/overhaul/rework has been brought up here several times - at least once by Florian. It's just waiting on someone to be itched by it enough to scratch that it.

Thanks for the link to edbrowse. Very neat.

Command line browsers can't be used for update anymore (no js).

Sorry, I don't know what this means. cli browsers can't browse the repo anymore?

One feature phone I have

This seems to go against what Florian declared:

likely further pushing his "mobile-first" (and sometimes almost "mobile-only") philosophy, which doesn't always fit nicely for people primarily working with desktop systems.

At any rate, thank you for your insights into the limitations you have found.

My opinion is the changes Stephan have made are improvements and welcomed by me.

Frankly, it seems like people want Fossil improved more, with the ability to add pictures into Fossil forum posts: https://fossil-scm.org/forum/forumpost/ff8ae17f30. Remember when we didn't have markdown support? Now we do!

Are we going to have a conversation in a few weeks about how this isn't good for various reasons?

cli browsers can't browse the repo anymore?

Sure they can, just not pages implemented in JS (wikiedit, fileedit, and next on the list is the forum (which i have Richard's approval to do)).

Text-mode browsers are emergency fallback solutions useful in very limited contexts. They can't do social media, they can't order goods on Amazon or Etsy, and they can't edit a wiki page in fossil as of version 2.12.

As a both pro-some-nicer-features, but also a pro-text-only-browser (and maybe also slightly to blame for the extra JS :-); I have to disagree that text only browsing is a emergency option. I personally use it very often - it is a perfectly adequate system when going over an SSH link or similar.

Fossil is alas barley usable with such browsers, most notably the branch page which is an important page. And that is the case for several pages when visiting from say EWW (Emacs web browser). There are also other minor problems, like the menu becoming truncated and no means of expanding it, which means that the Files page is missing. (I haven’t reported those quibbles simply due to lack of time)

So I’ve actually come to use my phone (which is slightly annoying with the context shift) as an emergency browser, since the experience is quite nice there. The wiki page editing is also very much appreciated, since it does make quick edits so quick (desktop, or mobile). Ditto with line numbers.

I think it’s just a matter of time and willingness to get things usable for both sides. And if time exists. I’d be happy in seeing that fossil is usable in a non-JS setup, but equally happy and thankful that it is very nice to use in a full blown browser.

[text-only browsers are] perfectly adequate...over an SSH link or similar.

I live in SSH, to the point that my company keeps a maintenance contract for a commercial GUI SSH client, as it provides many valuable features over Terminal + OpenSSH.

I say this to frame this question: Over SSH, why wouldn't you either use Fossil CLI or port-forward fossil ui through SSH so you can use a local browser against the remote Fossil instance? (e.g. ssh -L 9090:localhost:8080 to cause local browser conns to http://localhost:9090 to tunnel TCP port 8080 on the remote host through SSH.)

You can even use SSH as an adequate VPN alternative with OpenSSH's -D option, so that visiting http://localhost:8080 with the SOCKS tunnel established via your host's network stack or browser settings will connect through the tunnel to the remote machine.

Given these affordances, I simply don't see why someone would put up with text-mode browsers.

Enlighten me?

the menu becoming truncated and no means of expanding it, which means that the Files page is missing.

The trick is working out how to detect that the browser is only 80 columns (or whatever) wide either from the server side or client-side JS so we can apply suitable CSS rules to force the menu item into the "correct" location in the menu, by your lights.

I don't think we want a user report here, I think we want a tested-as-working proposed fix, so we have something to discuss.

Enlighten me?

Because our workflows aren't the same; caveat emptor, I'm a heavy Emacs user and spend most of my time there and it is normally running full screen. I use laptop most of the time, and have bad enough eyesight that I cannot use the tiny modern fonts to squeeze Emacs, Firefox, and what not into the same screen -- and I doubt I would want to do that anyway since it becomes messy.

Being able to click on a link in an email (which I read in Emacs), and get it opened in a buffer in Emacs is immensely convenient -- even if I am running Emacs in X11. Otherwise, there is a significant context switch for me, where focus goes to a Firefox window and then I have to go back instead of having all information on the same screen.

Having everything in the same program also means that I do not need to shift to a different program to for example cut and paste text, or view documentation (be it web based, man pages, info, or a README) since I can organize my Emacs to show what I need depending on a situation.

I also cannot do port forwarding on some sites (and its an extra annoying step).

I often also use use a text-only display which is distraction free -- and being able to look at the timeline, view tickets or forum posts without switching to X11 is just one thing that makes computing more enjoyable and less of a headache.

Does that somewhat explain things?

This is a typical computer screen for me, not to scale, all in the same Emacs window:

+--------------------+-------------------+
| int                | Compilation       |
| main(void)         | Test output       |
| {                  |                   |
|   printf("foo");   |                   |
|   return 0;        |                   |
| }                  +-------------------+
|                    | Fossil timeline   |
|                    | Shell or some     |
|                    | other useful      |
|                    | data              |
|                    |                   |
+--------------------+-------------------+

The fossil timeline, or the compilation output, I change back and forth to different buffers very actively be it to a shell, some random text files, or scribble notes. This fits nicely on a 160x40 text display, or in X11 with large fonts. In X11 you also have the ability to display pictures -- so maybe the discussion shouldn't be about "text-only" but rather "no-JS"...

On Thu, 20 Aug 2020, 07:14 Warren Young, noreplycf829f041@fossil-scm.org wrote:

https://fossil-scm.org/forum/forumpost/4af9c9a808

[text-only browsers are] perfectly adequate...over an SSH link or similar.

I live in SSH

    :

why wouldn't you either use Fossil CLI or port-forward fossil ui through SSH so you can use a local browser

   :

Given these affordances, I simply don't see why someone would put up with text-mode browsers.

One reason is because users often must put up with cranky browsers, be they text-mode or outdated or non-mainstream GUI browsers. Maybe not for the Fossil web ui, but many of the most common things a developer uses including Github and even the Mozilla pages are not viewable by a lot of people. All of the major GUI browsers have regressed in aspects of their accessibility metrics over the last few years.

Here is an example that is easy to verify.

Contrast, typically high-contrast, is an extremely common requirement and ought to be an easy technical problem to solve. In principle it's a matter of reversing black and white colours. But the current crop of mainstream browsers can't even do that reliably.

It is not possible to tell a recent Firefox to override the white background enforced on many web pages (including on some vital Github pages including for authentication.) White backgrounds induce physical illness in many people. You can use an inverted/dark Gtk theme, you can use the system Gtk theme, you can install contrast plugins, run in Firefox's high-contrast mode, tweak undocumented settings in your own custom-compiled Firefox... but still it is common to be ambushed by essential webpages blasting white and therefore causing illness (which is not even legal for many companies to use according to accessibility legislation in many countries, but it continues nonetheless.) Even worse, because providing the user control over contrast is not a release requirement it is not tested. So the next stable version of Firefox will require different magic to get to the same incomplete browsing experience. The process of learning whether or not a browser version has improved can take days of fiddling, so it eats away at resolve people who have the bad luck of needing to see things as white-on-black rather than black-on-white. Chrome is different but no better.

And that, in a nutshell, is why people would bother with text mode browsers. Because they have no choice, and because giant well-funded organisations ignore their statutory duty to make their websites and web tools accessible.

There is also the delightful brow.sh solution. The author hasn't found time to work on it for a year, but has demonstrated that it is viable to put a text front end onto a current browser rendering engine complete with Javascript.

A very big accessibility step is making sure that every Fossil feature has a commandline version, which Fossil more-or-less does today, so that's great. Javascript is important, but not everyone will be able to use it.

Best,

Dan

i'm responding to several different posts here, sometimes out of order - my apologies for the loss of context about exactly who said what in which order.

Also, my apologies for the length. To summarize what's said below:

• All new code is abundantly documented, tightly modularized, and all developers are free to improve up on it.
• Concerns about the "weight" of the JS code are completely unjustified - see below for why.
• i consider the long-term well-being of the project to hold infinitely more value than how i personally feel about Feature X, and i have a corresponding level of interest in seeing it remain relevant in a world which never stops moving forward.

Now, down the rabbit hole we go...

Quite a lot of it is documentation, and for some functions the comments even exceed the code in size. 4K of typical Web3.0 JavaScript would give us cause for concern (especially if it's minified), but 4K of well-written and documented JavaScript is probably much less alarming.

Not only is it 1/3 - 1/2 documentation, but the build process strips that out. Not only that, but the new "jsmode" options Richard added allow all JS for a page to delivered in 1-2 HTTP requests and to make them cacheable for a whole year, so that "whole 4k" (or 8k, in the case of our largest page - /fileedit) has an aggregate cost far smaller than doing only a few full server-side round trips of roughly-equivalent static pages.

As far as "well-written" goes, every single developer is invited to help improve the code in that regard. (So far that oft-repeated sentiment has not inspired anyone else to commit changes to the new JS code.)

My guess is that nobody will be able soon to understand the library and produce reasonable code using it, due to its sheer complexity

a) If someone is failing to understand how to use it, it's not documented well enough and that's something easily fixed. i enjoy documenting code. If they're not understanding it because they're not up to date on reasonably modern JS, then that's something they can fix if they like.

b) The modular approach of the fossil.XYZ APIs is inarguably far more readable and coherent than the hodge-podge of global functions we currently have for functionality like the copy button, and it's fully documented. By comparison, it took me more than half an hour to reverse engineer the copy button code, whereas we now have a single, documented function call to set up a copy button anywhere on the site (that module contains literally more documentation than code).

The things were created within the last few months. I'd assume anyone with a dev account is free to modify things. Just because no one has done that doesn't mean it will not get done. Does it?

100%.

stephan also makes clear that he will be the one to decide about the future of the Fossil UI -- likely further pushing his "mobile-first" (and sometimes almost "mobile-only") philosophy, which doesn't always fit nicely for people primarily working with desktop systems.

I certainly see no evidence of this.

100%. i have always made explcitly clear that anyone is free to modify the code. And if i haven't said this before, i'm saying it now: this is not "my" code. It's the project's code, written with the long-term well-being of the project in mind. My firm opinion is...

likely further pushing his "mobile-first" (and sometimes almost "mobile-only") philosophy

... mobile has a high priority, especially for the forum. A platform which does not support mobile devices has already lost, in that it cannot compete against platforms which do.

Mobile-friendly editor apps are, IMHO, more important than desktop-friendly ones because people at their desktops have the option of using their own preferred tools for the editing, whereas people "on the move" do not. i cannot count how many times i've been on my tablet and thought, "i wish i could tweak that doc, but it's either impossible (embedded docs) or too tedious to edit because all of the editor state gets lost on every preview (legacy wikiedit)."

The new features, like all features in fossil, were added to scratch someone's itch - in this case, mine. The ability to edit files directly online has been requested several times over the past decade, so it's clear the feature has value to some users other than myself.

As far as improving the interface for doing so goes: that's another case of waiting on someone who's itched by it enough to want to scratch it.

statements like "regardless of feedback, the final implementation decision lies with whoever is writing the code"

That was simply a reminder of that core-most, normally unspoken, law of coding, especially in FOSS projects. We're not given a list of coding tasks and we're not told how to perform them. We write the code we would like to see in the project when and how we would like to see it written.

i've volunteered on this project for a full quarter of my life and i have a correspondingly strong interest in seeing it survive and thrive. Though my decisions made with regards to the project are demonstrably sometimes seriously flawed, they are always made with the long-term well-being of this project in mind (without losing site of "the road to Hell is paved with good intentions").

For example, I don't understand why I'd want to run more than 800 lines of Javascript code each time I'm viewing a file in the web UI and would like to see the line numbers

That's debating the use of JS out of principle, not technical merit. Though i can sympathize with defending one's principle's, let's honestly ask ourselves:

Q) Do those 700-odd lines of code negatively impact the visible experience of the page? (The other 100-ish lines is legacy/skin stuff.)

A) No. A human being's reaction speed is tens- or hundreds of times slower than would be needed to notice any negative visual impact of this trivial amount of JS code on any desktop-grade or mobile-grade computer. These pages are made for humans to process, not machines, and a handful of milliseconds of processing time is effectively invisible to humans.

Q) Did those 700-odd lines of code noticeably impact the download speed?

A) No. Not only are the JS downloads in the single-digit-kb range, which is not even much by 56k modem standards (much less connections of 1MBit or higher), they're cached for up to a year.

Sidebar: the main fossil site currently inlines that code, adding it to every page request, but Richard made mention the other day off-list that he's considering switching to bundled mode by default, which would eliminate any and all arguments about repeated download costs. That would require no code changes - it's server-side configuration toggle. All of my own repos use bundled mode except when testing new code.

Aside from anti-JS principles, or pro-static-HTML principles, both of which i can sympathize with to some degree, i see literally no justification for the "let's keep it static" debate. It's grounded in historical ways of doing things, and i would very much like to see this project move well, well past that.

Anyone in this audience is more than welcomed to write static HTML-based pages for fossil. That's not the direction i'm going, so long as i have Richard's blessing (which i have, at least through the next planned phase of changes in the forum).

(aitap said to Florian...)

Despite finally getting my Contributor Agreement to D. Richard Hipp some time ago, I somehow haven't been able to find the time to resurrect the pre-AJAX Wiki editing page and offer a patch providing it as a <noscript> fallback. Would you be interested in maintaining fallback interfaces for Fossil together?

For what it's worth, you two have my utmost blessing to do so: i'm not going to contest someone else getting in and writing the code they feel benefits the project, so long as i don't also feel that the feature really, truly doesn't fit for some debatable technical reason.

i have publicly said, from the moment the porting of wikiedit to JS started, that i was not (and still am not) personally interested in maintaining two copies of that app, and that if someone wanted to retain the static one then they should feel free to do so. This commit shows precisely which parts were removed, so all of the relevant code is in one place.

PS: that was very nearly 2 hours of writing, rewriting, and re-re-re-re-writing i had wanted to spend working on the "js policy" docs.

Thanks for all the interesting messages! This is a reply to several different posts.

... but 4K of well-written and documented JavaScript is probably much less alarming.

It's 4K of LINES.

Would you be interested in maintaining fallback interfaces for Fossil together?

To some degree, maybe. But I'm not really looking for a truly <noscript> version, but for a way to keep the new heavy Javascript libraries off of simple and light-weight pages like /file or /artifact if line numbers are enabled. But since the simple code is already there, maybe compile-time directives (enabled-by-default) could determine whether the user prefers the fancy version, or the simple light-weight variant.

The things were created within the last few months.

No, because somewhere stephan said: "Much of it originated from my «personal toolbox» which has been schlepped around/developed for my sites the past 10-ish years." So it's not something that has organically grown with the requirements of Fossil -- it's more like throwing in a complex framework developed over 10 years, not known to anybody but the creator. So this feels much more like jQuery than like plain simple Vanilla Javascript.

Has Fossil become less simplistic with the enhancements?

In my opinion: yes. I don't need, and I don't want a wiki editor with almost as many features as my GMail web client! (And, did I mention that with my GMail web client, I can do everything with the keyboard?)

The modular approach of the fossil.XYZ APIs is inarguably far more readable and coherent than the hodge-podge of global functions we currently have for functionality like the copy button, and it's fully documented. By comparison, it took me more than half an hour to reverse engineer the copy button code, whereas we now have a single, documented function call to set up a copy button anywhere on the site (that module contains literally more documentation than code).

Reverse engineer? But did you notice src/copybtn.js, with the comments on top?

Everything about the "old" copy button can be controlled by only one single JS function (makeCopyButton(), used by the timeline tooltip) or C function (style_copy_button(), also accessible via the embedded TH scripting language).

So I really don't see what's better about your new version -- which seems to have a broken and inconsistent animation, anyway -- except that it's more (and more fancy) code?

Also, I really don't see the problem with JS globals, if all Javascript code is managed in the same project -- and wrapping the "old" copy button in a "namespace object" or "class" wouldn't be that difficult to justify the use of a full framework as a replacement?

Mobile-friendly editor apps are, IMHO, more important than desktop-friendly ones ...

...

I'm on your side from the standpoint of avoiding a mobile-first Fossil UI. That requires a paucity of design and expressiveness that harms desktop use.

However, that is not the same thing as saying we want mobile-unfriendly software.

I'm not saying the Fossil web UI should become mobile-unfriendly -- but it's my impression that it is becoming desktop-unfriendly!

For example, compare these two web forms:

• https://imgur.com/a/8EnAhMx

In the first form, all the controls look nice without any CSS, and visual orientation is easy due to consistent vertical alignment and putting each control on a new line.

In the second form, all the form controls (except buttons) are wrapped together with their labels in dense black borders, and then all squeezed into one single line, generating a tight tangle of lines which makes visual orientation unnecessarily difficult, and the form harder to use. (This is presumably because extra spacing has to be added between the form controls, so that they can be "tapped" with the finger tips, or maybe during winter with a Currywurst, what do I know?) And, did I mention (yes, I did) the nagging tooltips for form controls that already have text labels -- really very uncommon for desktop environments, but mobile users are spared?

The things were created within the last few months.

No, because somewhere stephan said: "Much of it originated from my «personal toolbox» which has been schlepped around/developed for my sites the past 10-ish years." So it's not something that has organically grown with the requirements of Fossil -- it's more like throwing in a complex framework developed over 10 years, not known to anybody but the creator. So this feels much more like jQuery than like plain simple Vanilla Javascript.

First, a correction from me. Things were put in branches and made publicly available within a few months. It was conjecture on my part to assume Stephan was developing the features right before us, though it did have that appearance.

Now are you saying someone who has been working on/with Fossil for a considerable period of time cannot have prototyped things out, even if it's something you're not pleased with? I don't know enough about the technology to know jq vs. plain vanilla to understand why you're opposed. I suppose because it's complicated, but it seems someone of your skill set would be able to review the changes in an afternoon and get acquainted with it.

For example, compare these two web forms:

I get you don't like the enhancement to the wikieditor, but comparing these two pages doesn't make much sense. They have completely different layouts.

I really hope your request isn't "Don't change anything. ever."

It's 4K of LINES.

I don't know how you came to that number. I got a considerably smaller number, though it is still worrisome. Let's take that topic up on the other thread, though.

maybe compile-time directives (enabled-by-default) could determine whether the user prefers the fancy version, or the simple light-weight variant.

That means maintaining two parallel feature sets. Stephan doesn't want to do it. I don't know anyone else who does. Maybe you?

this feels much more like jQuery than like plain simple Vanilla Javascript.

I'd rather discuss the new library's size, performance, and functionality rather than its provenance.

Fossil is a do-ocracy: he who does the work makes the rules. To reject the code's origin is to reject its originator. Do you really want Stephan to give up working on Fossil because his creations are being rejected outright, rather than riffed on and improved?

It's fine to bring objections, but please also bring solutions.

almost as many features as my GMail web client!

Since Gmail ships about 1 megabyte of compressed and minified Javascript, I don't see how we can treat that observation as anything but hyperbole.

it's more...code

Not unless you're counting comment and blank lines:

$ cloc src/copybtn.js ; cloc src/fossil.copybutton.js 
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
JavaScript                       1              0             27             72
JavaScript                       1             19             55             42

I really don't see the problem with JS globals, if all Javascript code is managed in the same project

It isn't always. The Fossil administrator is free to inject additional JS code into their repository via the skin, and several of us do that. We reduce the potential of bad interactions if we don't pollute the global namespace.

dense black borders,

I agree that they're distracting. The same sentiment is behind my recent improvements to the collapser/expander CSS. I think both /fileedit and /wikiedit would benefit from CSS to make them blend better with each skin.

I may even get around to doing that someday.

You're more than welcome to beat me to it, though.

extra spacing has to be added between the form controls, so that they can be "tapped" with the finger tips

Yes, that's part of what it means to be mobile-friendly.

If you can work out a method to allow a more compact UI when not on a mobile touch-based platform, show the method.

Beware: if your solution involves UA sniffing, it'll likely be rejected.

Extra credit: Make your solution also work with a convertible Chromebook that can become an Android tablet by folding the screen back or detaching it.

Extra extra credit: Also placate EWW and Lynx.

the nagging tooltips for form controls that already have text labels

Indeed. I see no reason why we need "alt" text on text spans. That's going to either make a screen reader ignore the alt text or it'll give redundant narration.

It's 4K of LINES.

So let's minify it down to 1 line. Problem solved.

Lines are not a terribly useful measure, as many of them (10% in the JS currently on my screen) have only a closing brace or a brace plus semicolon.

Reverse engineer? But did you notice src/copybtn.js, with the comments on top?

The use of global functions in modern-day JS is an absolute no-no. At most, a single global-level symbol (a project namespace) is acceptable. So, yes, i very much felt compelled to tear that one down and re-assemble it into a modular, re-usable form which has literally more documentation than code:

https://fossil-scm.org/fossil/info/2b55d30d7a269ce6

You will never convince me that the legacy implementation is easier to read and maintain:

https://fossil-scm.org/fossil/info/d0763b44562b09c3

So I really don't see what's better about your new version -- which seems to have a broken and inconsistent animation, anyway -- except that it's more (and more fancy) code?

1. The animation was copied as-is from the old one and works 100% identically. The "broken animation" you're complaining about is that the popup disappears before the button's animation completes. So what?!? If you tap on that same button on the timeline and move your mouse away immediately, it does the exact same thing.

   • You often complain about extra code and complexity in the JS while also demanding "fixes" which require exactly that. Adding yet another timer to the popup's closing, just so that it's visually synchronized with the fade-out of the copy button adds, believe it or not, code and complexity (and corner-cases when the popup is activated again while that final timer is running, leading to more code and complexity to solve a bug introduced by the "fix").

2. The animation can now be applied to any DOM element, not just the copy-to-clipboard button to which it was hard-coded, and has a programmable duration (defaulting to the same value used by the timeline).

For comparison:

Old "blink" impl is burried somewhere in here: https://fossil-scm.org/fossil/info?ln=54-81&name=d0763b44562b09c3

New "blink" impl: https://fossil-scm.org/fossil/info?ln=494-518&name=dd4f9c08237019f5

No, because somewhere stephan said: "Much of it originated from my «personal toolbox» which has been schlepped around/developed for my sites the past 10-ish years." So it's not something that has organically grown with the requirements of Fossil

"Originated from" did not mean "copied over as-is, with all of its cruft." Ported over from my personal toolkit were exactly 2 files: fossil.dom.js, which fossil's new apps make full use of, and the fossil.confirmer.js (confirmation buttons), which fossil also currently makes use of (until someone creates a platform-portable HTML/CSS popup alternative).

Both are well-tested and well-documented.

In the first form, all the controls look nice without any CSS,

You lost me at "without any CSS." That mode of operation is of exactly zero concern to me.

In the second form, all the form controls (except buttons) are wrapped together with their labels in dense black borders, and then all squeezed into one single line, generating a tight tangle of lines which makes visual orientation unnecessarily difficult

1. i have never claimed to be a good UI designer (and have often claimed the opposite).

2. Patches/commits are welcomed.

and the form harder to use.

1. That's one opinion, but it's not the opinion of the one who wrote the UI and who has spent more on-screen hours with it than anyone else.

2. Patches/commits which improve your UI experience are welcomed.

My 3 most-used apps are bash, emacs, and a browser, so my own expectations for UIs are quite low. Any improvements you can make to them, feel free to make.

The use of global functions in modern-day JS is an absolute no-no. At most, a single global-level symbol (a project namespace) is acceptable.

Apologies for the topic drift, but could you give me a link where this idea is explained? No need to spend time explaining it yourself, just a link.

Context: I've been tasked with making an interactive plot on a web page, and while it currently works well, I'd like to make it more maintainable. I've been reading Eloquent JavaScript, but it doesn't elaborate on the architecture of web applications. Recently I reduced the global namespace usage to three helpers (a-la jQuery's $) and two objects managing the state of the form and the plot, but your message tells me I might need to reduce it further.

Apologies for the topic drift, but could you give me a link where this idea is explained? No need to spend time explaining it yourself, just a link

i have no link, but have worked with JS on and off for some 22 years, during which globals have repeatedly proven to be unmaintainable, especially when working with/taking over someone else's code. Googling for "avoid globals in Javascript" reveals many articles on the subject (none of which i have read, so don't have specific recommendations). Having at least one global is practically unavoidable for most apps, but one per app/library is really all they need. jQuery, for example, introduces only one, despite including tons of functionality.

The more modern browsers support what they call "modules", which allows code to be structured in a way which avoids having even a single global variable, but it involves new syntax and its support is still not widespread enough for us to be able to rely on.

Since we can't reasonably get away (in our particular environment) with having zero custom globals, the newer fossil JS code injects a single global named, strangely enough, fossil, and all of its APIs get installed in that object. Certain types of apps can be completely encapsulated in a single anonymous function, potentially allowing them to work without introducing any globals. Those apps are typically either relatively small or use a tool like require.js to load any dependencies dynamically from within a tighter scope.

it's more...code

Not unless you're counting comment and blank lines ...

Aren't the dependencies missing in this balance?

• src/copybtn.js: none.
• src/fossil.copybutton.js: the general part of the new framework (for the F.* and D.* functions).

Adding code for that level of UI micromanagement is, IMO, in nobody's interests.

Nobody said that UI programming is easy ;-) and unfortunately, it's a lot about such micromanagement.

Consider the timeline tooltip: There's independently managed "dwell" and "close" timers, to make sure the tooltips won't be annoying and pop up too early, and to "stabilize" them if the hovered timeline rail is accidentally left but quickly re-entered with the mouse, so they won't be jumping around. Both timers are reset and/or cancelled as needed, also for example by ESC, to prevent them from "overlapping". Also, the tooltip can be shown by clicking the timeline rails on mobile devices (the click action for the nodes has already been assigned to select/deselect them). That's the crispy stuff I love!

Consider forms: simple, or "linear", forms have good accessibility, such as an intuitive tab order, support for ENTER to trigger the default action, etc. More complex, or "non-linear" forms, especially with default buttons arranged on top instead of at the bottom as usual, or with more advanced elements such as tabs, no longer automatically get these handy accessibility features. It's quite some work to bring them back -- but in my opinion, a simple form is far more useful than a complex form lacking these standard features. That's another reason -- besides my general pursuit of simplicity -- why I preferred the old wiki editor.

Consider the new "Copy link to lines" popup: I still haven't found out the rules by which clicking would create, expand, or discard the selection. Also, having the popup window appear prominently on every click is very obtrusive in desktop environments, even more so because it can't be closed by ESC. Also, the popup covers the first 30 or so characters from the marked line, blocking visual verification whether really the desired line was clicked.

Maybe that's how things work on mobile devices, where there's no mouse hover actions, and no ESC keys, so the new feature is just "good-enough-for-mobile" -- but somehow feels makeshift and unfinished in desktop environments. That's why I think there should be a way to disable it.

To reject the code's origin is to reject its originator.

Not at all, that's by no means the intent! But, as outlined above, I fear that the Fossil UI will soon be cluttered with lots of "good-enough-for-mobile" widgets all over the place, driven by the new JS framework, an impair the clean, simple and user-friendly desktop experience.

I'm fine with people working only on features they need themselves, and can to some degree understand the reluctance to dive into the innards of UI programming -- but my point is that "good-enough-for-mobile" features have the side effect to damage the desktop experience!

now we have a huge framework library, around 4K(!) worth of lines

If you can get the current functionality into fewer delivered bytes of code — a far more useful measure than lines of code! — then I'm sure we're interested in seeing your patch.

The current whitespace, comment removal, bundling, ETags, and compression steps likely save a lot more bytes on the wire than you're guessing. Study what happens in your browser's developer tools' Network tab when --jsmode bundled is enabled. Compare the uncached first-load numbers to the cached second-load numbers. That's the arena your patch will need to compete within.

My guess is that nobody will be able soon to understand the library

That's one of the reasons I wanted to use an existing BSDish JS framework instead of building our own: so we'd have existing documentation and web resources to help us understand it, to get new developers on-board quickly with it, etc.

You were among those who argued against doing that, and now you're upset that we've got a one-off code base that you don't understand. You can't have it both ways.

Given that this is how it's come out, we certainly should have some documentation on the new framework.

The best way to learn how something works is to try to document it in a way that others will understand. It's why I'm now the user capabilities guru, for example. I got that expertise by studying the code and documenting what it does.

doesn't always fit nicely for people primarily working with desktop systems.

I'm on your side from the standpoint of avoiding a mobile-first Fossil UI. That requires a paucity of design and expressiveness that harms desktop use.

However, that is not the same thing as saying we want mobile-unfriendly software.

The only way to avoid having to tolerate some sort of balance between these forces here is to go mobile-only or desktop-only. I don't think either option will fly in today's world. Therefore, if you think we've drawn the line in the wrong spot between these two tensions, fine: say where you think it should be moved and how.

I don't understand why I'd want to run more than 800 lines of Javascript code each time I'm viewing a file in the web UI and would like to see the line numbers

I just profiled a /file page load here on my 6-year-old iMac, and it took about 4 ms to execute all of the on-load scripts on the page. All of them, not just this new line selection stuff. A human cannot even reliably perceive such a short execution time.

Clicking on two of the line numbers on the resulting page chewed up about 1.2 ms of execution time, which means you'd need to click about 833 times a second to cause a bottleneck with that code.

You also make this complaint without apparently considering the alternative: a server-side round trip per click, which would likely cost orders of magnitude more, given the nature of the World Wide Wait.

such a complex Javascript application should be split into a separate, enhanced Fossil web UI application, to keep the Fossil core simple and compact.

That's been tried before. All third-party Fossil GUI and "Fossil light" efforts have fizzled due to lack of developer interest. It's clear now that we only have sufficient developer attention to maintain a single code base.

If you believe I'm wrong, you are most welcome to show us how it is done. :)

That's one of the reasons I wanted to use an existing BSDish JS framework instead of building our own: so we'd have existing documentation and web resources to help us understand it, to get new developers on-board quickly with it, etc.

To be clear, though, there's nothing in our framework which prohibits or inherently excludes the possibility of jQuery and there is, in fact, very little functional overlap between the two. Most of our JS is functionality we need whether or not jQuery is there, so it would need to be written one way or the other.

which means you'd need to click about 833 times a second to cause a bottleneck with that code.

Someone out there will do it, just give it time ;).

That's been tried before. All third-party Fossil GUI and "Fossil light" efforts have fizzled due to lack of developer interest. It's clear now that we only have sufficient developer attention to maintain a single code base.

If you believe I'm wrong, you are most welcome to show us how it is done. :)

It "would indeed be cool" to have separate all-static and all-mobile and all-desktop interfaces, but that's simply not practical in this project. We don't have the person-power to maintain such combinations.

Here are my thoughts on the JS usage on Fossil. I personally am not against JS but I would prefer not to use it. I was thinking about the /fileedit feature added recently and I would not personally use it.

Honestly I think that who made it has done a great job, but I don't think that it's useful in this context: this feature seems like the file edit page on GitHub that I think no one uses because it is much more comfortable editing files via git itself (not a git fan). The same reasoning applies here: my workflow would be to modify a file locally and push the checkin to the server, not editing the file on the server itself, I am much more comfortable in my editor of choice (not disclosed to avoid a religion war ;) ). This does not mean that the feature itself is useless.

I think that the fossil core server itself should be as light as possible, and adding this type of feature (JS heavy / ajax) is against this. Maybe I think someone should make (if this type of interface is required) a standalone Fossil server with all the JS that one wants, completely ignoring the integrated server and using the repo only for the data, achieving a GitHub-like experience.

p.s: not a native english speaker, so sorry for any english horrors.

Did you modify files in the wiki with the old editor, or have you always edited files locally and pushed changes up?

I've always used fossil wiki create to create my wiki file in a text file, then push it to the server (if present).

To modify it, I have an elisp fn (revealed my editor, lol) that exports the wiki page with fossil wiki export and puts it in a buffer. I make my edits and then use fossil wiki commit to update the wiki page. Never used the integrated fossil wiki editor.

What process of yours has now changed?

In reality nothing has really changed for me, my original message was just a philosophical type of thought. Just my feedback and my two cents on new features. I'll continue to use what I've always used :)

Good to know. Thanks for your feedback!

To modify it, I have an elisp fn (revealed my editor, lol) that exports the wiki page with fossil wiki export and puts it in a buffer. I make my edits and then use fossil wiki commit to update the wiki page. Never used the integrated fossil wiki editor.

Funnily enough... the wiki CLI commands were the first (or very close to it) new command i added to fossil, back in 2008, and "wikiedit 2020" is the most recent. i'm thrilled to hear that someone is using it from vi ;).

I think that the fossil core server itself should be as light as possible, and adding this type of feature (JS heavy / ajax) is against this.

On the contrary, JS and ajax offload work from the server to the client. More JS means, almost as a rule, less C. The binary is definitely heavier because fossil, unlike most apps, compiles the JS code directly into the app, but the load on the server is demonstrably less than the equivalent static pages.

/fileedit, for example: the main page simply emits the HTML skeleton and the JS, then tells the JS to do the rest. The logic of fetching, previewing, diffing, and committing files, then lives in single-purpose, UI-agnostic routines, completely separated from the UI code and each other. That's undeniably a cleaner approach: if you go back and look at the static HTML implementation (the left side of that diff) you'll see that the UI, the form handling, and all of the other features, are tightly tied together in a single monolithic function.

I agree that it might be nice to have something like the old-style 'plain-textarea-and-clickthrough-to-preview' option as an alternative for /wikiedit, but I think both it and /fileedit are great and they look like they will fit my use cases very well :)

Am currently too time-poor to read through all the JS-related threads and try to add to a proper response. Need to free up some reading time and do more experimenting rather than try to rush over what's likely old ground now - but wanted to add a quick voxpop to say that if the forum supported emoticons/emojis (please don't ever add that), I would post a long and effusive string of them in praise of /fileedit and /wikiedit.

As soon as I have time and as soon as the bug with cloning on Windows is fixed, I'll be moving to the latest version so that I can play with it more.

Totally off-topic, "--workdir" for "fossil open" is also a great addition.

but wanted to add a quick voxpop to say that if the forum supported emoticons/emojis (please don't ever add that),

🆗

In all seriousness, emoji's can be useful. Check out Andy's chart. ascii can work for that, but having simple symbols for it makes the representation easier to see.

One thing I mentally tater-totter on is a way to +1 a post, most commonly seen in reddit, but it had origins before reddit. I think it could be beneficial to show admiration to someone's post, as they contributed something nice to the community. As an example, Keith's post on SQLite about a csv extension he made available to the community.

However, I'd rather not see discussions be driven based on who gets the most upvotes. So in the end, let's not add that into our forum!