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

211–220 of 262 posts

Re: Building a TUI is easy now

#211

Post by 1vuio0pswjnm7 »

mrandish wrote: post #60

Alex, It's somewhat ironic that a web page about performant terminal user interfaces uses gratuitously complex CSS mask compositing and cubic gradients which reduce smooth scrolling on my 1 year-old, high-end Dell XPS laptop (>$3k) to Commodore 64 level (on default 'Balanced' battery mode). While it's pretty , it's also just a very subtle, non-critical background animation effect. Not being a CSS guru myself, here's…

To read using Firefox, or any browser/HTML pager, without Javascript or CSS:

   (
   printf 'GET /blog/tuis-are-easy-now HTTP/1.0\r\n'
   printf 'Host: hatchet.run\r\n\r\n'
   )|busybox ssl_client hatchet.run \
   |(echo "";grep -o "") > 1.htm
   firefox ./1.htm

Re: Building a TUI is easy now

#213

Post by andoando »

shakna wrote: post #133
coldtea wrote: post #96

Earlier quoted context omitted.

Would it be that many? Asked AI to do some rough calculation, and it spit that: Making 50 SOTA AI requests per day ≈ running a 10W LED bulb for about 2.5 hours per day Given I usually have 2-3 lights on all day in the house, that's like 1500 LLM requests per day (which sounds quite more than I do). So even a month worth of requests for building some software doesn't sound that much. Having a local beefy traditional b…

> 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

Re: Building a TUI is easy now

#214

Post by basilikum »

dwb wrote: post #48

I think TUIs-that-want-to-be-GUIs (as opposed to terminal commands just outputting plain text) are sad. Mainly because they’re largely inaccessible. They flatten the structure of a UI under a character stream. You’re forced to use it exactly the way it was designed and no different. Modern GUIs, even web pages too, expose enough structure to the OS to let you use it more freely. I get why people build TUIs, but it’s…

I like that they are integrated into the terminal and stay in the terminal. For most things my terminal multiplexer is essentially my tiling window manager and everything that breaks out of that via its own window is very unergonomic and breaks the structured logic of my workflow. Technically just having a full GUI inside the boundaries of a terminal would be fine for a lot of things. But it's also one of these things where constraints make a lot of things better. Many GUIs are just really bloated and bad. TUIs just do not allow a lot of the sins of modern GUIs.

I agree that they can get very clunky for non text based tasks or anything where you actually need custom text formating.

Re: Building a TUI is easy now

#216

Post by abelanger »

Y-bar wrote: post #169

Hey! This looks great, and I appreciate the effort! But just opening the page at https://tui.hatchet.run/ causes my (admittedly old Intel i7 9700K) to spin up its fans and consume >30% of the CPU without me even doing anything. I don't think a TUI should do that. I was also intrigued by it being a lot of Go dependencies as I have developed a bit of a fancy for this language recently.

Hi, thanks! To be clear, the demo there is merely a WASM-based Ghostty build which is rendering the TUI on a web page, just so people could try it out without needing to install anything. The actual TUI runs in your terminal. I'm guessing it's the WASM side of things causing the fans to spin, which you wouldn't see locally.

Re: Building a TUI is easy now

#217

Post by californical »

brabel wrote: post #194
9dev wrote: post #145

Earlier quoted context omitted.

The analogy mostly makes a point for snobbishness, but otherwise doesn’t really work. Most people would rather eat meals prepped by a Michelin star cook, but they can only afford microwave meals - whereas EMacs/Vim and VSCode are equally accessible to anyone.

I love emacs but would never compare that with a Michelin meal! On the contrary, emacs is the DIY option that lets you experiment with whatever ingredients you please without judging your choices!

I think their point was about “most popular” not necessarily meaning “better”. I don’t think they meant anything more by it

Re: Building a TUI is easy now

#218

Post by Aldipower »

mrandish wrote: post #60

Alex, It's somewhat ironic that a web page about performant terminal user interfaces uses gratuitously complex CSS mask compositing and cubic gradients which reduce smooth scrolling on my 1 year-old, high-end Dell XPS laptop (>$3k) to Commodore 64 level (on default 'Balanced' battery mode). While it's pretty , it's also just a very subtle, non-critical background animation effect. Not being a CSS guru myself, here's…

Don't blame my Commodore 64. Once a program is loaded it, runs with 50 or 60hz refresh rate, which is very smooth! Take that! :-)

Re: Building a TUI is easy now

#219

Post by dchuk »

arjie wrote: post #65

TUIs are great fun and Claude can make beautiful ones with a little ratatui action super fast. However, the downside of these are that you can't use them with Claude Code so while I have a few I prefer to also have a prompt-response CLI function since that's better for lots of things.

This works very well for automated testing from Claude code: https://github.com/pproenca/agent-tui

Re: Building a TUI is easy now

#220

Post by abelanger »

shevy-java wrote: post #149

> Notably this was the first time I felt that using Claude Code for something non-arbitrary was significantly faster than doing it myself Well, it is like code completion on a higher level. I still don't like this approach. Besides, who is going to maintain that code? Such code will probably forever be required to be maitnained via Claude. So no humans involved. Just autogenerated stuff. I dislike this idea a lot. Hu…

Author here - I'm also generally skeptical of coding agents, but with the right problem domain and approach they can produce quality output when paired with humans. There was a point in time in the chess world where computer + human was stronger than computer or human alone. I think we're in that era for a handful of applications. Not for things like kernels, browsers, or databases.

> Besides, who is going to maintain that code?

I maintain the code. If Claude gets sunset tomorrow, I'll still be able to maintain and write it - I've already rewritten parts of it.

You could make the same argument for a team member leading a project that you've worked on. Is that code forever required to be maintained by one team member?

Previously the overhead of ensuring code quality when the development process was driven by Claude Code was greater than just writing the code myself. But that was different for this project.

Post reply on HN