That's the original vision of hypermedia: cross-linkable book pages who can express metadata about their content while maintaining flexibility in their visual output.

I never thought I'd say this, but HTML4, with all its billions of warts, was a pinnacle of this vision. Later developments swung too hard towards an excessively content-focused vision first (XHTML, the "semantic web"), and then swung all the way in the opposite direction, turning web protocols into dumb pipes for the general-purpose VM runtime that modern JS/HTML engines have become.

Unfortunately, the industry always, always wanted this runtime. Plugins, applets, ActiveX -- people just refused to accept basic form-based interaction. DarkWeb properties accept it only because doing otherwise would be too dangerous, in the same way people don't wear jewelry when going through a ghetto.

Rant: If people using Tor have JS disabled, then why does the Tor Project keep pushing "Tor Browser" as one-size-fits-all program for all Tor users. The program is enormous and seems like overkill for something lightweight like text retrieval. (IMO, it should be expectped that people might use Tor for lightweight tasks on account of the latency.)

I've been experimenting with DuckDuckGo's .onion site. Below is example of how to search the light web over Tor without Tor Browser.

I'm interested in .onion sites because it sounds like .onion solves the reachability problem. Anyone could have a website. No requirement for domain name and hosting subscriptions. No commercial middlemen. (Assuming Tor network operators are true volunteers.) Not every website has to be commercial or reach large scale.

pts/1

    x=duckduckgogg42xjoc72x3sjasowoarfbgcmvfimaftt6twagswzczad.onion
    socat -d -d -d tcp4-l:443,fork,reuseaddr,bind=127.0.0.42 socks4a:127.0.0.1:$x:443,socksport=9050 

pts/2

     # Usage: echo query | $0 > 1.htm; 
              links -no-connect 1.htm;
              firefox ./1.htm;

     #!/bin/sh
     h=duckduckgogg42xjoc72x3sjasowoarfbgcmvfimaftt6twagswzczad.onion
     read x;
     curl -v0dq="$x" --resolve $h:443:127.0.0.42 https://$h/lite/

Using socat instead of curl

     #!/bin/sh
     h=duckduckgogg42xjoc72x3sjasowoarfbgcmvfimaftt6twagswzczad.onion
     read x;
     x=q=$(echo "$x"|yy046);
     export httpMethod=POST;
     export Content_Type=application/x-www-form-urlencoded;
     export Content_Length=${#x};
     export httpVersion=1.0;
     export Connection=close;
     echo https://$h/lite/|yy025|if sed w/dev/stderr;then 
      echo $x;echo $x >&2;fi \
     |socat stdio,ignoreeof ssl:127.0.0.42:443,verify=0

There are a spectrum of privacy-related use-cases that Tor Browser solves; not all of them require that you have untraceable anonymity from the perspective of the server you're talking to.

For example, when using Tor Browser to connect to regular public websites, your goal is usually just to obscure your connecting location, hide your traffic from your ISP, and punch through and firewalls between you and the destination, without first being required to establish a relationship with some specific proprietary VPN company (where doing so might not even be possible if you're in some countries.) So people doing this tend to be willing to enable JS, at least on a per-site basis.

It's only really when you're in the kind of trouble where state actors are trying to correlate your IP address through inadvertent connections you might make to state-owned-honeypot Tor hidden sites, that the full no-JS paranoia is warranted.

But, to vouchsafe the anonymity of those people, it's better for anti-fingerprinting if more people who are using Tor Browser for more mundane things, also have JS disabled. So Tor Browser disables JS by default.

Which means that it's pretty much a given that if you're doing web design specifically for a Tor hidden site, then you have to assume that people accessing your site will have JS disabled. (And that you can't just ask them to enable it — they'll say "nice try FBI" and close the tab.)

Tor Browser defaults to JS enabled.