decouple HTML from HTTP

Where are you seeing that they're coupled? Fossil's HTTP implementation is largely in cgi.c and http.c, whereas the bulk of the HTML is in style.c and the files it pulls in.

Perhaps this is just another way of getting to your later complaint about HTML being admixed with C using the @ preprocessing layer, but we'll get to that shortly.

JavaScript to a directory

Okay, say we move src/*.js to src/js. What did that buy us?

Don't prescribe; persuade.

scripting language u or users want to generate a preprocessed HTML

Writing in standard English would be more persuasive.

That aside, are you aware of Fossil's TH1 features? What does that not get you that you want from this vague alternative you're wanting?

generate a preprocessed HTML

We already do that — see §4.2 in particular — only it's server-side rather than client-side.

If you're arguing for Your Favorite Scripting Language over C, that gets you into a language war tarpit that isn't likely to result in a productive discussion.

But hey, if you want to attempt to launch yet another advocacy campaign in favor of PHP or Perl or Python or Ruby or or or…go right on ahead! Just don't expect it to gain much traction here.

use javascript to fetch some content

This seems to be a wish for pure client-side rendering, with all the raw data pulled via JSON and such then rendered into final presentation form at the last instant.

That would defeat Fossil's skinning feature unless you rewrote all of that to do it client-side instead of in style.c, where it's shipped as finalized HTML.

Also, it'd violate the current JS policies, which dictate that every function that requires JS have another way of doing things, ideally still through the web UI. To go down the path that you suggest, every one of the anti-JS holdouts — and beware that Fossil's minimalist nature attracts an outsized proportion of them — would be forced to use the CLI only.

While there are a few features currently in Fossil that absolutely require JS — e.g. /fileedit — they tend to be of the sort where you'd normally want to be using the CLI anyway, and the feature is giving an atypical alternative, not outright replacing existing no-JS mechanisms. In such cases, this JS-only alternative is optional, thus ignorable by the small but noisy anti-JS lobby.

Fossil does have a JSON API, atop which you're welcome to build a PWA or SPA or whatever other TLA you prefer. Doubtless the API would need extensions to allow full functionality from client-side JS code, but I don't see that such enhancements would be rejected in principle from "go." We'd have to see what you wanted to add before we could even begin to get to reasoned critiques.

split the source of the fossil in a couple of dirs.

How many, along what lines, and ultimately, why?

I'm not against the basic idea. What I'm getting at is that a concrete plan would be more useful than this vague wish. Give us something substantial to nosh on, not vaporous nothing-burgers.

A good structure of source code allows users to have a quick view of the overall design

I'd argue that we already have that. There aren't all that many rules that you need to learn to work out how to find the implementation for a given feature in Fossil. It's among the clearest to understand FOSS source code bases I've worked on.

One key rule is to start with the command ($CMD) you're investigating, then see if src/$CMD.c exists. If you find that lo, there it is, you're likely well on your way to your latest code spelunking adenture, having found the cave's entrance in seconds.

From there, begin reading the code, leaning on your favorite code-jumping tool set. Fossil comes out of the Unix world, where you run make tags and then lean on ctags and cscope via Your Favorite Programmer's Text Editor/IDE, but how you prefer to follow call chains to discover how a given source base works is a skill so fundamental to being a programmer that it's completely off topic here. Use what works for you.

There are exceptions, where a given feature isn't in an obvious place, but that's largely covered here, from which you learn how to apply your favorite grep type facilities to do the code-searching you need in order to find further code caverns.

I'm stopping my reply here, because I'm now up to nine links into the source and documentation, and I can't be bothered to extend it into the double digits. It's pretty clear you jumped into this topic without consulting the docs first, which makes me wonder if you're more interested in arm-twisting everyone else around to your preconceived design opinions than in working with a long-established FOSS development (dis)organization like you find here.

Show us that you're attempting to work with us, and we'll be more likely to work with you.

But hey, if you want to attempt to launch yet another advocacy campaign in favor of PHP or Perl or Python or Ruby or or or…go right on ahead! Just don't expect it to gain much traction here.

To add to Warren's exceptional response: libfossil, a 3rd-party effort (noting that the developers are also fossil devs), was designed from the beginning to be embedable in scripting engines, and anyone who's seriously looking to add fossil features to their favorite scripting engine is encouraged to look there.

One key rule is to start with the command ($CMD) you're investigating, then see if src/$CMD.c exists. If you find that lo, there it is, you're likely well on your way ...

From there, begin reading the code, leaning on your favorite code-jumping tool set. ...[for example] make tags and then lean on ctags and cscope via Your Favorite Programmer's Text Editor/IDE, but ... Use what works for you.

There are exceptions, where a given feature isn't in an obvious place, but that's largely covered here, from which you learn how to apply your favorite grep type facilities

Thank you. I imagine this same pith info is in the docs too, but I either didn't see that bit or saw and didn't absorb. Generous of you to say it again, and also for spending probably 3:1 ratio of time spent on reply vs opening post.

--A different Anony Mouse