zlacker

This decision is honestly very confusing to me as a constant user of Claude Code (I have 3 of them open at the moment.)

So many of the issues with it seem to be because ... they wrote the damn thing in JavaScript?

Claude is pretty good at a constrained task with tests -- couldn't you just port it to a different language? With Claude?

And then just ... the huge claude.json which gets written on every message, like ... SQLite exists! Please, please use it! The scrollback! The Keyboard handling! Just write a simple Rust or Go or whatever CLI app with an actual database and reasonable TUI toolkit? Why double down and buy a whole JavaScript runtime?

>>ctoth+(OP)
Boggles the mind.

>>ctoth+(OP)
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.

>>ctoth+(OP)
I have to admit this was my first thought, too. I'm pretty obsessed with Claude Code, but the actual app is so incredibly poorly engineered for something that doesn't even do that much.

Rust, Go, whatever -- writing a good TUI isn't that hard of a problem. Buying an entire VC funded JS runtime company isn't how you solve it.

>>dboon+v6
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+x8
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+y9
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+Mb
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+v6
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

>>ctoth+(OP)
“Port it to a different language” a language that’s more out of distribution? Bad devex. Store data as an unreadable binary file? Bad devex.

Stay in distribution and in the wave as much as possible.

Good devex is all you need. Claude code team iterates and ships fast, and these decisions make total sense when you realize that dev velocity is the point.

>>dboon+v6
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+Po
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.