It largely works and it's a massive business success. This is the classic engineer asking the 'why this technology?' to what amounts to a business question.

They chose it early on, it works, and it makes obscene amounts of revenue. End of story. That doesn't mean it was the "greatest" choice, or has a perfect technical architecture.

Rewrites are never easy, even the bun rewrite. But a non-UI developer tool with a rigid API surface contract (and associated tests) will always be easier to trust after a rewrite than a partially tested UI tool with ambiguous functionality.

I never knew that running an interactive program in my terminal would absolutely rinse my CPU and battery but that's what Claude, OpenCode and Ghostty have colluded to achieve. Even when the laptop is asleep overnight it's practically melting.

I'm sure there was some logical reason for shoehorning web technology into this stack given that we have a good 40 years or so of experience with interactive terminal programs that use curses/ncurses, alongside emacs, vim, almost the entirety of MS-DOS, and so on.

Codex CLI and Grok Build are both in Rust. OpenAI’s web still use react. Previously their CLI was React Ink until they ported most of it to Rust

It is kind of mind boggling. They could have chosen anything and decided to implement it in the slowest jankiest way possible.

Proves LLMs don’t help with taste.

> why the hell does a TUI need to run in terminal React by way of JavaScript

Because React is the only UI framework that takes the problem seriously. Everything else is stuck in the dark ages.

How HN gets this so badly backwards I'll never understand. Everyone on this site talks a big game about "there shouldn't be so many competing tech stacks, why can't everyone work together on one framework that does things right", and then as soon as that framework actually appears this site hates it more than anything.

I recently saw a blog post [1] about a famous Haskel shop moving away from Haskell to Python because the iteration speed with LLMs was just that much better. There is so much React in training data, TS compile times are minimal compared to Rust and similar.

I suspect user facing/fast moving code (UX layer) will move to dynamic systems with fast iteration times. Infra layer will move towards safe systems level environments like Rust. I'm not sure where Java/C# lands in all of this - it's kind of the middle ground between these two worlds but the tradeoffs change drastically with LLMs - my gut feeling says that TS/Python is good enough for UX work and Rust is better for systems work so it gets less popular going forward.

[1] https://avi.press/posts/2026-07-10-after-7-years-in-producti...

Why would rewriting Claude code, an app which probably has 30-40 (I might be significantly underestimating) extremely active contributors be easier than rewriting Bun, which has fewer contributors and almost certainly also less lines of code?

Yknow, I really didn't mind Claude Code that badly, but subjectively speaking I really do like Codex more after using it for a couple weeks. Feels a bit snappier and lighter weight. I know with OpenAI you can actually use third party tools with the subscription so there's less of a draw to using Codex, but I still find myself preferring it now.

Is this because Codex is written in Rust and not JS? I dunno. I think it's more just "lighter" in general, or it certainly feels that way. It's probably possible to make something with a similar feel in JS, just perhaps not with the big honking mess they've created.

>If rewrites are so easy, why not rewrite CC in a native language? Would’ve been a hell of a lot cheaper.

Yeah, good question. OpenAI decided to rewrite Codex in Rust about a year ago[0].

In fact, since rewrites are that easy, what do we need Bun for? Why doesn't everybody just port all of their Javascript code into Rust?

[0] https://github.com/openai/codex/discussions/1174

As a counter argument - I assume that Anthropic is using AI to write Claude Code.

I've read and heard in videos that Javascript is a pretty good language for AI to write code in. Apparently this is because there is so much training data out there. Also Javascript avoids problems of multi threading and memory management that can mess up the AI in other "more performant" languages.

So maybe Javascript is not the worst choice for writing software fast with AI

> If rewrites are so easy, why not rewrite CC in a native language? Would’ve been a hell of a lot cheaper.

It was unpleasantly surprised when I learned the hard way that LLMs are not much better at translating than writing from scratch.

The more you look into how they work, the more you see that it doesn't really give them a huge advantage, if the classes are big enough. You can tell them to break each function up and translate them one-by-one, but the errors compound, you can't test most of it until you have a lot done, and in the end, it really isn't much faster (and sometimes it seems to be a lot slower) then just telling them to start over from scratch.

The downside is... If you have a system that already works, you don't want to start from scratch and test everything all over again...

I asked this in a thread with a CC author a few months ago (I felt — and hope — very politely, with similar background.) No reply. https://news.ycombinator.com/item?id=46716974

I think Moore's Law and related have made programming sloppy. AI is building on that. There was a time where accounting for memory, footprint, stability, and speed mattered. Your point shows we are well passed that aside from certain areas.

Heck, a buddy and I once chatted about the likelihood of k8s running as the control plane in a prototype autonomous vehicle.

top/btop/htop on the mac are always fun to run and see what's up.

I'm confused as well, could someone who knows how TUIs work explain what's the point of React-style diffing in this context? I thought you need to clean and full redraw if anything changs anyways?

Cause it works, most users are fine with it, people don't migrate off it because of the codebase, and easier to maintain if the dev team is familiar with code flow.

This is close to the same "why Spotify is a chromium embed?" question. Because it works, and users are ok with it.

JavaScript is very fast and easy for UI rendering. If it works for web apps it’d also work for the terminal. Sure it’s bloated but it’s fine. The dev velocity of JavaScripts is orders better than rust.

So the code for the web, the desktop app, and the cli where largely similar.

And the TUI fights the terminal on basic things like copy/paste. I end up telling Claude to write all outputs to a tmp file.

Otherwise an idle TUI wouldn't halve my laptop's battery life. Maybe that's an exaggeration but not that much, based on looking at wakeups in powertop.

The answer is those are the tools their lead engineers knew, so they repurposed them rather than learning other paradigms .

> why not rewrite CC in a native language?

It's hell to maintain for not much gain (for a use case like this at least). As much as it's become a meme, JS and web tech in general has become extremely portable and stable.

I also don't think Anthropic bought bun to make their TUI better. They could have forked it, they bought bun because it incidentally was excellent for the way agents prefer to work and they wanted to capture that audience.

it is kinda mystifying bc from what i understand their engineering ethos is very much "if it's not working, just regenerate it" (which i completely understand).

Anything that can be written in JavaScript will be written in JavaScript. That's just how it is it seems.

i got annoyed by this especially the memory use and non portability aspect of bun so I had claude (lol) and kiro cook up my own agent. it runs on linux, openbsd and even on omnios and esp32. it's just a personal project so there are probably rough edges, but I am using it on my clockworkpi uconsole daily now. https://github.com/mischief/clm

I’m not sure what else can you use to share the same business logic between website frontend, desktop gui and tui apps and backend

Lots of devs know how to code in it, and the AI models have more training in JavaScript than any other language.

It's like asking "why does everything run on Windows?" Because everything runs on Windows.

> Maybe I’m taking crazy pills, but I’m still stuck on “why the hell does a TUI need to run in terminal React by way of JavaScript”

No, you are not crazy. They do crazy things with unlimited budget, and still their chat app flickers when using.

They should just port pi-tui from pi coding agent, since they have no clue.

Should have done it in C++ with SDL3.

Probably because claude suggested some kind of wack react based setup early on (because react dominates the training data) and it's be blasphemy worthy of termination for the Anthropic employees to question the sacred pronouncements of the llm.

If you think that way I would recommend just keeping away from these topics. It is just useless arguing and speculating about things don’t matter.

I have been trying to keep away in the last couple weeks and it was all win for me. I still come down here sometimes when I am stressed with real work since it is a strong addiction to see “how terrible the plebs are doing”.

JavaScript is dynamic and supports live reload which means iterations are far faster than would be in a compiled language--even for LLMs.

This is especially useful when you're trying to evaluate behaviors while changing state surgically.