From the docs:
Stop thinking in standard CSS units like px, em, rem, %
Start thinking in Character Cells for spacing, sizing, and positioning
The web browser has an insanely powerful typographic and layout engine. Now we're looping back into character cells. Something went wrong here, at least once.
That said, I like the aesthetic and the default color palette. It's quirky, but it has its places.
So there's something to be said about those types of interfaces - it may look simple and be text based, but it's the most user friendly for the qualified operator to get things done.
You could get the same result with a graphical interface, as long as you provide proper keyboard based navigation. The web browser provide all the capabilities that you need for that.
The nice part of a text based ui is that you have a simpler device to use for rendering, so things like layout is easier, as long as you remain in the domain of what the device allows for.
If a business forced a keyboard-only input method, then that might help to raise the efficiency of everyone more equally.
I have a feeling that sort of "trainable speed" is a feature of interfaces that treat the thing they manage like a physicial "thing" you're rolling thru a process. (instead of a feature of textmode interfaces) Rather than having to get to a menu for outside lines in some abstract window, there's just actual physicial buttons to mash. You get this feeling that you're juggling a call between your fingers because every press you do is doing a "thing", not just opening a menu. There's real physicality to that process that my monkey brain can learn no problem.
I don't have any experience operating a terminal based PoS, but from what I know, they tend to also have the same sort of "juggling" actions, like SALE, DISCOUNT, VOID etc. I have to imagine using them feels like juggling the current item you're looking at thru a few different buttons.
My working theory is that these terminal-based UIs aren't quicker because they're terminal-based, but rather users need to learn the keyboard shortcuts because they're so painful to use any other way. A well-designed GUI equivalent could be significantly quicker, and much easier to learn, but nobody wants to pay for that.
Related: I really liked Blender's text-searchable menus and I wish every GUI app had searchable menus. It's faster than hunting through a static hierarchy. In fact, one of the few criticisms I have of the 4.x era Blender UI is just that it's mildly harder to invoke search.
[0] Which is how linear video edit consoles worked before modern NLEs, mind.
They do on mac: shift+⌘+? opens a "search menu" menu.
Luckily most do, but I’ve encountered situations where they haven’t and it only shows compatible system shortcuts
On macOS and KDE (Wayland), they do! Agreed it's really handy.
Maybe it is a matter to actually design for the customers use case.
You can build a perfectly snappy, keyboard-driven GUI application; a terminal emulator is (ironically) the perfect example.
That's the beauty of the terminal. It's not a one size tool for all. There is no product that can be made for everyone. Instead it's an environment for you to craft and live in. Everyone's dotfiles are as unique as they themselves are. That's the point. Because when you can't build something for everybody you give them the means to craft their own worlds. The computer didn't become so great because the chips, it was the ability to write software and build the things you need. The smartphone didn't take off because it had a big screen, it did because the app. Because you could create. Because your phone is yours and no other phone is like it.
But I haven't found a browser that lets me be me. That let's me dance around the web and jump and be free. And I fear we lost sight of this thing as it became so natural, that the phone and computer are turning into things that be instead of a reflection of me
Not everyone's work life revolves around text just because yours does.
But I'll also say, in all these applications having good key bindings is still a massive help. Those really good at these programs aren't clicking dropdown menus constantly but are issuing keystrokes in combination with the need for their mouse. In a way, that's not too different even if in another way it is
FTFY
They both have their place, pros and cons, that fit different purposes differently. The mistake is in trying to assign superlatives.
Two things can be true at the same time, TUIs are superior to GUIs, and GUIs are superior to TUIs, but in different contexts.
TUIs are GUIs - in a trench coat. A TUI program must still process input events, draw widgets, manage state & focus, etc - all the things a GUI must do. What OTOH it can't do, is even the most basic stuff, like system clipboard or displaying pictures. You have to use side channels to get that, and once you do, you throw away the TUI's one single advantage - SSH.
Yes, but the TUI application running in it can't - unless using non-portable side channels such as pbcopy or xclip. Copying text is limited to what's visible on your screen (and have fun if it's drawn inside a widget). When pasting, you're dumping the text as if it was typed in. Also, have fun with Ctrl-C / Ctrl-V.
> You might be limited in pictures [...]
That's right, sixels are indeed 1980s technology, seems like VT200 can do that.
But you know what I mean. It can't do audio, video, HDR pictures, precise mouse motion, accessibility, or even recognise shift+alt (ran out of bits in ASCII). It's a serial link, and using a side channel is just cheating.
Being terminally terminal doesn't mean I only use the terminal and go headless on all my machines. It is my main interface with my computers but I'm writing to you from Firefox. Nor am I going to play steam games in it. But most of the time I'm on my computer I'm not playing games or watching movies. Even with web browsing 99% of what I'm doing I don't actually need these things.
I'd love to have a web that is much more minimal. We don't need to go to walls of text like the 80's, nor even as stripped as HN (which is very lightweight), but there is a nice elegance to more minimal pages (more than just aesthetics) and the zippy experience is almost universally appreciated.
And again, a lot has changed from the 80's and no, a VT200 cannot create the images I see on my machine. I'm not looking at pixelated junk. When I'm running chafa I'm getting something quite similar to what I'm seeing if I open the picture through my file manager. I'm sure if I zoomed in I could tell the difference but that's not my usual workload.
I also don’t know why you consider manipulating the system clipboard a side channel. The terminal emulator provides a way of manipulating the clipboard but that is just convenience.
Any program can access the clipboard and a TUI program can do this as well. I have a grepalike that inserts a search match into the clipboard for convience. Somewhat ironically most of the time that match gets pasted back into the terminal.
I would actually like to have a network wide clipboard system. There are solution for that but I haven’t yet found any that isn’t too unwieldy.
What? The serial link was the only way for the terminal to talk to the Big Machine. There never was a "side channel", in fact things like control flow are mixed in-band; that's why some programs get confused about C-s and C-q.
> The terminal emulator provides a way of manipulating the clipboard but that is just convenience.
That's different from the TUI application accessing the system clipboard. You need to use pbcopy or xclip, that's non-portable, won't work over SSH, relies on those external tools being installed, etc.
> I would actually like to have a network wide clipboard system. There are solution for that but I haven’t yet found any that isn’t too unwieldy.
Try any two Apple devices signed in to the same iCloud account. It works OOB, zero setup, 100% reliable. It's called Continuity: <https://support.apple.com/en-us/108046>
Yeah, proprietary, non-portable, etc. Choose your trade-offs.
Ghostty matching and supporting xterm protocol is different than it /being/ xterm and thus /being/ functionally identical to your 70's terminal. Of course it needs to be able to support this protocol because why would someone building a terminal emulator build something that is going to break as soon as you touch something that tries to communicate via an xterm protocol? There's a reason there's that ssh stuff at the end. Are you going to criticize a browser for supporting html and css?
But I don't get your point here. Why would that even matter? You're hyper fixating on the similarity to the 70's terminal while blatantly ignoring everything that is different.
Does your 70's terminal:
- Support tabs?
- Support panes?
- Handle mouse clicks?
- Support non-ansii fonts?
- Colors?
- Ligatures?
- Glyphs and Icons? Emojis?
- Support asian language input?
- Use GPU acceleration?
- Support shaders?
- Render high resolution images?
- Render the terminal at hundreds or thousands of fps?
I mean what do you want? In my terminal I can write my code, have full color support, view PDFs, view high resolution images, and do all this without really putting any meaningful stress on my system. I can have a bunch of tabs open viewing code, pdfs, images, several instances of gdb and still be using less CPU and memory than if I just open VSCode.
So what point are you trying to make? That I interact with you program mainly with the keyboard and that despite being able to use my mouse I choose not to? Or are you just mad at the aesthetics? Or that people haven't exploited the previously mentioned capabilities to build cooler things?
Honestly, I do not understand what point you are trying to make.
Vim and Emacs both have GUIs. As an Emacs user, I subjectively find the GUI superior - I can e.g. rebind Cmd-S to "save", and that's a reason enough.
> It's a language you learn [...]
You mean the serial lines and ANSI escape codes and termcap? I would say it's more like pidgin with a dozen obscure dialects, and a body language on top. Try writing a portable TUI application from scratch, without touching curses or termbox. <https://viewsourcecode.org/snaptoken/kilo/>
Or do you mean, how to drive a TUI application from the keyboard? Here's the painful truth: you can't quit a TUI application without learning it. In vi, it's "Esc-q!-Enter", in Emacs it's "C-x C-c", in screen it's "C-a C-\", in tmux it's "C-a C-d", and so on. Maybe pressing "q" or F10 or C-d will work, but good luck guessing. This is just to quit, and ironically - it's only the start.
By contrast, on macOS it's Cmd-Q; on Windows, it's Alt-F4; and so on. Innovation happens on stable foundations, not by pulling rugs.
> It's not a one size tool for all. There is no product that can be made for everyone. [...] Everyone's dotfiles are as unique as they themselves are.
You know non-TUI applications are also customisable? I have Hammerspoon scripts, a dozen custom keybindings in macOS, .xsession+.Xdefaults+.Xresources, .gitconfig (I use git via Emacs+Magit), various .config/*'s (for e.g. sway), .emacs (bankrupted several times), and so on - none of these are TUI applications.
Or do you mean the command line? I believe we can build a better REPL than a terminal emulator. Emacs is a decent PoC, you can also have a look at Swift Playgrounds. Maybe we can build a generic non-terminal REPL where Ctrl-C means "copy", and Ctrl-V means "paste", that would be a great start.
Don't get me wrong, I'm happy if you're happy, I just don't understand the collective obsession. These tools exist, which is great, but we deserve better.
That's the window manager of the respective systems though. On i3, I can also kill any window by pressing Option-Shift-q. But that's more like the sledgehammer approach and not how I'd close a text editor on any system ...
So what? I'm not so sure you can learn Photoshop without either watching someone use it or reading a few books on it, whilst emacs maintains an excellent tutorial that it tells you to read multiple times when you start it.
In the 1990s and early 2000s I volunteered at a senior center teaching people how to move the mouse and translate that movement into the little arrow-cursors' movement, and the experience convinced me absolutely nothing about computer-use is intuitive or obvious to anyone who did not grow up using it.
I urge you not to stick with a worse-user-experience just because you already "know" it. If you think GUIs are better, that's one thing, but this cannot possibly be the reason.
> Try writing a portable TUI application from scratch, without touching curses or termbox
Try writing a portable X11 application from scratch, without touching libX11 or libxcb.
Try writing a portable Win32 application from scratch, without user32.dll
None of this is fun, but the TUI application is less code, and it's not even close.
> As an Emacs user, I subjectively find the GUI superior - I can e.g. rebind Cmd-S to "save", and that's a reason enough.
The mac Terminal isn't great for a few reasons, but iTerm and kitty absolutely let you do this if you teach Emacs to decode the sequences.
I find this a much better experience than using tramp to tunnel remote servers.
> non-terminal REPL where Ctrl-C means "copy", and Ctrl-V means "paste", that would be a great start
You can have this today (see above), but I much prefer ^C being cancel/interrupt/compile, and ^V being make-visible. I avoid copy and paste because it doesn't fit in my workflow very well:
> You know non-TUI applications are also customisable? I have Hammerspoon scripts, ... I just don't understand...
I don't want hotkeys, I want automation.
In a terminal I just run the regular application (like emacs) under autoexpect. I then edit the resulting script, and run it and now I have a new application that does something useful to me. Eventually I add it to an application I wrote which just runs all of my scripts in a big loop.
I run one gui application (chrome), and then use vncsnapshot to dump images that I print out over the kitty image protocol. I then have a perl script forward the keyboard and mouse metrics into qemu via vnc. It works well enough for autoexpect, but it's a lot of work for one application.
Then, I go to the beach while my computer is doing stuff people pay for.
I'm not talking about learning Photoshop, I'm talking about quitting Photoshop. On a Mac, the "close" button is in the upper left corner of the window, and has been there since 1984. Dock icons only appeared in NeXTStep, which OS X inherited ca 2000. But the list goes on.
> Try writing a portable [...] application from scratch.
That's not my point at all. The terminal emulator creates a window for you, and puts pixels in it. The TUI application then talks to that emulator over a serial line, as if they were running on separate machines. Why not let the application paint the pixels directly?
> The mac Terminal isn't great for a few reasons, but iTerm and kitty absolutely let you do this if you teach Emacs to decode the sequences.
These extensions are non-portable, and require specific integrations on the part of each and every TUI application. For example, kkp is 800 lines of Lisp. Also, termcap is hell, and comes to bite you as soon as you spell "ssh".
> I avoid copy and paste because it doesn't fit in my workflow very well [...] Then, I go to the beach while my computer is doing stuff people pay for.
That's a lot of effort and dedication on your part, and I respect that. But let's be honest, what you're doing is a narrow specialisation - and that is what you're being paid for. I'm talking about applications copying and pasting text, displaying an icon in the dock, or having consistent key shortcuts - out of the box, consistently, no glue, no side channels to cheat the serial line.
That's your unfounded opinion man. You have no idea what I'm doing.
There's only two reasons to use a computer: One is because it is an entertaining way to spend your time and money, the other is because it's a way to make money.
> Why not let the application paint the pixels directly?
Partly because they do it badly, and partly because it's harder for other applications to read the pixels.
Think about how the clipboard has to work: The application just told the display to write some text there, but the clipboard has to ask again what text is there, wait for a response, and let the other program know. Meanwhile the terminal just knows, so it's faster.
> I'm not talking about learning Photoshop, I'm talking about quitting Photoshop. On a Mac, the "close" button is in the upper left corner of the window
And you learned that somehow. You can learn other things too.
> These extensions are non-portable
So what? They're portable to every terminal I use, every new terminal being made, and if you want, any terminal you use. The Mac isn't portable to anything except another mac.
cmd-s is a single keypress and can be done with a single hand.
shift-; w cr is two more and involves a back and forth over the entire keyboard.
I'll give the parent that this is slightly harder than <C-s> but they got the right conclusion for the wrong reasons. But if that trivial extra effort is what's required for what I can do in vim, I'll gladly make that trade. I love my panes, buffers, windows, completion (see :h ins-completion), my visual mode, my search, my replace (way more powerful than many think), my tags that allow me to walk through the program, and how I can effortlessly move my cursor around the screen and around the document. It takes far less effort to move my cursor to where I want than it is to lift my hand and grab the mouse. I love that I can open all files in my project while my computer doesn't even blink, and I can do some refactors of all my code with a single line. No IDE has ever come close to giving me these abilities and I haven't even mentioned the half of it.
> I can e.g. rebind Cmd-S to "save", and that's a reason enough.
:nmap <C-s> :w<CR>
> In vi, it's "Esc-q!-Enter"
Do you also get pissed off when you modify a word document, click quit, and it asks you if you're sure and like to quit without saving? It's literally the same thing.
Idk I just don't see the problems you are talking about. They aren't things I face. On my Mac I can still use native cmd+{c,v} and on anything else I'm not upset by adding a shift. Though most of the time I'm yanking and pasting because I can "vim" in bash, zsh, hell I can even do it in ipython! In tmux and screen I just type exit or <c-d> to kill a pane. You say it's just the beginning and I agree, but I think you missed that in tools like vim the language is the motion and actions. It's why I can discover "new commands" but it's like discovering you can jump over a box when you already know how to jump. If you're just trying to memorize commands and combinations you are doing it wrong. I'm sorry whoever taught you failed you, and I'm sorry there's so much noise.
But if we want to be pedantic then you're going to have to admit that cmd+q and <c-q> don't always quit. Many times they just close the window. Sure, alt+F4 is different, but that's a force kill list like typing "pkill <program name>" or simply <c-c> (which came first? <c-c> or <c-q>?)
It's not like I don't use a GUI at all. But yeah, it's nice to not lift my hand from the keyboard. Don't get me wrong, I'm happy if you're happy, I believe the best tool for you is the best tool for you. But if you want to understand why I'm obsessed, you have to try to see what I see, from my eyes and not yours. It's hard over text like this, that's fair.
And you're right! We do deserve better! If you ask me, my number one annoyance is when the computer won't let me do things. I'm very frustrated with both windows and Mac since they put up so many walls that make it difficult for me to shape my machine the way I want. Sure, this is hard in Linux but there's no locked doors in which I need to find a key (other than sudo) or a back door. I edit my dotfiles to make these things a part me, why would we not want to carry on that idea?
Web model is objectively better than
‘’’ Stop thinking in standard CSS units like px, em, rem, % Start thinking in Character Cells for spacing, sizing, and positioning ‘’’
Hard disagree. Modern web browsers are incredibly complex beasts that evolved by amalgamating decades of experimentation, poor non-standards, and elaborate counter-measures to fix that mess. I recommend reading <https://browser.engineering>, or even just building Chromium from source, to gain some appreciation. Most applications would benefit from something much simpler. But it's often practical to use as it is, pretty much exactly like terminal emulators.
The main difference being, terminal emulators are still several orders of magnitude less complex than web browsers, but in spite of that still require a lot of complexity to undo the side-effects of having a serial line between the CPU and the character grid. If you like monospaced fonts and character grids, you can probably render that with plain SDL, bitmap fonts with indexed sprite sheets (no Freetype), and in return get non-broken copy & paste, or even a dock icon. You know, the MVP of GUI.
Try <https://lite-xl.com>, it builds its GUI straight on top of SDL.
You don't even need SDL https://github.com/cmuratori/refterm
The point is, once you have a window and a putpixel (or even better, surfaces and blitting), the rest is easy to handcraft. A standardised library would of course help.
Of course nobody would expect this to take off largely. But aesthetically speaking, I see nothing wrong in the design per se. It is clean, consistent, light and minimalist-like. Terminals just provide a minimalist style that is tested and also familiar to some. It is very easy to get around the website. Pages load fast.
The main drawback I see is lack of multimedia support, obviously (even if supported they would be a bit out of style). But that's not a problem if you do not care about that. And that it is hard to place ads.
Sure, "Web model is objectively better" but also depends what one considers as "web model" because a lot of modern web is just a bloated mess, which I find more annoying thaν a project like this.
Css uses boxing with no sugar (like size groups or custom allocation). Boxing is this in that in that in that, sometimes stretched. And now when you want A and B in different boxes to align well, you're screwed, cause it creates an invisible fragile tree of braces that hold everything in place.
Maybe they would use a much more natural constraints-based language instead of text modes. Like, literally, "this under that, and these five left- and width-aligned". But web is reluctant to add it, because when not used carefully it could slow down first interactive renders by 0.01% out of average 10s (that is, assuming the same moronic site structure for some reason and the code that renders it).
The higher-level view of data-over-time is inherently serial, and I don't think there's anything anyone can do about it: Serial is the correct/best abstraction.
That being said, I acknowledge the problem you're referring to, because serial what exactly? Every time we complete the circle, it gets a little smaller, and our collective knowledge of what is actually going on improves.
It should make a certain amount of sense if you look at it this way: Use a serial decoder to fill a memory bank of character cells or pixels or whatever, and share that memory bank with a video encoder, and the software guys say: well, how about I just fill up that memory bank directly. Then, you don't want character cells but triangles, and you find you're just DMA'ing in that shared buffer and working around the timing of another process reading it and your ring-based memory buffer has turned back into a serial protocol before you know it.
I think the main problem is that programming languages are terrible at serial, so programmers keep trying to work around it, and then convert to/from serial at the edges.
> it's another thing to claim that this is the peak tech to power our modern CLIs, or a solid foundation for portable UIs.
I can't explain all of it, but terminal UI remain without match: Even today (2025) I use a terminal because there's no better human-computer interface for doing intellectual work.
A picture of a terminal, is not a terminal, so I understand why stuff like this confuses.
I think a REPL is the real-eval-print-loop used by lisp systems to talk to a terminal, or something that looks/works like that (but maybe doesn't use lisp). These days I think lots of things have REPLs. Even Python. The only ones to survive 40 years though, have been serial ones, and I don't think that's an accident.
That command box/area that the user uses and re-uses in Oberon and Acme is something else and specifically worse than a REPL because you can't script it: There's no GNU expect for rio, and no DESQview-learn for Oberon and their command language just isn't good enough. This interface has not proven particularly efficient for users either, but terminals are still around.
Emacs is what I'd consider "peak terminal", and it has a REPL and an excellent command language. You can also script Emacs with emacs, by literally running emacs in an emacs terminal.
Imagine Emacs mixed with Jupiter netbooks, for the whole OS stack.
Sounds dreadful.
> That is a a barebones REPL from early 1960's, not the experience I was mentioning.
No, that is a definite article. I was talking about three things, two of which are things you brought up in an effort to find common ground. If you don't know Oberon or Acme then there's no point in talking to you about them. I still don't know what you're trying to tell me, and I'm beginning to think you don't either.
To people stuck in UNIX mindset, maybe.
> If you don't know Oberon or Acme then there's no point in talking to you about them. I still don't know what you're trying to tell me, and I'm beginning to think you don't either.
Oh boy, I definitely know Oberon.
Here is my detailed explaination.
You write the REPL like code you feel like on a pane, you can the use the sigils that map if the command (loaded dynamically as instances from Oberon commands in modules), refers to existing text, selected wigdet on another pane, or requests user for additional infortmation, mouse select the command and execute it.
> You write the REPL like code you feel like on a pane, you can the use the sigils that map if the command (loaded dynamically as instances from Oberon commands in modules), refers to existing text, selected wigdet on another pane, or requests user for additional infortmation, mouse select the command and execute it.
Ok. I feel like I already explained why TextFrames is (a) not a REPL, and (b) absolutely worse than what you can do in a terminal.
> To people stuck in UNIX mindset, maybe.
I don't know man. I don't know anyone who doesn't use UNIX every day, and I don't know anyone who uses Oberon every day. I am telling you in a way why I don't think that's an accident, and we can talk about that aspect if you want, but I think the cobol forms on a 3270 are a way more interesting version of terminals than what UNIX does with them, and programming/scripting the terminal is really the thing I think that makes them better than any other human-computer-interface.
Depends. Emacs has had brilliant ideas, did brave things, it just remained stagnant for the past 30 years. (Unlike terminal emulators, which do boring things, and have been stagnant for 40 years.)
A slightly better REPL doesn't have to be brave. It just needs a sensible text editing widget, that's already a tenfold improvement. The cognitive load between Ctrl-C and Ctrl-Shift-C drives me crazy.
I disagree with all of this.
> The cognitive load between Ctrl-C and Ctrl-Shift-C drives me crazy
If you use emacs like you say, you should know you can bind ^C to whatever you want.
I like ^C being what it always has been, and I'm not persuaded by one person's inability to perform an internet search or read the manual of software they claim to use.
Hell no. I've suffered Emacs bankruptcy several times over the past 20 years. I try to keep my init.el under 1k lines to avoid another one. Rebinding Ctrl-X or Ctrl-C never works without addressing a dozen quirks, and there's always another one waiting around the corner. Hell no.
> I disagree with all of this. [...] I like ^C being what it always has been [...]
You're entitled to your opinions, but I'm arguing for more consistent behaviour for applications. This can be objectively measured by answering questions such as: "does this application copy and paste text? if so, does it use the same key shortcuts as the next application?"
:)
> I'm arguing for more consistent behaviour for applications
I think that's tilting at windmills.
You can solve your own problems, or you can ignore them, but there's no way you can just whinge on the Internet about how much you love Emacs but hate the copy/paste keys and get anywhere. You already know this. I'm sorry. Good luck with that.
> This can be objectively measured by answering questions such as: "does this application copy and paste text? if so, does it use the same key shortcuts as the next application?"
Since my first mouse, it has always been select with left button and paste with second button. That's how it is in OS/2, in every unix, and even on VMS. That's how it still is with every terminal I use. It's just simply not an application concern in my world and I think it was bad engineering for Apple and Microsoft to try and get the Application involved in the clipboard.
So the nostalgia for it is not a surprise, and the decision to spend more time in terminal-esque interfaces can be rational. Often some marketing department wants to splash fonts, layouts and colors everywhere; but I just want to read some text.
Apparently that is some kind of retrocomputing movement.
The strange part is that most folks pushing for TUIs weren't even born and don't get the pain we went through.
We used TUIs because that is all we could afford, not because we were given an option.
Perhaps 500 years from now "beautiful" (or whatever it has morphed into) will simply have a meaning similar to "pleasant".
But words tend to get nerfed, and clickbait culture certainly doesn't help. "Slams" in a headline has been reduced to "made a somewhat negative remark about," and "genius" now means "it took more than 2 seconds of thinking." Let's not discuss what "beyond excited" has become. I too would like word meanings not to shift too fast, as it helps preserve culture, especially literature, but the forces are too strong and diffuse to oppose.
So "I love this web font" now just means "Don't think, just click on this link."
I have vague ideas for how I could build something ergonomic, easy, and pleasant to use, but I lack experience in this area, and the focus/energy to experiment.
I'm hoping to bring this subject to the light, and have a constructive discussion. If not me, then perhaps someone else will get inspired.
But inspiration is a fickle thing. If you're going to build something, you might as well be inspired by terminal-style interaction, but it can't be the goal.
100% agree. I believe that if we do replace the terminal, the end result will not be that much different - keyboard first, power users first, APIs that are simple to consume, platform-agnostic. What would make the key differences is letting go of 50 years of accumulated technical debt, that continues to hold back the UX - aka the ergonomics and ease of use.
> IMO, you need to be a domain expert [...]. You (or the team you're part of) have to understand the topic and users extremely well.
"Sometimes Ordis likes to assume he knows nothing. Nobody can learn what they think they already know."
Whether libraries like this one manage to replicate the experience is a whole other question.
[1] Just look at what modern tools FilePilot and RAD Debugger can do with their UIs and compare that to nearly every single one of modern apps.
Not CSS but similarly ratzilla (2) also comes to mind, that allows you to build terminal-themed web applications with Rust and WebAssembly.
Check out the examples (3) they look great!
(1) https://terminaltrove.com/
(2) https://github.com/orhun/ratzilla
(3) https://github.com/orhun/ratzilla?tab=readme-ov-file#example...
NerdFonts (and the right terminal emulator) were needed, and enough, there. Playing with AstroNvim, and blocked by use of yakuake.
Hoping that I can hot load something from https://www.nerdfonts.com/font-downloads, I'm not sure what from https://fonts.google.com/ has the needed ligatures or symbols.
> Don't share this with anyone you wouldn't trust
This is on another level. They built a terminal sharing application that connects to their servers. One must truly like to live on the edge to try this at home.
If someone built a full C compiler but it throws errors when compiling itself, would you use it?!
Ngl, I see a non-zero chance of this kind of aesthetic catching on for nerdy blogs, which tends to proliferate to the wider web eventually. If nothing else, I love some support for those of us who spend all day reading (stylized) Markdown syntax!
for more, I liked The Monospace Web: https://news.ycombinator.com/item?id=41370020
and some other good examples in the comments
I was actually going to write a theme for a project I'm working on that is meant to be styled like an inventory terminal from an auto parts store circa 1995, which was all some kind of TUI, so your theme is a great inspiration!
## Shameless plug
I explored a bit what older tech such as IBM's TN5250 terminals could bring to the Web [0] 2 years ago. In particular for data input scenarios.
It's designed for Desktops, not mobile.
This is neat, but no, stop it. TUIs are an abomination of design that poorly mimic actually beautiful UIs. They look the way they do because of inherent constraints of the terminal, not because their authors particularly wanted them to look like that. So bringing that design language to a platform that does support rich UIs is artificially limiting what can be done on the web. It will also never truly have the same design as the terminal, unless you also want to avoid having any rich multimedia, interactivity, or use any web functionality introduced after 1995. At that point, your users would be better served by a text-only or Gemini site instead.
As an aside, I think TUIs are wrong in most cases. If you're building something like a text editor or process manager, sure, they have their place. Although even then I would argue that they shouldn't mimic the look and feel of GUIs, but be purpose-built for the app in question. But most terminal programs shouldn't use TUIs. They should accept command-line arguments to modify their behavior, run and do what the user asked, and then exit. This is how you make programs adaptable, composable, and scriptable. They can still be made interactive at runtime via a different e.g. "client" program, but forcing the user to manually interact with an interface that mimics GUIs is an awful experience.
My mother used to have an early "digital company" back in the 90s in Argentina. We are from a small town in the "Patagonia region"[0] and there was only 1 programmer in the whole town. The guy was a huge nerd that had spent some time studying in Buenos Aires.
Long story short, my mother hired this kid to build software for him. This is around 1992 so it was all DOS.
This guy built a full TUI software with CRUD operation, reporting, "cron jobs" (some stuff that I never understood but would run every night), printing, etc.
Until this day I remember the people working at my mother's company how they just FLEW over the software. It was all keyboard and hotkeys. They'd just go back and forth, print stuff, enter data, connect with the Fax machine, all with their keyboard in this black screen full of green, white and orange glyphs.
I NEVER found any other software that is SO powerful and efficient and user friendly as TUIs.
[0] The "true" Patagonia region in the East of Arg.
I think the reason is "limitation", if you have to design an app that CAN NOT use a Mouse, you'll be darn sure it'll work well with the keyboard.
Don’t get me wrong, you can do it right, but most don’t bother with non- functional requirements “this should take 5ms” etc, so you just end up with pointless animations and transitions that stop useful work being done. This is often simple things like the tab order being wrong, or an AJAX request blocking the next thing you want to do.
1. Developers have to make an extra effort (and require time) to do it right 2. People are much less likely to learn the keyboard shortcuts
If you designed a GUI to be keyboard first then it might work as you say, but I cannot think of any real life examples of that. I think people need to TUI look to push them to use keyboards.
Compare a proficient travel agent who speaks Sabre to you booking a flight on Skyscanner. They’d whup your ass.
https://youtube.com/watch?v=G8n0_3t-EhI&pp=ygUPc2FicmUgY2xpI...
Similarly with IDEs and programming - saving 0.5-2 seconds for 10-20 operations isn’t my bottleneck once I’ve decided to do the thing; waiting for the corporate antivirus to scan the chrome executable that has self updates since it last saw it, plus the VPN timeout because I haven’t logged into a corp site in 3 hours is.
Besides, visual tools can and do have very powerful shortcuts. ‘Make run’ takes longer to type than pressing F5 does, in visual studio. Photoshop, Maya, Nuke, ProTools, Final Cut, even Unity/Unreal are all graphical tools that have powerful widely used keyboard shortcuts.
Heck, there are even Win32 and X Windows APIs designed with the exact purpose for keyboard navigation and shortcuts.
Maybe instead of doing TUIs one should better spend their time learning the tools of their craft.
Skyscanner failure to adopt such tooling, which browser also have due to accessibility requirements, has nothing to do with technical issues, all about skill and willingness where to spend budget.
https://learn.microsoft.com/en-us/windows/win32/inputdev/key...
https://tronche.com/gui/x/xlib/events/keyboard-pointer/keybo...
Although I'm sure its technically possible to do it, in reality no gui apps work that way and extra keystrokes end up lost while web forms refresh or a 2 tier app is waiting for the DB to respond.
Much faster to use on a keyboard than point clicking all over the place with a mouse on the screen or typing the long commands and flags and forgetting a single flag and having to typing it once again.
On macOS, you can hold Option and click to emulate the correct amount of left or right arrow presses to move the cursor.
So, no, you don't need to type the whole command again. I would personally probably hit Ctrl + a and move my cursor forward a few words to where I need to add the flag.
Maybe it's because I cut my teeth on 80s Turbo Pascal but there's something about the TUI that I feel hits an optimum in the simplicity vs use of visual space spectrum so, so lost in a world of Vulkan etc.
Turbo Vision was great and one of the frameworks I am most found of, back in 1990.
> I am a fan of terminal aesthetics in general
But the reason it feels so off, or uncanny valley, to me is it looks like what someone thinks a vim interface is, but doesn't feel that way. No buttons work for me other than "/", but that is a pretty common binding on websites anyways. going to the examples page, things feel more weird. I can do {c,d,l,n} to change my theme and {1..5} to access options, but other than that, nothing works. I see <C-i> for inbox but what does this mean? Control + i? (the usual meaning) That doesn't work. Is it command + i? That doesn't work. The annotation is reminiscent of vim and the landing page looks like vim, so am I in command mode? But then why are there no motions? Is this emacs? Oh, I do search and can go to the style-guides page and h,j,k,l motions work. Oh, l takes me to the right pane? Why is H,M,L missing?
To be fair, a lot of TUIs have these same uncanny feelings, but I want to draw your attention to this as it appears people like me are your target audience and I do want this product, so I really do want you to understand what I need and how my space works. There is a lot of method to the madness with vim. A lot of people make the mistake of trying to memorize commands instead of memorizing patterns. There's too much in vim to memorize all individual commands, but if you approach it in the way of there are motion keys and action keys then honestly, you can be highly functional in vim in an after noon! (vimtutor does communicate this btw) So the things like how the theme switching and application switching feel very non-intuitive to me. I have to learn something new but it throws me off because visually it looks like I should be doing another set of patterns. For the theme switching I would expect to do something like `:colorscheme dark` or have some action associated with this (idk, c would be find since you aren't going to be cutting text?) and then an associated motion. The application switching I would want to move like I do with buffers. gt and gT to cycle through, 1gt to go to the email (first), 5gt to all components (5th).
So I love the idea and really, I do want this thing to exist. But at the same time it feels like bizarro land to me. Many TUIs make these same mistakes and it leaves me with the same feelings. What I really want is for the wheel to not be reinvented. In a typical webpage I can surprisingly use a lot of keyboard commands and even use some motions. But what things like vim are very useful for is the movement. It is not a text writer, it is a text editor. So it is important that I be able to have fine control and be able to move through a document (page) quickly. It is important that there is this synergy of combinations of motions and commands (or some other philosophy!) that I can learn the basic rules from and then extrapolate from there. This is the thing that gives me superpowers in the terminal, and this is the exact reason I so desperately want something like this around the web. But I also understand why this is difficult and often missed. After all, most vim users I know never learn the vim meta. But I really want to speak up, not to talk you down but because I really want to see something like this succeed and I want you to understand where these "super powers" come from. It's non-obvious unless you get deep into it, but there is a connecting philosophy that allows people to know how to do something new without having ever been told. You get to a point in vim where it is speaking a language and that is the end goal. Do not design one offs and just maps to useful motions, a good interface has to be a language because the goal is to communicate with the machine.
I hope this makes sense. I really do want to see this thing become a reality. To bridge this gap between our worlds.
I'm working on a new project to build some simple workflow applications for business, and one of the aspects I would like to attempt to resolve is the speed of input. It is painful watching operators work with modern GUI inputs, particularly web based as the mouse work slows them down horrendously. And keyboard 'shortcuts' where they exist are often anything but, as the entire GUI model assumes a mouse (or on the web a Document) first.
It is like you mention about this CSS library, it kind of misses the point in that the awesomeness of TUI is not in the appearance, but rather how workflows that the constraints of a keyboard-first interface enforce allow creative and highly efficient solutions.
When all you have is a mouse everything becomes a click, and that is a horrible way to input data.
People see the aesthetics and appreciate the beauty but the best way I can describe the problem is it's like trying to write poetry in a language you do not understand. You can get the rhythm and tone but it has no substance. The aesthetics are driven from the language, the way we play, the way we speak. There's something natural to this but only when you're fluent. The art is a reflection of us. It looks like something you pull from outside, a craft to hone, a monument to build; but it will always miss because it is an expression, a feeling, it comes from you.
I don't know how to describe it like a linguist would describe a poem. There's depth they see that I don't. I only know the feel, the way Sylvia Plath can make me feel but Su Shi never will. I can appreciate it from afar but it remains foreign. I do not know the language, the culture, the context, so I can only be a stranger as if looking through glass.
But I do know this. We programmers often fail to see when building and designing things. The Zen of it is to use your things the same way you use the grass under your feet or the air you breathe. It feels weird to call the ground a tool but you use it to move. I certainly do not have the right words but I hope the meaning is clear. The point is to build something that feels as natural as the air you breathe. A space to live in and makes you feel free. It's okay if this has to be learned but there's something more I don't know how to describe. It's like saying it's okay to learn a new language but recognizing that the concept of language itself is natural and part of us. Even without a language we still speak, there is a drive to make sound, to communicate, to express. It makes language inevitable yet as difficult to describe in detail as the beating of your own heart. It's just you
> When all you have is a mouse everything becomes a click, and that is a horrible way to input data.
Quite a few people access web pages via a table or phone. Touch is often easier than a mouse (not always, though), and can also outdo a keyboard.
I think web-based TUI is a very small niche. Large-scale data entry might be about the only place where it could work, but then you'd want a highly tailored, ergonomic, user-friendly interface.