WebTUI – A CSS Library That Brings the Beauty of Terminal UIs to the Browser • Hacker News Board

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

#141

Post by geocar » Mon, Apr 14, 2025, 12:46 PM UTC

rollcat wrote: post #135

geocar wrote: post #133

Earlier quoted context omitted.

> it just remained stagnant for the past 30 years. (Unlike terminal emulators, which do boring things, and have been stagnant for 40 years.) 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 perf…

> If you use emacs like you say, you should know you can bind ^C to whatever you want. 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…

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

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

#142

Post by geocar » Mon, Apr 14, 2025, 4:16 PM UTC

pjmlp wrote: post #137

geocar wrote: post #94

Earlier quoted context omitted.

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

> Sounds dreadful. 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 (loade…

> Oh boy, I definitely know Oberon.

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

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

#143

Post by ranger_danger » Mon, Apr 14, 2025, 7:51 PM UTC

mrighele wrote: post #111

sgt wrote: post #75

Earlier quoted context omitted.

Occasionally when you see someone using a point of sale terminal that is terminal based, the operator usually flies through the interface like it's nothing. 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.

That has nothing to do with the interface being a terminal, but with the primary input method being a keyboard instead of a pointing device. 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 thi…

Yes, but given the choice, I think most people would opt for the less-efficient mouse navigation on a web page, even if there were no actual upsides to doing it that way.

If a business forced a keyboard-only input method, then that might help to raise the efficiency of everyone more equally.

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

#144

Post by ranger_danger » Mon, Apr 14, 2025, 7:58 PM UTC

c-hendricks wrote: post #98

kmeisthax wrote: post #92

Earlier quoted context omitted.

Good GUI apps have shittons of keyboard shortcuts to achieve the same result. The ideal is that the qualified operator keeps their hands on the keyboard for anything that isn't an actual pointing operation. For example, in a video editing app, you can rough-cut with a handful of keys[0] for setting in and out points, jogging through the source material, and inserting into the current active timeline. The keyboard isn…

> I wish every GUI app had searchable menus On macOS and KDE (Wayland), they do! Agreed it's really handy.

What exactly makes an app a "KDE app"? Obviously a game with a custom UI is not going to have the same searchable menu, right?

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

#145

Post by jampekka » Mon, Apr 14, 2025, 9:02 PM UTC

godelski wrote: post #103

jampekka wrote: post #72

Earlier quoted context omitted.

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

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

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

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

#146

Post by godelski » Tue, Apr 15, 2025, 2:11 AM UTC

jampekka wrote: post #145

godelski wrote: post #103

Earlier quoted context omitted.

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

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/

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

#147

Post by rollcat » Tue, Apr 15, 2025, 8:33 AM UTC

geocar wrote: post #140

rollcat wrote: post #134

Earlier quoted context omitted.

> 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 e…

> 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 i…

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

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

#148

Post by godelski » Tue, Apr 15, 2025, 6:58 PM UTC

rollcat wrote: post #147

geocar wrote: post #140

Earlier quoted context omitted.

> 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 i…

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

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

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

#149

Post by rollcat » Wed, Apr 16, 2025, 10:50 AM UTC

godelski wrote: post #148

rollcat wrote: post #147

Earlier quoted context omitted.

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

> 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!).…

You're assuming I'm ignorant.

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

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

#150

Post by c-hendricks » Wed, Apr 16, 2025, 4:03 PM UTC

ranger_danger wrote: post #144

c-hendricks wrote: post #98

Earlier quoted context omitted.

> I wish every GUI app had searchable menus On macOS and KDE (Wayland), they do! Agreed it's really handy.

What exactly makes an app a "KDE app"? Obviously a game with a custom UI is not going to have the same searchable menu, right?

I don't think I mentioned "KDE app" or games? KDE's Global Menu works with apps built with other toolkits than QT, and games are typically not considered apps. It would be cool if games did something similar though, I would love to be able to go into a games options and type "subtitles" to quickly find the option.