Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building a TUI is easy now

hatchet.run

Post reply on HN
Print view View original

231–240 of 262 posts

Re: Building a TUI is easy now

#231

Post by 1313ed01 »

1123581321 wrote: post #34
SoftTalker wrote: post #12

I don't see any real advantage of TUIs over web forms or GUIs for the same thing. I do like CLIs though, especially the ones that are properly capable of working in pipelines. Composing a pipeline of simple command-line utilities to achieve exactly what you want is very powerful.

I like a TUI when I always want an app to run side by side with a CLI. It’s easier to do split windows in a terminal or tmux/zellij panes than to script two separate app windows to stay locked together as a pair. Although, I’d welcome advice as to how to do it better. I also find TUIs are easier to program for the same reason they’re limited. Fewer human interface aspects in play and it’s not offensive to use the sam…

> It’s easier to do split windows in a terminal or tmux/zellij panes than to script two separate app windows to stay locked together as a pair. Although, I’d welcome advice as to how to do it better.

Did you try some tiling window managers and decided you did not like that?

Re: Building a TUI is easy now

#232

Post by 1313ed01 »

pjmlp wrote: post #147

Building TUIs was already super easy in 1990 with Turbo Vision and Clipper on MS-DOS, with compiled languages (TP, xBase), using super fast build times on systems running at 10 Mhz, within 640 KB.

I built a TUI application for MS-DOS (well, DOSBox) recently, just using the few functions in MSC 5.1's included graphics library (plus a few simple BIOS calls) and what a joy compared to web interfaces or any GUI library I have used. Having a fixed screen size and known, limited, character set is at least developer-friendly. Of course there existed more advanced libraries as well, but for a simple TUI just a few functions can go a long way.

https://github.com/microsoft/MS-DOS/blob/main/v4.0/src/TOOLS...

Re: Building a TUI is easy now

#233

Post by 1313ed01 »

emilfihlman wrote: post #2

The thing with TUIs is that, using mobile native virtual keyboards, it's apparently quite impossible to make them behave in a sane way in browsers! I think the only reasonable option seems to be reimplementing one yourself, which is massively stupid.

I use TUIs almost daily on my android phone, either some Linux application in Termux or a DOS application in DOSBox. Both have some extra on screen controls to add special keys, and DOSBox in particular allows adding widgets to control things (including invisible buttons, that are fun to add in some cases over parts of the screen in DOS to give an old game or application touch controls).

Re: Building a TUI is easy now

#234

Post by swordsith »

The cursor CLI was a great springboard for me to make my own frontend to prompt from, I would never use it though god, I implemented git, difs, and chat histories, so i can use it easily from my phone with tailscale. It picks up on my rules and can grep my project, so easy. https://imgur.com/a/HZOEvr7

Re: Building a TUI is easy now

#235

Post by charcircuit »

troupo wrote: post #192
charcircuit wrote: post #185

Earlier quoted context omitted.

That post doesn't say that it takes 16ms to create a scene and have the terminal rasterize and try and present it. That's just the budget they have. It is the upper bound they have to work with. For example Claude Code could emit a strange symbol and if the terminal has to go and load a font from disk to be able to rasterize something that can eat into the budget and prevent the terminal from having a smooth frame ra…

> That post doesn't say that it takes 16ms to create a scene and have the terminal rasterize and try and present it. So they literally take 16ms to rasterize just a few hundred characters on screen. Of those, 11ms are spent in "React scene graph", and they have 5ms to do the extremely complex task of rendering a few characters. 16ms is an eternity . A game engine renders thiusands if complex 3D objects in less time.…

>So they literally take 16ms to rasterize just a few hundred characters on screen

Did you measure this yourself? Where is this number coming from? I am talking about a budget. Even if it takes 1ms total as long as that is under 16 ms that is fine.

Re: Building a TUI is easy now

#236

Post by shakna »

andoando wrote: post #213
shakna wrote: post #133

Earlier quoted context omitted.

> Making 50 SOTA AI requests per day ≈ running a 10W LED bulb for about 2.5 hours per day This seems remarkably far from what we know. I mean, just to run the data centre aircon will be an order of magnitude greater than that.

Air conditioning for a whole data center services a whole data center, not one machine running a task for 1 min

Yes... But the machines in those data centres don't get there without the companies who put them there. You get no tasks for no minutes, without the infrastructure, and so the infrastructure does actually have to be part of the environmental impact survey.

Re: Building a TUI is easy now

#237

Post by wpm »

stingraycharles wrote: post #119
bronlund wrote: post #118

I love Claude Code, but how they made the TUI is just plain stupid. Not how it looks, but you know, the React part.

It’s a very cumbersome UI that feels extremely bloated. Especially if you have a lot of text you want to scroll over — eg i want to see the details of the last X exchanges - it just performs absolutely horribly. It seems like it already was like this from the start, though? I’m not a frontend / TUI dev, but why are these issues so hard to fix?

It's just architected poorly. The job of putting text on a screen fast has been solved for 50 years.

Re: Building a TUI is easy now

#238

Post by emilfihlman »

1313ed01 wrote: post #233
emilfihlman wrote: post #2

The thing with TUIs is that, using mobile native virtual keyboards, it's apparently quite impossible to make them behave in a sane way in browsers! I think the only reasonable option seems to be reimplementing one yourself, which is massively stupid.

I use TUIs almost daily on my android phone, either some Linux application in Termux or a DOS application in DOSBox. Both have some extra on screen controls to add special keys, and DOSBox in particular allows adding widgets to control things (including invisible buttons, that are fun to add in some cases over parts of the screen in DOS to give an old game or application touch controls).

I also use Termux daily!

It's really a superb tool.

I only wish we could have that same experience without requiring a native app.

Re: Building a TUI is easy now

#239

Post by troupo »

charcircuit wrote: post #235
troupo wrote: post #192

Earlier quoted context omitted.

> That post doesn't say that it takes 16ms to create a scene and have the terminal rasterize and try and present it. So they literally take 16ms to rasterize just a few hundred characters on screen. Of those, 11ms are spent in "React scene graph", and they have 5ms to do the extremely complex task of rendering a few characters. 16ms is an eternity . A game engine renders thiusands if complex 3D objects in less time.…

>So they literally take 16ms to rasterize just a few hundred characters on screen Did you measure this yourself? Where is this number coming from? I am talking about a budget. Even if it takes 1ms total as long as that is under 16 ms that is fine.

> Where is this number coming from?

They literally complain about that in yhe tweet I linked. That they spend 11 ms in React and only have 5ms to do the impossibly hard task of outputting a few characters on screen.

> Even if it takes 1ms total as long as that is under 16 ms that is fine.

How is it fine when you can re-render the entire terminal in microseconds (I also linked a demo for that, too), and they take 11 milliseconds just "constructing React scene"?

It doesn't matter if they take 12ms to render or 16ms. You're completely missing the point.

Re: Building a TUI is easy now

#240

Post by syene »

Y-bar wrote: post #170
syene wrote: post #126

Earlier quoted context omitted.

It rendered perfectly, without JavaScript, in Emacs EWW.

I think perhaps Emacs does not support the `hidden` attribute? https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... If you check the source (not the DOM) the actual content is loaded in ` ...` which is then moved/copied into the proper main content div in the DOM using a JS event it seems.

It must have sent it differently if the browser reports it can’t do JavaScript.
Post reply on HN