7 ms·

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” The fact that Anthropic felt

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” The fact that Anthropic felt the need to buy a runtime so they could make their TUI better speaks more to the quality of engineering than anything else IMO. If rewrites are so easy, why not rewrite CC in a native language? Would’ve been a hell of a lot cheaper.

deadbabe 3mo ago
Should have done it in C++ with SDL3.
ljm 3mo ago
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.
- deleted 3mo ago
  [deleted]
- senderista 3mo ago
  Why are you implicating ghostty? Have you compared its CPU usage to any other terminal?
  - agrippanux 3mo ago
    I don't know if its still the case anymore since 1.3 but Ghostty did have a documented issue with Claude causing resource issues.
  - tdhz77 3mo ago
    I think the author is saying everything that touches llm.
  - ljm 3mo ago
    Of course I have. If I see ghostty constantly consuming the most energy and helping reduce my battery life to barely 2 or 3 hours, the first thing I'm going to do is switch terminal to see if I can improve that situation. The built in terminal and WezTerm have been fine and I've had much more reasonable battery life since. This does not even speak to it pegging my CPU and keeping the fans running on full blast even when the laptop is supposed to be idle overnight.
    - st3fan 3mo ago
      Same. I really want to file a proper bug report for this but I haven't been able to really dig into the details and the last thing I want is a "ghostty is a cpu hog" kind of report without useful info on how to debug that.
    - andruby 3mo ago
      This seems a suspicious. How do you measure the CPU load of Ghostty? Is the measure/reporting method just attributing the cpu load of the commands/programs you're running in Ghostty to Ghostty? You could test this by running "yes > /dev/null" in Ghostty. In Activity Monitor on my Macbook it shows `yes` using 100% and Ghostty using 0.5% of cpu.
    - benrutter 3mo ago
      If you're looking for a non-ghostty recommendation (not that I have anything against ghostty) I use alacritty + zellij and it works fantastic. It doesn't seem to impact battery, I certainly get good battery usage on both my work and home laptops.
      - mtlmtlmtlmtl 3mo ago
        I've messed around with pretty much all the fancy new terms to varying extents. Ghostty, wezterm, alacritty, etc. And I'm all in favour of people innovating in this space again. But at the end of the day, I always end up back with xterm. It's reasonably lightweight, runs and is packaged absolutely everywhere, I never have to muck about with termcap files and/or $TERM on remote hosts, and I've never had it break, crash, or exhibit any kind of bug or strange behaviour in over a decade of using it. The only TUI that has some quirks in xterm is Emacs, but Emacs has weird quirks in every term I've tried to run it in, and different quirks in every case somehow, so I just chalk that up to Emacs being weird. I'm sure xterm has some bugs buried in it still, but I bet all of them are in codepaths that are almost never reached nowadays, or at least are extremely niche. It does lack some features like ligature fonts(I just decided not to care), sixels and similar graphics things(again, don't really care) and panes/tabs/yadda yadda(tmux or screen or whatever you like can do all of that anyway). Never had to dig through the xterm bug tracker to figure something out. I don't even know what version I'm running, or even what the versioning scheme looks like. I haven't changed the configuration since the first time I set it up. It just works.
- myaccountonhn 3mo ago
  Its so wasteful, but that tracks with the modus operandi of AI companies.
- vmg12 3mo ago
  The fundamental problem with all Js based apps is how they are very single threaded. With js you get 1 thread at 100% utilization. Power usage and heat scale non-linearly with cpu utilization and 100% utilization on a single threaded js app means you will have ui lag. Other languages like golang would split work across 8 threads and have 8 threads at 20% utilization and this would result in less power usage. Claude Code would have been better off performance wise being an electron app because it would be offloading rendering to the browser and gpu. Also, the architecture of Open Code is actually a lot better here than Claude Code. ClaudeCode does everything, including rendering in a single thread and it's all in js. OpenCode has a zig based tui renderer it offloads that work onto. But I will also say these coding agent tuis do get unfairly maligned because they launch subprocesses and those subprocesses tend to be expensive. If you are using Rust analyzer with claude code, it's rust analyzer that's causing the majority of your problems.
  - cozzyd 3mo ago
    I'm not concerned with CPU use/wakeups while actively using it, but with it sitting idle doing nothing.
  - skydhash 3mo ago
    That’s not really a big issue. In major OS like the BSD, SMP implementation are not that old. If we can have a full OS running in single core mode, we can have an application being performant too. I’m currently running OpenBSD on 4 cores and it’s basically 99% idle. Bad coding is just bad coding.
    - vmg12 3mo ago
      It's basically idle because it's not doing anything. If you are streaming in markdown and code and then doing syntax highlighting on this code in real time, then rendering it on the screen you are doing actual work. It's also all cpu bound work. The majority of the stuff on your screen is being rendered by the gpu.
      - wild_egg 3mo ago
- blt 3mo ago
  yep, developers from 10 or even 5 years ago would have considered it a hilarious joke
- LtWorf 3mo ago
  > Even when the laptop is asleep overnight it's practically melting. Then something is waking it up and it's not asleep at all. Asleep the CPU shouldn't be running.
dmix 3mo ago
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
deleted 3mo ago
[deleted]
ozgrakkurt 3mo ago
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”.
johnfn 3mo ago
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?
- weakfish 3mo ago
  Because I’ve been told that Fable can do anything :-) My question is moreso “why was it ever JS in the first place” & the cost of a native rewrite would be cheaper than acquiring Bun no matter how you shake it
  - AndrewKemendo 3mo ago
    >Because I’ve been told that Fable can do anything I hear some version of this anecdote constantly yet despite using all these prompting tools since 2019 I have never once heard a lab or professional say “x model can do anything” Can you provide me whatever specific source you heard for this?
    - weakfish 3mo ago
      It’s hyperbolic and intended to generalize the sentiment I perceive from others. Dario Amodei said in January that he expected software engineers to be replaced [0], so I suppose the quote should be extended to “can do anything… a software engineer can do” And I think we can all agree that SWE is on the more complex end of all white collar jobs. So, my thinking is that if SWE can hypothetically be replaced, so can many other jobs. Hence, the claim the models can “do anything” intending to capture the majority of white collar work. This, of course, is if you take their claim at face value - which I certainly do not. [0] https://www.entrepreneur.com/business-news/ai-ceo-says-software-engineers-could-be-replaced-in-months/502087 https://www.entrepreneur.com/business-news/ai-ceo-says-softw...
      - AndrewKemendo 3mo ago
        So then nobody actually has ever said that and its explicitly hyperbole So then its misleading in the extreme to say “I’ve been told AI can do anything” It amplifies hype when people make claims like this by including hyperbolic statements as though they are reflective of the state of the discussion.
switz 3mo ago
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.
- galangalalgol 3mo ago
  The criticism didn't appear to me to be that the solution didn't work, just that many of the working solutions we are selecting are dangerously overcomplicated due to shortsighted decisionmaking. The benefits of throwing redundant stacks of abstraction atop each other in terms of time to market are questionable, and obviously absent in every other metric.
  - weakfish 3mo ago
    Correct And the question of “if AI is so amazing, shouldn’t it enable easy development of a native TUI even if JS is easier at first?” Don’t get me wrong I find great value in coding agents daily. Just finding the hype cycle tiring.
  - bwfan123 3mo ago
    So, you have a vibe-coded TUI which happens to work, and then, as a workaround you vibe-translate its engine to make it more performant. Where does that leave you ? Basically, fully dependent on AI to fix whatever breaks. Workaround on a workaround is the way I see it, and it aligns with the AI design mentality in general. For a variety of usecases, this might still be a win in terms of overall cost. But, for software that is intended to be built to last, I dont see this approach working out.
    - jubilanti 3mo ago
      > for sw that is intended to be built to last, I dont see this working out. the era in which the tech industry built software to last was over long before LLMs, especially VC-backed startups.
deleted 3mo ago
[deleted]
voidhorse 3mo ago
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.
sroussey 3mo ago
So the code for the web, the desktop app, and the cli where largely similar.
- qudat 3mo ago
  The component trees have to be rewritten, only the non-view related JS code can be reused.
hellohello2 3mo ago
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?
- delusional 3mo ago
  Ncurses is how people used to do it.
- qudat 3mo ago
  You can do damage tracking for TUIs. Printing to the terminal is done by moving the cursor and redrawing the line the cursor is on.
- tredre3 3mo ago
  > I thought you need to clean and full redraw if anything changs anyways? Unless you use an ancient teletype, you don't have to redraw everything. That would make any interactive applications way too slow/flickery. You can move the cursor arbitrarily in the terminal and start overwriting characters from there. So you need to track state to know what is "dirty" and needs refreshing. Occasionally you issue a full redraw to catch missed artifacts left behind or when the terminal is resized (SIGWINCH).
  - deleted 3mo ago
    [deleted]
fny 3mo ago
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.
- nozzlegear 3mo ago
  There's no surgery when you're a company with a trillion dollar hammer and every problem looks like a big ass nail.
- amoss 3mo ago
  If you are relying on live updates to change state in a dynamic language then you are not doing it "surgically", unless there is some other definition that means hitting it softly with a large rock.
- pjmlp 3mo ago
  There are several compiled languages with live reloading, including C++.
newswasboring 3mo ago
Anything that can be written in JavaScript will be written in JavaScript. That's just how it is it seems.
cozzyd 3mo ago
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.
onetrickwolf 3mo ago
> 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.
- simonw 3mo ago
  I think they bought Bun because it was a supply chain risk for them. Their new flagship product (earning them billions of dollars in revenue per month) was dependent on a platform maintained by a tiny startup. Buying Bun was a very rational way to reduce that risk, epically since it also got them some top tier engineering talent. Thinking about that further, I wonder if that was part of the rationale for switching from Zig to Rust that they haven't talked about? Zig is a much riskier bet for your multi-billion dollar cash cow than Rust is. But saying that out loud would be rude - they took steps to NOT openly criticize Zig, even after Zig's founder did not show them the same courtesy.
  - geodel 3mo ago
    > But saying that out loud would be rude - they took steps to NOT openly criticize Zig, even after Zig's founder did not show them the same courtesy. If this does not get Anthropic 'The Presidential Medal of Strategic Restraint' I don't know what will.
- vips7L 3mo ago
  I thought maintenance was free with LLMs???
  - tayo42 3mo ago
    I don't think it's that kind of maintenance like code.you need to test cross compiling and running on different platforms. I guess js acts like how the jvm is
groundzeros2015 3mo ago
The answer is those are the tools their lead engineers knew, so they repurposed them rather than learning other paradigms .
- antonvs 3mo ago
  To the man with a hammer…
  - mexicocitinluez 3mo ago
    This saying has been abused 10 ways til Sunday. "I'm using technology I know that will get us there" is not the same as treating every problem as a nail. It's making a practical choice that probably also had time constraints and other factors we don't know.
    - groundzeros2015 3mo ago
      I think it’s completely applicable here. Nobody who worked in the 80s or 90s would have selected this solution.
      - mexicocitinluez 3mo ago
        > Nobody who worked in the 80s or 90s would have selected this solution How does this support your argument? The tech didn't even exist in the 80s or 90s. Saying "They wouldn't have made the same choices 40 years" is meaningless in this context. There's a lot of things they wouldn't have done back then that we do today. And this is a field that has been changing by the week recently, which makes even less appropriate. This idiom now apparently means "I disagree with your tech choices" or in your case, "Someone 40 years ago would disagree with your tech choices".
        groundzeros2015 3mo ago
        Let me clear up your confusion. I did not say they wouldn’t used react in the 90s (obviously). Anybody familiar with terminal uis (a technology which did exist) and perhaps any other ui system would not have chosen this design. And no it’s not just me as evidenced by the many confused comments any time this is brought up.
tokioyoyo 3mo ago
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.
jchw 3mo ago
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.
- amluto 3mo ago
  Codex appears to be a mildly complex, somewhat-but-not-outrageously-sloppy Rust program (yes, I’ve poked around at its source — thank you OpenAI for making it more or less open source). It has lots of features, mostly related all the fancy web features of Codex. Claude Code seems to be an insanely complex program will all manner of cutesy features and telemetry features. The net result is approximately the same as Codex, but it’s pretty common in software engineering to find a simple thing and a complex thing that do more or less the same thing.
deleted 3mo ago
[deleted]
deleted 3mo ago
[deleted]
bushbaba 3mo ago
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.
rafaelmn 3mo ago
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-production-scarf-has-reluctantly-moved-away-from-haskell.html https://avi.press/posts/2026-07-10-after-7-years-in-producti...
- kccqzy 3mo ago
  That blog post doesn’t make sense to me at all. The author is going from full modern Haskell (since he mentioned Servant and Beam, you could tell almost every file uses dozens of GHC extensions beyond what Haskell2010 gives you) to Python with dynamic types. He could instead rewrite the Haskell to use less modern type system features and get so much faster compilation speed. Also GHC has an interpreter. It powers the REPL. No need to compile everything if you’re just experimenting. I do find that in the Haskell world the REPL is criminally underused compared to Python. And the rest of your comment doesn’t make sense; this shop is rewriting their infra (not UI) from Haskell to Python.
- frollogaston 3mo ago
  Python was faster to iterate on than Haskell even before LLMs
vintagedave 3mo ago
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 https://news.ycombinator.com/item?id=46716974
- simonw 3mo ago
  At a guess it's because Boris literally wrote a book on TypeScript: https://www.oreilly.com/library/view/programming-typescript/9781492037644/ https://www.oreilly.com/library/view/programming-typescript/...
  - weakfish 3mo ago
    I don’t doubt his expertise, I just am not convinced it’s the right tool. To me it comes back to the premise I hear a lot from AI hype men (of which I do not subscribe but it’s worth clarifying that I find great value in using it for code) that the code doesn’t matter anymore. I just don’t know how to square that claim with the idea that we’re limited still by JS/TS being easier to use or approachable despite inferior TUI toolsets.
keeganpoppen 3mo ago
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).
miroljub 3mo ago
> 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.
api 3mo ago
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.
yoyohello13 3mo ago
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.
abc42 3mo ago
>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 https://github.com/openai/codex/discussions/1174
- frollogaston 3mo ago
  Code verbosity and complexity still matter with LLM coding
  - abc42 3mo ago
    Yeah, they do, but probably not in quite the same way as it matters to humans.
pianopatrick 3mo ago
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
- simonw 3mo ago
  I feel like a year ago JavaScript and Python were the best languages for coding agents to use because of their heavier presence in the training data, but I'm not sure that's true any more now. The latest frontier models are competent at Rust and Swift and all manner of other less widely used languages. The more important factor is how good they language's compiler is at kicking out actionable error messages, since one-shot code generation isn't as important once you have a coding agent loop.
  - pianopatrick 3mo ago
    Sometimes I think that if we are willing to burn tokens and rely on compilers in a loop we should be using languages that can catch as many errors as possible at compile time. Like Ada or Ocaml or Haskell or something. Or even require like MC / DC testing or MISRA C verification. Or even some of the languages that apply Hoare checks, like Ada SPARK or FRAMA-C or VALE or whatever. I don't have the budget to test how that would work but it seems interesting.
    - hexasquid 3mo ago
      I presume haskell applications similar to claude code are well represented in the training data.
      - pianopatrick 3mo ago
        There was a post recently from a guy who used Haskell with AI agents. If I remember correctly he said the type checking did catch errors. The problem was the compiler was very slow, which slowed down the feedback loop and output. I think he switched to Python.
frollogaston 3mo ago
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.
jmspring 3mo ago
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.
- scrollaway 3mo ago
  Caring for memory mattered more when memory was sparse. But then again, it's crazy how people are disingenuous. You're in a thread about Bun being rewritten from a non-memory-safe to a memory-safe language and everyone's shitting on it because it's a useless rewrite. How does this mesh with what you say about caring for stability? Using AI you can actually start caring about things such as memory, footprint, stability and speed because it's crazy cheap to start optimizing for this, when before you couldn't afford to make the tradeoff.
golergka 3mo ago
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
onlyrealcuzzo 3mo ago
> 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...
mischief6 3mo ago
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 https://github.com/mischief/clm
lmm 3mo ago
> 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.

deadbabe 3mo ago

Should have done it in C++ with SDL3.

ljm 3mo ago

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.

deleted 3mo ago
[deleted]
senderista 3mo ago
Why are you implicating ghostty? Have you compared its CPU usage to any other terminal?
- agrippanux 3mo ago
  I don't know if its still the case anymore since 1.3 but Ghostty did have a documented issue with Claude causing resource issues.
- tdhz77 3mo ago
  I think the author is saying everything that touches llm.
- ljm 3mo ago
  Of course I have. If I see ghostty constantly consuming the most energy and helping reduce my battery life to barely 2 or 3 hours, the first thing I'm going to do is switch terminal to see if I can improve that situation. The built in terminal and WezTerm have been fine and I've had much more reasonable battery life since. This does not even speak to it pegging my CPU and keeping the fans running on full blast even when the laptop is supposed to be idle overnight.
  - st3fan 3mo ago
    Same. I really want to file a proper bug report for this but I haven't been able to really dig into the details and the last thing I want is a "ghostty is a cpu hog" kind of report without useful info on how to debug that.
  - andruby 3mo ago
    This seems a suspicious. How do you measure the CPU load of Ghostty? Is the measure/reporting method just attributing the cpu load of the commands/programs you're running in Ghostty to Ghostty? You could test this by running "yes > /dev/null" in Ghostty. In Activity Monitor on my Macbook it shows `yes` using 100% and Ghostty using 0.5% of cpu.
  - benrutter 3mo ago
    If you're looking for a non-ghostty recommendation (not that I have anything against ghostty) I use alacritty + zellij and it works fantastic. It doesn't seem to impact battery, I certainly get good battery usage on both my work and home laptops.
    - mtlmtlmtlmtl 3mo ago
      I've messed around with pretty much all the fancy new terms to varying extents. Ghostty, wezterm, alacritty, etc. And I'm all in favour of people innovating in this space again. But at the end of the day, I always end up back with xterm. It's reasonably lightweight, runs and is packaged absolutely everywhere, I never have to muck about with termcap files and/or $TERM on remote hosts, and I've never had it break, crash, or exhibit any kind of bug or strange behaviour in over a decade of using it. The only TUI that has some quirks in xterm is Emacs, but Emacs has weird quirks in every term I've tried to run it in, and different quirks in every case somehow, so I just chalk that up to Emacs being weird. I'm sure xterm has some bugs buried in it still, but I bet all of them are in codepaths that are almost never reached nowadays, or at least are extremely niche. It does lack some features like ligature fonts(I just decided not to care), sixels and similar graphics things(again, don't really care) and panes/tabs/yadda yadda(tmux or screen or whatever you like can do all of that anyway). Never had to dig through the xterm bug tracker to figure something out. I don't even know what version I'm running, or even what the versioning scheme looks like. I haven't changed the configuration since the first time I set it up. It just works.
myaccountonhn 3mo ago
Its so wasteful, but that tracks with the modus operandi of AI companies.
vmg12 3mo ago
The fundamental problem with all Js based apps is how they are very single threaded. With js you get 1 thread at 100% utilization. Power usage and heat scale non-linearly with cpu utilization and 100% utilization on a single threaded js app means you will have ui lag. Other languages like golang would split work across 8 threads and have 8 threads at 20% utilization and this would result in less power usage. Claude Code would have been better off performance wise being an electron app because it would be offloading rendering to the browser and gpu. Also, the architecture of Open Code is actually a lot better here than Claude Code. ClaudeCode does everything, including rendering in a single thread and it's all in js. OpenCode has a zig based tui renderer it offloads that work onto. But I will also say these coding agent tuis do get unfairly maligned because they launch subprocesses and those subprocesses tend to be expensive. If you are using Rust analyzer with claude code, it's rust analyzer that's causing the majority of your problems.
- cozzyd 3mo ago
  I'm not concerned with CPU use/wakeups while actively using it, but with it sitting idle doing nothing.
- skydhash 3mo ago
  That’s not really a big issue. In major OS like the BSD, SMP implementation are not that old. If we can have a full OS running in single core mode, we can have an application being performant too. I’m currently running OpenBSD on 4 cores and it’s basically 99% idle. Bad coding is just bad coding.
  - vmg12 3mo ago
    It's basically idle because it's not doing anything. If you are streaming in markdown and code and then doing syntax highlighting on this code in real time, then rendering it on the screen you are doing actual work. It's also all cpu bound work. The majority of the stuff on your screen is being rendered by the gpu.
    - wild_egg 3mo ago
blt 3mo ago
yep, developers from 10 or even 5 years ago would have considered it a hilarious joke
LtWorf 3mo ago
> Even when the laptop is asleep overnight it's practically melting. Then something is waking it up and it's not asleep at all. Asleep the CPU shouldn't be running.

dmix 3mo ago

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

deleted 3mo ago

[deleted]

ozgrakkurt 3mo ago

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”.

johnfn 3mo ago

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?

weakfish 3mo ago
Because I’ve been told that Fable can do anything :-) My question is moreso “why was it ever JS in the first place” & the cost of a native rewrite would be cheaper than acquiring Bun no matter how you shake it
- AndrewKemendo 3mo ago
  >Because I’ve been told that Fable can do anything I hear some version of this anecdote constantly yet despite using all these prompting tools since 2019 I have never once heard a lab or professional say “x model can do anything” Can you provide me whatever specific source you heard for this?
  - weakfish 3mo ago
    It’s hyperbolic and intended to generalize the sentiment I perceive from others. Dario Amodei said in January that he expected software engineers to be replaced [0], so I suppose the quote should be extended to “can do anything… a software engineer can do” And I think we can all agree that SWE is on the more complex end of all white collar jobs. So, my thinking is that if SWE can hypothetically be replaced, so can many other jobs. Hence, the claim the models can “do anything” intending to capture the majority of white collar work. This, of course, is if you take their claim at face value - which I certainly do not. [0] https://www.entrepreneur.com/business-news/ai-ceo-says-software-engineers-could-be-replaced-in-months/502087 https://www.entrepreneur.com/business-news/ai-ceo-says-softw...
    - AndrewKemendo 3mo ago
      So then nobody actually has ever said that and its explicitly hyperbole So then its misleading in the extreme to say “I’ve been told AI can do anything” It amplifies hype when people make claims like this by including hyperbolic statements as though they are reflective of the state of the discussion.

switz 3mo ago

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.

galangalalgol 3mo ago
The criticism didn't appear to me to be that the solution didn't work, just that many of the working solutions we are selecting are dangerously overcomplicated due to shortsighted decisionmaking. The benefits of throwing redundant stacks of abstraction atop each other in terms of time to market are questionable, and obviously absent in every other metric.
- weakfish 3mo ago
  Correct And the question of “if AI is so amazing, shouldn’t it enable easy development of a native TUI even if JS is easier at first?” Don’t get me wrong I find great value in coding agents daily. Just finding the hype cycle tiring.
- bwfan123 3mo ago
  So, you have a vibe-coded TUI which happens to work, and then, as a workaround you vibe-translate its engine to make it more performant. Where does that leave you ? Basically, fully dependent on AI to fix whatever breaks. Workaround on a workaround is the way I see it, and it aligns with the AI design mentality in general. For a variety of usecases, this might still be a win in terms of overall cost. But, for software that is intended to be built to last, I dont see this approach working out.
  - jubilanti 3mo ago
    > for sw that is intended to be built to last, I dont see this working out. the era in which the tech industry built software to last was over long before LLMs, especially VC-backed startups.

deleted 3mo ago

[deleted]

voidhorse 3mo ago

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.

sroussey 3mo ago

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

qudat 3mo ago
The component trees have to be rewritten, only the non-view related JS code can be reused.

hellohello2 3mo ago

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?

delusional 3mo ago
Ncurses is how people used to do it.
qudat 3mo ago
You can do damage tracking for TUIs. Printing to the terminal is done by moving the cursor and redrawing the line the cursor is on.
tredre3 3mo ago
> I thought you need to clean and full redraw if anything changs anyways? Unless you use an ancient teletype, you don't have to redraw everything. That would make any interactive applications way too slow/flickery. You can move the cursor arbitrarily in the terminal and start overwriting characters from there. So you need to track state to know what is "dirty" and needs refreshing. Occasionally you issue a full redraw to catch missed artifacts left behind or when the terminal is resized (SIGWINCH).
- deleted 3mo ago
  [deleted]

fny 3mo ago

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.

nozzlegear 3mo ago
There's no surgery when you're a company with a trillion dollar hammer and every problem looks like a big ass nail.
amoss 3mo ago
If you are relying on live updates to change state in a dynamic language then you are not doing it "surgically", unless there is some other definition that means hitting it softly with a large rock.
pjmlp 3mo ago
There are several compiled languages with live reloading, including C++.

newswasboring 3mo ago

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

cozzyd 3mo ago

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.

onetrickwolf 3mo ago

> 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.

simonw 3mo ago
I think they bought Bun because it was a supply chain risk for them. Their new flagship product (earning them billions of dollars in revenue per month) was dependent on a platform maintained by a tiny startup. Buying Bun was a very rational way to reduce that risk, epically since it also got them some top tier engineering talent. Thinking about that further, I wonder if that was part of the rationale for switching from Zig to Rust that they haven't talked about? Zig is a much riskier bet for your multi-billion dollar cash cow than Rust is. But saying that out loud would be rude - they took steps to NOT openly criticize Zig, even after Zig's founder did not show them the same courtesy.
- geodel 3mo ago
  > But saying that out loud would be rude - they took steps to NOT openly criticize Zig, even after Zig's founder did not show them the same courtesy. If this does not get Anthropic 'The Presidential Medal of Strategic Restraint' I don't know what will.
vips7L 3mo ago
I thought maintenance was free with LLMs???
- tayo42 3mo ago
  I don't think it's that kind of maintenance like code.you need to test cross compiling and running on different platforms. I guess js acts like how the jvm is

groundzeros2015 3mo ago

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

antonvs 3mo ago
To the man with a hammer…
- mexicocitinluez 3mo ago
  This saying has been abused 10 ways til Sunday. "I'm using technology I know that will get us there" is not the same as treating every problem as a nail. It's making a practical choice that probably also had time constraints and other factors we don't know.
  - groundzeros2015 3mo ago
    I think it’s completely applicable here. Nobody who worked in the 80s or 90s would have selected this solution.
    - mexicocitinluez 3mo ago
      > Nobody who worked in the 80s or 90s would have selected this solution How does this support your argument? The tech didn't even exist in the 80s or 90s. Saying "They wouldn't have made the same choices 40 years" is meaningless in this context. There's a lot of things they wouldn't have done back then that we do today. And this is a field that has been changing by the week recently, which makes even less appropriate. This idiom now apparently means "I disagree with your tech choices" or in your case, "Someone 40 years ago would disagree with your tech choices".
      - groundzeros2015 3mo ago
        Let me clear up your confusion. I did not say they wouldn’t used react in the 90s (obviously). Anybody familiar with terminal uis (a technology which did exist) and perhaps any other ui system would not have chosen this design. And no it’s not just me as evidenced by the many confused comments any time this is brought up.

tokioyoyo 3mo ago

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.

jchw 3mo ago

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.

amluto 3mo ago
Codex appears to be a mildly complex, somewhat-but-not-outrageously-sloppy Rust program (yes, I’ve poked around at its source — thank you OpenAI for making it more or less open source). It has lots of features, mostly related all the fancy web features of Codex. Claude Code seems to be an insanely complex program will all manner of cutesy features and telemetry features. The net result is approximately the same as Codex, but it’s pretty common in software engineering to find a simple thing and a complex thing that do more or less the same thing.

deleted 3mo ago

[deleted]

deleted 3mo ago

[deleted]

bushbaba 3mo ago

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.

rafaelmn 3mo ago

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-production-scarf-has-reluctantly-moved-away-from-haskell.html https://avi.press/posts/2026-07-10-after-7-years-in-producti...

kccqzy 3mo ago
That blog post doesn’t make sense to me at all. The author is going from full modern Haskell (since he mentioned Servant and Beam, you could tell almost every file uses dozens of GHC extensions beyond what Haskell2010 gives you) to Python with dynamic types. He could instead rewrite the Haskell to use less modern type system features and get so much faster compilation speed. Also GHC has an interpreter. It powers the REPL. No need to compile everything if you’re just experimenting. I do find that in the Haskell world the REPL is criminally underused compared to Python. And the rest of your comment doesn’t make sense; this shop is rewriting their infra (not UI) from Haskell to Python.
frollogaston 3mo ago
Python was faster to iterate on than Haskell even before LLMs

vintagedave 3mo ago

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 https://news.ycombinator.com/item?id=46716974

simonw 3mo ago
At a guess it's because Boris literally wrote a book on TypeScript: https://www.oreilly.com/library/view/programming-typescript/9781492037644/ https://www.oreilly.com/library/view/programming-typescript/...
- weakfish 3mo ago
  I don’t doubt his expertise, I just am not convinced it’s the right tool. To me it comes back to the premise I hear a lot from AI hype men (of which I do not subscribe but it’s worth clarifying that I find great value in using it for code) that the code doesn’t matter anymore. I just don’t know how to square that claim with the idea that we’re limited still by JS/TS being easier to use or approachable despite inferior TUI toolsets.

keeganpoppen 3mo ago

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).

miroljub 3mo ago

> 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.

api 3mo ago

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.

yoyohello13 3mo ago

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.

abc42 3mo ago

>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 https://github.com/openai/codex/discussions/1174

frollogaston 3mo ago
Code verbosity and complexity still matter with LLM coding
- abc42 3mo ago
  Yeah, they do, but probably not in quite the same way as it matters to humans.

pianopatrick 3mo ago

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

simonw 3mo ago
I feel like a year ago JavaScript and Python were the best languages for coding agents to use because of their heavier presence in the training data, but I'm not sure that's true any more now. The latest frontier models are competent at Rust and Swift and all manner of other less widely used languages. The more important factor is how good they language's compiler is at kicking out actionable error messages, since one-shot code generation isn't as important once you have a coding agent loop.
- pianopatrick 3mo ago
  Sometimes I think that if we are willing to burn tokens and rely on compilers in a loop we should be using languages that can catch as many errors as possible at compile time. Like Ada or Ocaml or Haskell or something. Or even require like MC / DC testing or MISRA C verification. Or even some of the languages that apply Hoare checks, like Ada SPARK or FRAMA-C or VALE or whatever. I don't have the budget to test how that would work but it seems interesting.
  - hexasquid 3mo ago
    I presume haskell applications similar to claude code are well represented in the training data.
    - pianopatrick 3mo ago
      There was a post recently from a guy who used Haskell with AI agents. If I remember correctly he said the type checking did catch errors. The problem was the compiler was very slow, which slowed down the feedback loop and output. I think he switched to Python.

frollogaston 3mo ago

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.

jmspring 3mo ago

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.

scrollaway 3mo ago
Caring for memory mattered more when memory was sparse. But then again, it's crazy how people are disingenuous. You're in a thread about Bun being rewritten from a non-memory-safe to a memory-safe language and everyone's shitting on it because it's a useless rewrite. How does this mesh with what you say about caring for stability? Using AI you can actually start caring about things such as memory, footprint, stability and speed because it's crazy cheap to start optimizing for this, when before you couldn't afford to make the tradeoff.

golergka 3mo ago

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

onlyrealcuzzo 3mo ago

> 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...

mischief6 3mo ago

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 https://github.com/mischief/clm

lmm 3mo ago

> 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.