My main issue with the protocol is that it is requiring creating a new TLS connection for every request. That is indeed a simple approach but I argue that the extra round trip times added due to this are not worth the trade-off for the simplicity gained in this case
Coming up with a simple way to reuse a connection would reduce the round trips needed drastically. If we put our heads together, I feel like we could come up with a way to do that, that doesn't overly complicate the protocol ...
The reason Plan 9 died a swift death was that, unlike Unix – which hardware manufacturers could license for a song and adapt to their own hardware (and be guaranteed compatibility with lots of Unix software) – Bell Labs tried to sell Plan 9, as commercial software, for $350 a box.
(As I have written many times in the past: <https://news.ycombinator.com/item?id=22412539>, <https://news.ycombinator.com/item?id=33937087>, and <https://news.ycombinator.com/item?id=43641480>)
It's just unlikely that it will get as big of a following as Linux has.
That grants people an easy way to discuss content and to check any prior discussion, if any.
Something like https://lists.sr.ht/~shugyousha/public-inbox for example.
It is well suited for me because
- I like wood
- I like knives
- I'm into typography
- it doesn't require that much work space
I have only just started out but it feels nice indeed! A hindrance is that I am not very artistically gifted, but as long as I make it mostly for myself, I don't mind too much.
The reason is that in a monospaced font all the glyphs are supposed to the same advance value. This forces the ligatures to always take up the same space as two (or however many glyphs) are involved, which may stretch the ligature glyph in a non-intended way (if it is even possible to rasterise it that way).
Monospace fonts are also often used for programming (because they make sure that the columns line up consistently, regardless of the font being used). I personally don't see the point in showing ligature glyphs that do not correspond to the actual Unicode code points encoded to bytes in the source code.
Just my 2 cents.
I honestly don't get the point of TUIs...
A real command-line interface is extremely useful - it's trivially scriptable, works direct or with ssh, scroll-back buffer logs what happened, commands stay in my shell history, I can copy-paste commands to a friend over chat system, or into shell script, and it's easy for app authors too. Its my first choice for my apps.
If low-color fixed-width character grid is not cutting it, then native app or web app is a great second step, or even intermediate solutions, like generating HTML files from CLI tool and opening them in default browser. You have to invest some effort, but you have infinite ways to design your interface, and it's still in user's familiar environment.
But those charm.sh TUI applications seem utterly useless and highly annoying. They give up all of the terminal advantages: my shell's history is useless, my favorite ways to edit commands does not apply (as they have their own editor), I cannot scroll back and see what the program just printed, I cannot script it, I cannot log it, I cannot search it, I cannot redo the previous action, the color scheme is not the one I've picked... At least with web apps I can parse html and/or hit underlying API directly - no such luck with TUI apps.
At least the good news is that TUI apps are not getting any traction, and I can completely understand why.
There are one or two advantages over regular GUIs, but that's it.
The biggest is probably that they are lightweight since there are no GUI library dependencies (and if there are TUI ones, they are usually much lighter than their GUI sisters). This also means there are fewer (if any) dependencies to distribute compared to a GUI.
The only other advantage I can come up with is that a TUI will have to be usable by keyboard only (in almost all cases). This is not a given for regular GUI libraries.
I'm not a fan of TUIs either. I think the only one I am using regularly is `tig` (https://jonas.github.io/tig/). I guess the reason is that I don't have to remember the git revision list syntax that way and that `tig` allows for easy commit searching with `/` ...
> What if you don’t care about efficiency or causality?
"Yeah, what about if you don't care about money/time and are happy with finding a correlation only?!!?"