Fossil

disabled. In every place where Fossil uses JavaScript, it is an
enhancement to provided functionality, and there is always another way
to accomplish a given end without using JavaScript.

This is not to say that Fossil’s fall-backs for such cases are always as
elegant and functional as a no-JS purist might wish. That is simply
because [the vast majority of web users run with JavaScript enabled](#stats),
and a minority of those run with some kind of [conditional JavaScript
blocking](#block) in place. Fossil’s active developers do not deviate from that
norm enough that we have many no-JS purists among us, so the no-JS case
doesn’t get as much attention as some might want. We do [accept code
contributions][cg], and we are philosophically in favor of graceful
fall-backs, so you are welcome to appoint yourself the position of no-JS
czar for the Fossil project!




Evil is in actions, not in nouns: we do not believe JavaScript *can*
be evil. It is an active technology, but the actions that matter here
are those of writing the code and checking it into the Fossil project
repository. None of the JavaScript code in Fossil is evil, a fact we
enforce by being careful about who we give check-in rights on the
repository to and by policing what code does get contributed. The Fossil
project does not accept non-trivial outside contributions.

    The heaviest such pages served by Fossil only have about 8 kB of
    compressed JavaScript. (You have to go out of your way to get Fossil
    to serve uncompressed pages.) This is negligible, even over very
    slow data connnections. If you are still somehow on a 56 kbit/sec
    analog telephone modem, this extra script code would download in
    about a second.

    Most JavaScript-based Fossil pages use less code than that.

    Atop that, Fossil 2.12 adds new script delivery methods with
    aggressive caching enabled so that typical page loads will skip
    re-loading this content on subsequent loads. These features are
    currently optional: you must either set the new [`fossil server
    --jsmode` option][fsrv] or the corresponding `jsmode` control line
    in your [`fossil cgi`][fcgi] script when setting up your
    [Fossil server][fshome]. That done, Fossil’s JavaScript files will
    load almost instantly from the browser’s cache after the initial
    page load, rather than be re-transferred over the network.

    Between the improved caching and the fact that it’s quicker to
    transfer a partial Ajax page load than reload the entire page, the
    aggregate cost of such pages is typically *lower* than the older
    methods based on HTTP POST with a full server round-trip. You can
    expect to recover the cost of the initial page load in 1-2
    round-trips. If we were to double the amount of JavaScript code in
    Fossil, the payoff time would increase to 2-4 round-trips.

2.  “**JavaScript is slow.**”

    It *was*, before September 2008. Google's introduction of [their V8
    JavaScript engine][v8] taught the world that JavaScript need not be
    slow. This competitive pressure caused the other common JavaScript
    interpreters to either improve or be replaced by one of the engines
    that did improve to approach V8’s speed.

    Nowadays JavaScript is, as a rule, astoundingly fast. As the world
    continues to move more and more to web-based applications and
    services, JavaScript engine developers have ample motivation to keep
    their engines fast and competitive.

    Once the scripts are cached, Ajax based page updates are faster than
    the alternative, a full HTTP POST round-trip.

3.  <a id="3pjs"></a>“**Third-party JavaScript cannot be trusted.**”

    Fossil does not use any third-party JavaScript libraries, not even
    very common ones like jQuery. Every bit of JavaScript served by the
    stock version of Fossil was written specifically for the Fossil
    project and is stored [in its code repository][fsrc].

    Therefore, if you want to hack on the JavaScript code served by
    Fossil and mechanisms like [skin editing][cskin] don’t suffice for your
    purposes, you can hack on the JavaScript in your local instance
    directly, just as you can hack on its C, SQL, and Tcl code. Fossil
    is free and open source software, under [a single license][2cbsd].

4.  <a id="snoop"></a>“**JavaScript and cookies are used to snoop on web users.**”

    There is no tracking or other snooping technology in Fossil other than
    that necessary for basic security, such as IP address logging on
    check-ins. (This is in part why we have no [comprehensive user
    statistics](#stats)!)

    Fossil attempts to set two cookies on all web clients: a login session

    *   ...[open source][flic] and [available][fsrc] to be inspected,
        audited, and changed by its users.

    *   ...compiled directly into the `fossil` binary in a
        non-obfuscated form during the build process, so there are no
        third-party servers delivering mysterious, obfuscated JavaScript
        code blobs to the user.

    Local administrators can [modify the repository’s skin][cskin] to
    inject additional JavaScript code into pages served by their Fossil
    server. A typical case is to add a syntax highlighter like
    [Prism.js][pjs] or [highlightjs][hljs] to the local repository. At
    that point, your trust concern is not with Fossil’s use of
    JavaScript, but with your trust in that repository’s administrator.

    a few of these part-timers are responsible for the bulk of the code
    in Fossil. If you want Fossil to support such niche use cases, then
    you will have to [get involved with its development][cg]; it’s
    *your* uncommon itch.

11. <a id="compat"></a>“**Fossil’s JavaScript code isn’t compatible with my browser.**”

    The Fossil project’s developers aim to remain compatible with
    the largest portions of the client-side browser base. We use only
    standards-defined JavaScript features which are known to work in the
    overwhelmingly vast majority of browsers going back approximately 5
    years, at minimum, as documented by [Can I Use...?][ciu] We avoid use of
    features added to the language more recently or those which are still in
    flux in standards committees

[v8]:     https://en.wikipedia.org/wiki/V8_(JavaScript_engine)


----

## <a id="uses"></a>Places Where Fossil’s Web UI Uses JavaScript

This section documents the areas where Fossil currently uses JavaScript
and what it does when these uses are blocked. It also gives common
workarounds where necessary.


### <a id="timeline"></a>Timeline Graph

Fossil’s [web timeline][wt] uses JavaScript to render the graph
connecting the visible check-ins to each other, so you can visualize
parent/child relationships, merge actions, etc. We’re not sure it’s even

[wt]: https://fossil-scm.org/fossil/timeline


### <a id="wedit"></a>The New Wiki Editor

As of Fossil 2.12, the [Fossil wiki][fwt] document editor requires
JavaScript for a few unavoidable reasons.

First, it allows in-browser previews without losing client-side editor
state, such as where your cursor is. With the old editor, you had to
re-locate the place you were last editing on each preview, which would
reduce the incentive to use the preview function. In the new wiki
editor, you just click the Preview tab to see how Fossil interprets your
markup, then click back to the Editor tab to resume work with the prior

WYSIWYG editor component in browsers, doubtless because it’s relatively
straightforward to create one using JavaScript.

_Graceful Fallback:_ Unlike in the Fossil 2.11 and earlier days, there
is no longer a script-free wiki editor mode. This is not from lack of
desire, only because the person who wrote the new wiki editor didn’t
want to maintain three different editors. (New Ajaxy editor, old
script-free HTML form based editor, and the old WYSIWYG JavaScript-based
editor.) If someone wants to implement a `<noscript>` alternative to the
new wiki editor, we will likely accept that [contribution][cg] as long
as it doensn’t interfere with the new editor. (The same goes for adding
a WYSIWYG mode to the new Ajaxy wiki editor.)

_Workaround:_ You don’t have to use the browser-based wiki editor to
maintain your repository’s wiki at all. Fossil’s [`wiki` command][fwc]
lets you manipulate wiki documents from the command line. For example,
consider this `vi` based workflow:

```shell
    $ vi 'My Article.wiki'                   # begin work on new article
      ...write, write, write...
    :w                                       # save changes to disk copy
    :!fossil create 'My Article' '%'         # current file (%) to new article
      ...write, write, write some more...
    :w                                       # save again
    :!fossil commit 'My Article' '%'         # update article from disk
    :q                                       # done writing for today

      ....days later...
    $ vi                                     # work sans named file today
    :r !fossil wiki export 'My Article' -    # pull article text into vi buffer
      ...write, write, write yet more...
    :w !fossil wiki commit -                 # vi buffer updates article
```

Extending this concept to other text editors is an exercise left to the
reader.

[fwc]: /help?cmd=wiki
[fwt]: ./wikitheory.wiki