Text-Only Websites
sjmulder.nl
sjmulder.nl
[1] https://www.freesoft.org/CIE/Topics/index.htm - I learned from this twenty years ago. Still relevant.
People love to shit on info because its default viewer uses emacs keybindings and the documentation "isn't geared for professionals" which is another way of saying providing minimum-viable knowledge (AKA non-OpenBSD man pages).
I happen to love info for those very reasons. Software freedom and usability used to mean that non-developers could understand how to use software. Want to learn how to code in Emacs Lisp? An info book on it comes with Emacs. Want to learn the ins and outs of the coreutils? Bash? gawk? Documentation the size of a book comes with all of them as well, formatted and designed to be friendly to people who have no idea what they're doing.
I have no data to back this up, but to me, it seems that when people think about building websites without JS, they completely forget that CSS, or design are a thing.
I am building a website for a simple API I built for my company[1] that I thought others might want to use, and while there is no JS, that does not mean that I just uploaded an unstyled .html file to the root of my server.
While unstyled have their own charm at times, in general, I think a little bit of CSS, design, and inspiration goes a long way.
When this idea has come up on HN before it has been met by angry web developers claiming they "would have to maintain two websites" or some such nonsense.
However, consider that no one composes content in JSON, or even HTML. Textual content always begins as readable text. Even if only in the mind of the person creating it. There is nothing to maintain as there is nothing to "develop". All that needs to be done is add the HTTP header and deliver the text.
One of the most popular examples of text retrieval I can think of to illustrate:
https://www.kernel.org/doc/Documentation/
Personally I prefer the directory-style "Index of" to the HTML-ised "Up / Next / Previous". Same functionality.
Even if the complaint "we would have to maintain two websites" had any substance, which website do you think would be easier to maintain?
That is a rhetorical question. That means I already know the answer.
Has syntax highlighting as well, beyond that I wrote it myself because it let me do exactly what I wanted the way I wanted.
Code is here if it's any use to you https://kopy.io/ibFMc
It supports Jinja templates and you can put meta data in the header so you can choose what template you want, override the title etc.
If you don't override the title 10-tricks-to-foo becomes "10 tricks to foo" automatically
I've used that script to write technical documentation as well, I just swapped out the template and everything else stayed the same, in terms of time to value reward it's up there for the most useful code I've written in a long time.
For context/the uninitiaatd, I think of pandoc as the "postgres" of markdown-to-<blessed_format>: you can build your own text-format-converter, but oftentimes you can get 90% of the way there with pandoc, and fill in the rest with custom filters and elbow grease.
To whet your appetite, I have a personal site that checks your boxes, where the build script is basically one long invocation of pandoc and xargs. In my experience and that of others', building on top of pandoc can get you to quite satisfying places and workflows (e.g. https://www.gwern.net/About).
(Also, fwiw, we use it at my place of work for writing versioned technical documentation, as well.)
Keep on plain-texting! :)
I ended up exporting all of my old blog posts from WordPress. Rebuilding the entire site (~370 pages) takes about 4 seconds.
The biggest problem I found was that I had to modify tufte.css to make it work well on mobile.
Care to post your site?
Mine, if you are curious: https://sheep.horse/
In my case there is a certain irony in writing it in Python the lazy way since I'm a full stack dev who writes typescript, js and PHP for work.
Never trust a builder with a finished house I guess applies, I didn't want anything I'd have to maintain.
edit: oh wait that's what the Tufte css is! What tweaks did you end up making?
It took me a lot of fiddling before I managed to find an acceptable compromise.
If I was going to start again I might consider implementing the margin notes differently. They interact oddly with each other and image captions.
for f in texts/*.html; do
cat preamble.html "$f" postamble.html > out/$(basename "$f")
done
The front-page is written manually. <!doctype html>
<title>Title of the document</title>
<p>A paragraph
<ul>
<li>First item
<li>Second item
</ul>
<p>Another paragraph
writing html tables by hand is especially pleasurable due to the auto-closing tags. As I see it, modern HTML is so concise that markdown is more of a burden than an aid. In most cases, we would be better off writing html directly than markdown. Maybe the only thing that I miss is that an empty line creates a paragraph tag.However, HTML4.1 for a time faded in popularity compared to XHTML, which was an "HTML-like" markup derived from XML rather than SGML. XML has significantly stricter parsing rules, for example always requiring full closing tags, trailing slashes on self-closing tags, etc.
XHTML's popularity seems to have been in large part a result of the IE6 backlash. Problems with web standards were widely perceived as a high priority for the web. This was the time period in which people kept putting "W3C Compliant HTML" badges in their footers. Because XHTML had stricter parsing rules, it fit into the general scheme of emphasizing web markup that was "correct" by allowing for strict automatic validation. Because it was XML-compliant it also fit nicely into both the popular-at-the-time "Semantic Web" (e.g. XHTML documents could be validated against XML DTDs/schemas) and dovetailed with browser support for XSLT (in which case a document could be sent to the browser as semantic XML with an XSLT "style sheet" for transformation to XHTML for presentation), which was one of those things that seemed like "the future" for about five minutes. I had done my personal website that way for a hot minute.
XHTML's vogue was somewhat short-lived, while it was a big part of the "web" scene in e.g. 2007, it was largely forgotten the moment HTML5 because available. What seems to have survived from XHTML, though, is a much stricter approach to writing SGML being seen as more or less required. I think a lot of people "grew up" on XHTML, quite possibly unknowingly, and so errantly view HTML itself as XLM with the subsequent parsing rules.
As always, there is often value in being explicit and verbose in markup in terms of maintainability. But in a lot of cases readability and maintainability are not harmed or even improved by saving some typing... as in cases like lists and tables.
That said, a big part of the phenomena is that hand-writing or reading HTML is decidedly out of vogue today, and so in general the readability quality of most HTML on the web is extremely poor, generally a result of it being generated by templating or composable component systems which often abandon basic indentation, as well as by the popularity of frameworks with unusual use of HTML such as non-semantic class-driven CSS frameworks. Of course this phenomena isn't entirely new, FrontPage and DreamWeaver were popular in their day and generated some pretty terrible markup, but it seems to have become more common, rather than less, for HTML to be machine-generated and thus extremely unpleasing to humans.
https://en.wikipedia.org/wiki/Mathematical_operators_and_sym...
Here's a nice demo on how to write tech docs using Emacs and Org mode https://youtu.be/0g9BcZvQbXU
Otherwise, if you math is just inline latin/greek symbols without 2D formulas (integrals, summations, etc), you can get away with unicode symbols and sub-indices.
If someone worked on a large team and moved all documentation from markdown to HTML, I think they'd quickly grow to become something a lot more messy than your example.
Already has best of both worlds.
[0]: https://idle.nprescott.com/2020/why-bother-with-markdown.htm...
[1]: https://sourcehut.org/blog/2020-05-27-accessibility-through-...
The optional tags make it easier to write, but make it far harder to mechanically process later if need be.
[2] It's been only the past year or so that I've created my own markup language [3] to render the HTML, and it's the resulting HTML that I store.
[3] A mostly-up-to-date sample of what it looks like: https://github.com/spc476/mod_blog/blob/master/NOTES/testmsg And the Lua script that parses it: https://github.com/spc476/mod_blog/blob/master/Lua/format.lu... It's still buggy, and there are corner cases I know how to avoid, and I'm not recommending it to anyone else, as it works for me.
[4] gopher://gopher.conman.org/
If you do want HTML (or possibly Markdown), then of course HTML will do. Just use plain HTML (perhaps with a common header and/or footer, added either ahead of time or using server side includes); no CSS, JavaScripts, decorations, etc.
I've also been experimenting with just using md files on GitHub, which is very easy to write and publish. https://github.com/codazoda/markdown-test
Suppose you want a really long lived store for your plain text or html files (archive.org is unlikely to go away anytime soon)
1) create an account on archive.org
2) upload your folders of files as an Archive.org item
(works best if you upload with a root folder included so that the archive.org meta files get created outside of your first level documents folder)
Your index listing will live under a url like:
https://archive.org/download/test_blog_2020/test/
(or even sub-folders like: https://archive.org/download/test_blog_2020/test/blog/)
(note that "test_blog_2020" here is a global unique identifier you can customize when you first upload to archive.org. as long as it is available of course)
Each file will have its own url like: https://ia601506.us.archive.org/4/items/test_blog_2020/test/...
(which means you can use relative links in your html and they will just work)
And you can use the "Edit" functionality to add more files to your folders:
via a url like this: https://archive.org/edit.php?edit-files=1&identifier=test_bl...
Do you know if there is a way to have an automatic directory index page? (i looked around the gitubpages/Jekyll docs but couldn't find a way at first glance)
i.e. What I mean is I would like to throw a bunch of md files into a folder and have a url that outputs the hyperlinked dir listing
https://stackoverflow.com/questions/25022016/get-all-file-na...
Then use Javascript to create the index page.
meanwhile after some googling this may be it (not tested though)
But I've chosen not to mess with things line text size and line height. More power to the user (agent)! Also, pleasant is in the eye of the beholder and I like it this way.
(Added your page by the way)
Please excuse the plug(feedback is welcomed)
A problem validation platform - https://needgap.com
Curated list of startup tools - https://startuptoolchain.com
Startup/Entrepreneurial blog(Has occasional comics, but with transcription) - https://hitstartup.com
When the users are logged in, the voting buttons get RED and you'll notice less of the pink(Please do give it a try and let me know if it's better).
Thank you for your time.
I built my website the same way, and spent a lot of time shaving milliseconds off and optimising readability. I wanted to create the same sort of smooth, bullsh-- free experience.
Email (SMTP) was defind 7 bit and it took us 2 decades to work somewhat reliably with other languages requiring more characters.
2018 https://news.ycombinator.com/item?id=17787816
2018 (a bit) https://news.ycombinator.com/item?id=17921251
2017 https://news.ycombinator.com/item?id=13337948
Any others?
They tend to use little to no decorative images outside of main content though, which is nice. Not to imply a list like this doesn't have the right to exist.
I intend to further curate the list soon and give proper text only sites a more prominent place. Retro, minimal, and text-only sites aren't quite the same.
I don't think completely text websites have to look bad. E.g., my personal website looks pretty good with relatively little CSS:
Some of the formatting is a bit sophisticated too, e.g. for block quotes of poetry:
This, though: http://wttr.in, will never break. I'll tape my old iPad to the fridge and use it as a weather screen.
which might be it.
If I wanted a clear definition of a text only website, I'd say a text-only website is a website which is served with a Content-type: text/plain header. This is far from that.
I do intend to reorganise the list to focus on those kinds of sites, but this HN submission caught me by surprise so for now it's just a list of sites the sort of match an aesthetic I like. "totally insane" is a bit harsh maybe.
Actually A text only web as a few interesting advantages. Almost instantaneous load even in a poor connection. Very fast development time since you throw away so many things away.
Probably going to use Javascript and angular.js, but open to suggestions. (I used to be good at JS, never used angular so far).
But README.MD start to ask me to install NPM which not beginner friendly...
I also came up with this concept https://github.com/runvnc/noscriptweb which I may never actually code because of time constraints.
NetHack
MUDs, MOOs, MUSHs
Dwarf Fortress
Kroz
Brogue
Zork (looks best on green phosphor screen).
Midnight Commander.
Trade Wars 2002.
If you explore the right platforms and eras then you will find many tens or even hundreds of thousands of text applications, many of which look "good" in my opinion.
$ curl rate.sx # outputs a nifty table of coins and their market rates
$ curl rate.sx/:help # to see how to use the api
I whipped up a shell function wrapper that makes this feel more like a standard cli command. In the off chance anyone is interested, I'm sharing it below (unfortunately, HN turns my tabs into spaces, so indentation is now a single space.)Note that I was careful to not let it clutter up your environment, so feel free to include it in your .profile with impugnity. Also, this sort of exhibits my current experiments with terse shell style, so don't hate on me for that, but otherwise the function should provide all the typical ergonomics you expect of a standard cli utility.
ratesx() (
set -o errexit -o nounset -o noclobber
RATESX_DOMAIN=${RATESX_DOMAIN:-rate.sx}
RATESX_CURRENCY=${RATESX_CURRENCY:-USD}
RATESX_NROWS=${RATESX_NROWS:-10}
RATESX_FETCH_CMD=${RATESX_FETCH_CMD:-curl --silent}
usage=$(cat <<-USAGE
usage: ratesx [<options>] [<command> <arguments>]
Show information about cryptocurrencies. Command defaults to 'table'.
Commands
graph <coin> [<interval>]
Display exchange rate graph for <coin> over <interval> (defaults to
\$RATESX_CURRENCY hours)
value <amount> <coin> [<amount> <coin>] ..]
Convert sum of <amount>*<coin> to <currency> (defaults to
\$RATESX_NROWS).
table Display table of top coins by market capitalization
coins Show list of supported cryptocurrency coins
currencies Show list of supported currencies
info Show upstream API info
Options
-q Quiet mode. Hide header and footer
-F Hide "Follow" line
-T Disable ANSI color
-n <nrows> Number of currencies (rows) to display in output table
-c <currency> Base currency for exchange rate calculations
-d <domain> Use API endpoint located at <domain>
Variables
RATESX_DOMAIN=$RATESX_DOMAIN
Default domain name of API endpoint
RATESX_NROWS=$RATESX_NROWS
Default count of rows to display in output table
RATESX_CURRENCY=$RATESX_CURRENCY
Default base currency for unit conversions
RATESX_FETCH_CMD=$RATESX_FETCH_CMD
Default command with which to submit API requests
USAGE
)
fetch() { $RATESX_FETCH_CMD "$@"; }
table() { fetch "$1/${2:+?$2}"; }
graph() { fetch "$1/$4${5:+@$5}${2:+?$2}"; }
value() { u=$1; o=$2; c=$3; shift 3; p=0
for v in "$@"; do
p=$((p^1)); [ $p = 1 ] && r="${r:+$r+}"; r="${r:-}$v"
done
printf '%s %s\n' "$(fetch "$u/$r${o:+?$o}")" "$c"
}
info() { fetch "$1/:help"; }
currencies() { fetch "$1/:currencies"; }
coins() { fetch "$1/:coins"; }
while getopts ':qFTn:c:d:' opt "$@"; do
case "$opt" in
q) quiet=q;; F) follow=F;; T) ansi=T;;
n) nrows=$OPTARG;; c) currency=$OPTARG;; d) url=$OPTARG;;
:) error "Need argument: -$OPTARG" "$usage";;
*) error "Unknown option: -$OPTARG" "$usage";;
esac
done; shift $((OPTIND - 1))
nrows=${nrows:-$RATESX_NROWS}; currency=${currency:-$RATESX_CURRENCY};
url=${url:-$RATESX_DOMAIN}; cmd=${1:-table}; shift || :;
url="https://$currency${currency:+.}$url"
opts="${quiet:-}${follow:-}${ansi:-}"
opts="${opts:+$opts&}${nrows:+n=$nrows}"
"$cmd" "$url" "$opts" "$currency" "$@"
)I started up Wireshark and then remembered that the traffic is encrypted by default ... so yea, that's not going to help.
Are there any gemini tutorial on how to make a gemini site?
I'm going to keep an eye on it though.
--
[1] http://www.jaruzel.com/gopher/gopher-client-browser-for-wind...
Summary: you write plain text. Use linefeeds to separate paragraphs, not lines of text ("Multiple consecutive lines which are shorter than the client's display device MUST NOT be combined into fewer, longer lines.").
Links go on lines by themselves, like:
=>[<whitespace>]<URL>[<whitespace><USER-FRIENDLY LINK NAME>]
Wrap preformatted blocks in "```", like in Markdown.Mark headers with "#", "##", or "###", like in Markdown.
Write lists like "* item", like in Markdown.
Write quotes on lines starting with ">", like in Markdown.
There, that's 99% of the Gemini format spec.
[1]https://portal.mozz.us/gemini/gemini.circumlunar.space/docs/...
But I think the main reason there's no example is because there's very little to show. Just make a text document and if you need to link to something you use the Gemini method of => URL title text
There's a few other things in the spec that are considered hints for clients (using # as headers, * for numbered lists) but those aren't even guaranteed to be rendered by the client as anything but plain text.
ssh kiosk@gemini.circumlunar.space