WebTUI – A CSS Library That Brings the Beauty of Terminal UIs to the Browser

The obsession is because it is still the best. For all its faults, I'm still terminally terminal. The beauty of it is in the utility and how it becomes so natural. It's a language you learn that gives you so much freedom you cannot find anywhere else. I've tried many IDEs but I'll always come back to vim. It might have taken time to learn but this is true for anything else. I didn't learn a tool, I learned a language. I didn't learn to run, I learned how to move my legs. With that I could teach myself, I can walk, I can run, I can jump, I can dance, I can be anything I want to be. In VSCode I can walk, hell I might even be able to run, but there is no dance, there is no "me".

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

GP talks about how you develop those TUIs, not TUIs themselves.

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 ‘’’

It is a different design decision. You do not have to choose all capabilities of modern browsers when you do sth.

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.

> I've tried many IDEs but I'll always come back to vim.

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.

> Web model is objectively better than [...]

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.

Hmm I just use :w<cr> to save in my graphical editors too. It’s easier to type.

> If you like monospaced fonts and character grids, you can probably render that with plain SDL

You don't even need SDL https://github.com/cmuratori/refterm

If it is still the best, what's the superior terminal equivalent for Photoshop, Premiere, Audacity, and Figma?

Not everyone's work life revolves around text just because yours does.

Interesting project, but you still need to hook it up to a backend to create a window to draw pixels on. SDL is likely the most portable library to do that; you could substitute fbdev, DirectX, wgpu, glfw, win32, metal, and so on.

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.

What a lovely sentiment. Fully agree; staying in the terminal for as much as possible makes for far less friction when context-switching.

Text-based interfaces can be done with techniques other than simulating a very restricted device from 1978.

> Not everyone's work life revolves around GUIs just because yours does.

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.

No, it's objectively more difficult to type [on a qwerty keyboard].

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.

> Two things can be true at the same time, TUIs are superior to GUIs, and GUIs are superior to TUIs.

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.

I use two hands to type, but if I only had use of one I’d probably use a different key sequence, or more likely a different input method.

But the original terminal was also already using a side channel. You used them to connect to a remote piece of hardware and weren’t running anything locally. In that sense ssh itself is also a side channel.

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.

I think you know your point is obtuse. Context matters in a conversation. You got me! Everyone is going you agree with you, including me. But only got me by moving the conversation to somewhere no one was considering and could be well agreed upon that it was out of scope. It's correct, there's no one size fits all.

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

My terminal can display pictures and use the clipboard. Most of them can in fact. You might be limited in pictures on some but neither do we live in the 90's anymore. I routinely login to remote machines and view the pictures I have stored on them through my terminal

If your terminal is from the 70's you really should get with the times. Check out ghostty or something because things are very different these days

  > I can e.g. rebind Cmd-S to "save", and that's a reason enough.

I'm no emacs user but I'm pretty confident you don't need a GUI for that. I can certainly do that in vim in the terminal.

  :nmap <C-s> :w<CR>

  > In vi, it's "Esc-q!-Enter"

That's not accurate. In vi it is :q<cr> (: then q then enter). The escape (or <c-[) is only necessary if you're in write mode. "!" Is only necessary if you've modified the document and want to force quit.

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?

> 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.

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 ...

To support this claim I'd like to give a common example in vim. Everyone hates `esc`, right? Well I use `<C-[>` instead. Yeah, that's control plus left bracket. 2 keys! But this is a hell of a lot easier that lifting my hand from the keyboard to reach to the top left corner. I just drop my left pinky slightly and move my right ring finger slightly. Both actions are quite normal in how I just type and my wrists never lift. Using two hands is what makes it easy. I neither type with a single finger, I use every one of them. :w<CR> is not hard because :w might as well be one key (plus I'm always hitting : so the action "burns in" as any constant motion does), w is just a normal key requiring very little movement from my rest state, same as pressing enter (pinky).

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.

Good thing you can bind arbitrarily complex action to a key/combination in a programmable editor and avoid this semantic fuss whatsoever.

right but easy doesn't always mean fewest key strokes, it can simply mean "I have muscle memory for exiting this editor that I use 43% of my working hours with so Imma map it to exiting my browser and ________ app as well." . I personally have to move between too many systems for something like that to be useful to me but if you stay on a single machine most of your work day I can see the value.

> My terminal can [...] use the clipboard.

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.

> But the original terminal was also already using a side channel.

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.

Sure, I'm not going to use my terminal to watch HD movies in. Nor am I going to use it to browse the web. But we're being a bit obtuse here in thinking the terminal is going to do everything. There is no single tool that solves all problems. Not even the computer, as general as it is. That's okay.

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.

> Here's the painful truth: you can't quit a TUI application without learning it

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.

https://github.com/benotn/kkp

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 so sure you can learn Photoshop [...]

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.

> But let's be honest, what you're doing is a narrow specialisation - and that is what you're being paid for

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.

Ghostty seems to support a subset of the xterm protocol. Sure, a bit more advanced than VT100, but still it still is, as the ghostty dev puts it, "very often touted as the gold standard for historical terminal behavior."

https://mitchellh.com/writing/ghostty-devlog-005

I think you're reading things with the intent to support your conclusion rather than with intent to understand what is being communicated. Including the basic fact that xterm is itself an improvement upon VT100.

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?

Your 70's terminal can't even do window resizing, let alone accurately render that. Then comparing it to something that realistically could run 4k videos in it. Go look at the notcurses demo[0]. I'd love to see your 70's terminal do anything close to that.

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.

[0] https://notcurses.com/

> Partly because they do it badly, and partly because it's harder for other applications to read the pixels.

I can select text in a web browser or a spreadsheet or a chat app just fine.

> 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.

How does a terminal emulator render text on the screen then? Your screen is made of pixels.

> And you learned that somehow. You can learn other things too.

You're missing my point entirely, but you seem to enjoy taking an hour to open every new door. I won't judge that.

  > You're missing my point entirely

The reason you're having a hard time communicating is because, honestly, you do not understand how these things work. You've made assumptions about how they work but be honest with yourself, could you code them up yourself? I don't mean gluing some libraries together, I mean straight up in C. I'm pretty sure the person you're responding to would say they couldn't (I sure couldn't!). Not because lack of experience in C but because they have a better understanding in all the details that goes into these things.

  > How does a terminal emulator render text on the screen then? Your screen is made of pixels.

This alone says a lot, even if you don't know it. Do you know how pixels are painted on a screen? I know you got this thought in your head like "duh, you just give each one an RGB value". Great! But how do you determine what pixel gets what values? How do you define a letter? It is not just as easy as making a predefined box where you have constructed the letter inside. Look up ligatures. Now how do you do colors? How do you define different fonts? How do you scale? How do you scale without turning your text into a bunch of giant pixelated crap? Do me a favor, increase the font size on your terminal and keep going to a really ridiculous size. Then do the reverse, make it ridiculously small. Everything still should look sharp. You can't do that by having a predefined box that says where to shade and not shade without aliasing. It wouldn't look sharp when big nor small because even going small the interpolation methods are still going to introduce aliasing. To go big you either need a fucking gigantic image for each letter or something different.

You're not going to be able to communicate effectively because you're actively demonstrating to people that you think you know more about how these things work than you actually do. I get it. The modern way people learn CS and programming is so high level and there's this bad culture of being know-it-alls, as if there is some shame in not knowing how things work. Shit's complex. Stop pretending like it isn't. There's a huge difference in thinking "there's a lot of complexity here, I need to approximate and just get going" vs "shits easy". If you take the latter you'll never build anything of quality because the truth is that there's massive amounts of complexity even in the most mundane things. If you gain a deep expertise in any single one thing this truth will be self-evident. So thing is, by thinking things are easy you're more telling on yourself that you have no depth. It's fine to be a generalist, but a generalist can't be effective if they think depth doesn't exist. You might as well try walking in the middle of the ocean, because I mean, hey, you were able to walk around on the shore of the beach, why would it be any different?

You're assuming I'm ignorant.

I would also assume so. It's the only way not to be.

Well to be pedantic, no, macOS Cmd-Q is quite distinct from closing the window

I learned Photoshop by clicking the icons that looked like what i wanted to do and then clicking the image to see what happened. I'd never seen anyone else use it and i didn't have Internet access.

Did someone teach you MSPaint? Or notepad? Or did the discoverability of visible controls guide you to how to use them?

There certainly is a bad culture of being know it alls, that much is very apparent

To be extra pedantic, any app following Apple guidelines will quit on Cmd-Q, it should never (and I've never seen it so) only close a window, and alt-F4 isn't any different than clicking the close button with your mouse.

Really the point being, modern GUI applications (hell even not-modern 90s DOS applications) almost universally follow a common set of guidelines that were established many decades ago and have been more or less consistent across multiple platforms for many people's entire lives, vs the land of Vim and emacs and screen et. al. where every app has its own bespoke method of operation.

I think there's a benefit to the former even in TUI apps. If i remote into a client's system, or jump on my coworkers laptop, or am setting up a new system, it's good to know how it's going to work.

Agreed, macOS has different and distinct paradigms from Windows, KDE, or Gnome. But they're (for the most part) more internally consistent.

Say I want to keep the music playing when I close the player window. Other systems have to hack around it by e.g. using the status bar; on macOS it follows from the first principles.