zlacker

Ink (and modern alternatives) probably are the best TUI toolkit. If you want to write a UI that's genuinely good, you need e.g. HTML, or some way to express divs and flex box. There isn't really another way to build professional grade UIs; I love immediate mode UI for games, but the breadth of features handled by the browser UI ecosystem is astonishing. It is a genuinely hard problem.

And if you're expressing hierarchical UI, the best way to do it is HTML and CSS. It has the richest ecosystem, and it is one of the most mature technologies in existence. JS / TS are the native languages for those tools. Everything is informed by this.

Of course, there are other options. You could jam HTML and CSS into (as you mention) Rust, or C, or whatever. But then the ecosystem is extremely lacking, and you're reinventing the wheel. You could use something simpler, like QML or handrolled. But then you lose the aforementioned breadth of features and compatibilities with all the browser code ever written.

TypeScript is genuinely, for my money, the best option. The big problem is that the terminal backends aren't mature (as you said, scrollback, etc). But, given time and money, that'll get sorted out. It's much easier to fix the terminal stuff than to rewrite all of the browser.

>>dboon+(OP)
The idea that you need or want HTML or CSS to write a TUI is missing the entire point of what made TUIs great in the first place. They were great precisely because they were clean, fast, simple, focused -- and didn’t require an entire web stack to draw colored boxes.

>>frumpl+22
I'm not so sure about that. I've written some nontrivial TUIs in my time, the largest one being [1], and as the project got more complicated I did find myself often thinking "It sure would be nice if I could somehow just write this stuff with CSS instead of tiny state machines and control codes for coloration". There's no reason these languages couldn't compile down to a TUI as lean as hand-coloring everything yourself.

[1]: https://taskusanakirja.com/

>>hiAndr+33
I'm certainly not advocating for a return to C + ncurses, but there's a wide ocean of options between that and HTML+CSS+JS in the terminal.

>>frumpl+h5
Yes, for simple projects, absolutely. But when you're shipping something as widely adopted as CC, I disagree. At the end of the day, you're making a UI. It happens to be rendered via the terminal. You still need accessibility, consistent layouts, easy integration with your backend services, inputs, forms, and so on. If you don't need that stuff, there are lots of other, simpler options. But if you do, your other options begin to resemble a half baked, bug filled reimplementation of the web. So just use the web.

>>dboon+(OP)
Ink seems to be the root cause of a major issue with the Claude Code CLI where it flickers horribly when it needs to repeatedly clear the screen and redraw.

I don't know why it's even necessary for this.

https://github.com/atxtechbro/test-ink-flickering

Issue on Claude Code GitHub:

https://github.com/anthropics/claude-code/issues/769

>>dboon+(OP)
I like JS for this use case, and React on web, but really not fond of the Ink usage. Idk if it's Ink itself or the way it gets used, but somehow people are making CLIs that lag and waste terminal space now.

>>dboon+ki
I don't think you and I live on the same planet when it comes to engineering, but I'm used to that when it comes to folks who have spent their entire career in the web stack.

The web is the half-baked, bug-filled reimplementation of the native application stack. We figured these problems out a long time ago, and the constant wheel re-invention from folks who only know and refuse to use anything but the web is getting old. I'm tired of everything you produce being slow, buggy, and consuming gigabytes of RAM.