5 ms·
Also explains why Claude Code is a React app outputting to a Terminal. (Seriously.)
by gjsman-1000 9mo ago
Also explains why Claude Code is a React app outputting to a Terminal. (Seriously.)
- thehamkercat 9mo agoSame with opencode and gemini, it's disgusting Codex (by openai ironically) seems to be the fastest/most-responsive, opens instantly and is written in rust but doesn't contain that many features Claude opens in around 3-4 seconds Opencode opens in 2 seconds Gemini-cli is an abomination which opens in around 16 second for me right now, and in 8 seconds on a fresh install Codex takes 50ms for reference... -- If their models are so good, why are they not rewriting their own react in cli bs to c++ or rust for 100x performance improvement (not kidding, it really is that much)
- azinman2 9mo agoWhy does it matter if Claude Code opens in 3-4 seconds if everything you do with it can take many seconds to minutes? Seems irrelevant to me.
- wahnfrieden 9mo agoBecause when the agent is taking many seconds to minutes, I am starting new agents instead of waiting or switching to non-agent tasks
- RohMin 9mo agoI guess with ~50 years of CPU advancements, 3-4 seconds for a TUI to open makes it seem like we lost the plot somewhere along the way.
- strange_quark 9mo agoDon’t forget they’ve also publicly stated (bragged?) about the monumental accomplishment of getting some text in a terminal to render at 60fps.
- jama211 9mo agoSo it doesn’t matter at all except to your sensibilities. Sounds to me that they simply are much better at prioritisation than your average HN user, who’d have taken forever to release it but at least the terminal interface would be snappy…
- mbesto 9mo agoThis is exactly the type of thing that AI code writers don't do well - understand the prioritization of feature development. Some developers say 3-4 seconds are important to them, others don't. Who decides what the truth is? A human? ClawdBot?
- jama211 9mo agoThe humans in the company (correctly) realised that a few seconds to open basically the most powerful productivity agent ever made so they can focus on fast iteration of features is a totally acceptable trade off priority wise. Who would think differently???
- sumedh 9mo ago> Some developers say 3-4 seconds are important to them, others don't. Wasnt GTA 5 famous for very long start up time and turns out there some bug which some random developer/gamer found out and gave them a fix? Most Gamers didnt care, they still played it.
- barnabee 9mo agoSome people[0] like their tools to be well engineered. This is not unique to software. [0] Perhaps everyone who actually takes pride in their craft and doesn’t prioritise shitty hustle culture and making money over everything else.
- azinman2 9mo agoAside from startup time, as a tool Claude Code is tremendous. By far the most useful tool I’ve encountered yet. This seems to be very nit picky compared to the total value provided. I think y'all are missing the forrest for the trees.
- nsingh2 9mo agoMost of the value of Claude Code comes from the model, and that's not running on your device. The Claude Code TUI itself is a front end, and should not be taking 3-4 seconds to load. That kind of loading time is around what VSCode takes on my machine, and VSCode is a full blown editor.
- barnabee 9mo agoIt’s orders of magnitude slower than Helix, which is also a full blown editor. When all your other tools are fast and well engineered, slow and bloated is very noticeable.
- barnabee 9mo agoIt’s almost all the model. There are many such tools and Claude Code doesn’t seem to be in any way unique. I prefer OpenCode, so far.
- wahnfrieden 9mo agoCodex team made the right call to rewrite its TypeScript to Rust early on
- g947o 9mo agoGreat question, and my guess: If you build React in C++ and Rust, even if the framework is there, you'll likely need to write your components in C++/Rust. That is a difficult problem. There are actually libraries out there that allow you to build web UI with Rust, although they are for web (+ HTML/CSS) and not specifically CLI stuff. So someone needs to create such a library that is properly maintained and such. And you'll likely develop slower in Rust compared to JS. These companies don't see a point in doing that. So they just use whatever already exists.
- shoeb00m 9mo agoOpencode wrote their own tui library in zig, and then build a solidjs library on top of that. https://github.com/anomalyco/opentui https://github.com/anomalyco/opentui
- Philpax 9mo agoThose Rust libraries have existed for some time: - https://github.com/ratatui/ratatui https://github.com/ratatui/ratatui - https://github.com/ccbrown/iocraft https://github.com/ccbrown/iocraft - https://crates.io/crates/dioxus-tui https://crates.io/crates/dioxus-tui
- g947o 9mo agoWhere is React? These are TUI libraries, which are not the same thing
- shoeb00m 9mo agocodex cli is missing a bunch of ux features like resizing on terminal size change. Opencode's core is actually written in zig, only ui orchestration is in solidjs. It's only slightly slower to load than neo-vim on my system. https://github.com/anomalyco/opentui https://github.com/anomalyco/opentui
- bdangubic 9mo ago50ms to open and then 2hrs to solve a simple problem vs 4s to open and then 5m to solve a problem, eh?
- jama211 9mo agolol right? I feel like I’m taking crazy pills here. Why do people here want to prioritise the most pointless things? Oh right it’s because they’re bitter and their reaction is mostly emotional…
- thehamkercat 8mo agoThe "50ms" number was measured by me and you can literally try it on your system as well. it will likely be faster than 50ms Do you have a proof that gpt-5.2 or 5.3 codex takes 2 hours for the same problem that sonnet/opus4.5/4.6 take 5 minutes to solve? (I use both anthropic and openai models daily almost equally, and i'm not relating to what you said) Sure codex-cli lacks way-too many features compared to claude-code (I use opencode), but your statement implies that openai models are absolute garbage (2h vs 5m to solve a problem)
- CooCooCaCha 9mo agoIt’s really not that crazy. React itself is a frontend-agnostic library. People primarily use it for writing websites but web support is actually a layer on top of base react and can be swapped out for whatever. So they’re really just using react as a way to organize their terminal UI into components. For the same reason it’s handy to organize web ui into components.
- dreamteam1 9mo agoAnd some companies use it to write start menus.
- tayo42 9mo agoIs this a react feature or did they build something to translate react to text for display in the terminal?
- pkkim 9mo agoThey used Ink: https://github.com/vadimdemedes/ink https://github.com/vadimdemedes/ink I've used it myself. It has some rough edges in terms of rendering performance but it's nice overall.
- tayo42 9mo agoThats pretty interesting looking, thanks!
- embedding-shape 9mo agoNot a built-in React feature. The idea been around for quite some time, I came across it initially with https://github.com/vadimdemedes/ink https://github.com/vadimdemedes/ink back in 2022 sometime.
- sbarre 9mo agoReact, the framework, is separate from react-dom, the browser rendering library. Most people think of those two as one thing because they're the most popular combo. But there are many different rendering libraries you can use with React, including Ink, which is designed for building CLI TUIs..
- skydhash 9mo agoAnyone that knows a bit about terminals would already know that using React is not a good solution for TUI. Terminal rendering is done as a stream of characters which includes both the text and how it displays, which can also alter previously rendered texts. Diffing that is nonsense.
- 9dev 9mo agoYou’re not diffing that, though. The app keeps a virtual representation of the UI state in a tree structure that it diffs on, then serializes that into a formatted string to draw to the out put stream. It’s not about limiting the amount of characters redrawn (that would indeed be nonsense), but handling separate output regions effectively.
- jama211 9mo agoThere’s nothing wrong with that, except it lets ai skeptics feel superior
- exe34 9mo agoI use AI and I can call AI slop shit if it smells like shit.
- RohMin 9mo agohttps://www.youtube.com/watch?v=LvW1HTSLPEk https://www.youtube.com/watch?v=LvW1HTSLPEk I thought this was a solid take
- jdthedisciple 9mo agointeresting
- 3836293648 9mo agoOh come on. It's massively wrong. It is always wrong. It's not always wrong enough to be important, but it doesn't stop being wrong
- deleted 9mo ago[deleted]
- sweetheart 9mo agoReact's core is agnostic when it comes to the actual rendering interface. It's just all the fancy algos for diffing and updating the underlying tree. Using it for rendering a TUI is a very reasonable application of the technology.
- skydhash 9mo agoThe terminal UI is not a tree structure that you can diff. It’s a 2D cells of characters, where every manipulation is a stream of texts. Refreshing or diffing that makes no sense.
- bizzleDawg 9mo agoOnly in the same way that the pixels displayed in a browser are not a tree structure that you can diff - the diffing happens at a higher level of abstraction than what's rendered. Diffing and only updating the parts of the TUI which have changed does make sense if you consider the alternative is to rewrite the entire screen every "frame". There are other ways to abstract this, e.g. a library like tqmd for python may well have a significantly more simple abstraction than a tree for storing what it's going to update next for the progress bar widget than claude, but it also provides a much more simple interface. To me it seems more fair game to attack it for being written in JS than for using a particular "rendering" technique to minimise updates sent to the terminal.
- skydhash 9mo agoMost UI library store states in tree of components. And if you’re creating a custom widget, they will give you a 2D context for the drawing operations. Using react makes sense in those cases because what you’re diffing is state, then the UI library will render as usual, which will usually be done via compositing. The terminal does not have a render phase (or an update state phase). You either refresh the whole screen (flickering) or control where to update manually (custom engine, may flicker locally). But any updates are sequential (moving the cursor and then sending what to be displayed), not at once like 2D pixel rendering does. So most TUI only updates when there’s an event to do so or at a frequency much lower than 60fps. This is why top and htop have a setting for that. And why other TUI software propose a keybind to refresh and reset their rendering engines.
- krona 9mo agoSounds like a web developer defined the solution a year before they knew what the problem was.
- jama211 9mo agoNah. It’s just web development languages are a better fit for agentic coding presently. They weighed the pros and cons, they’re not stupid.
- shimman 9mo agoOf course they can be stupid, hubris is a real thing and humans fail all the time.
- jama211 9mo agoBut not in our criticism of them, no it cannot be us who are the stupid ones
- barnabee 9mo agoI’ve had good success with Claude building snappy TUIs in Rust with Ratatui. It’s not obvious to me that there’d be any benefit of using TypeScript and React instead, especially none that makes up for the huge downsides compared to Rust in a terminal environment. Seems to me the problem is more likely the skills of the engineers, not Claude’s capabilities.
- CamperBob2 9mo agoAlso explains why Claude Code is a React app outputting to a Terminal. (Seriously.) Who cares, and why? All of the major providers' CLI harnesses use Ink: https://github.com/vadimdemedes/ink https://github.com/vadimdemedes/ink
- krystofbe 9mo agoI did some debugging on this today. The results are... sobering. Memory comparison of AI coding CLIs (single session, idle): | Tool | Footprint | Peak | Language | |-------------|-----------|--------|---------------| | Codex | 15 MB | 15 MB | Rust | | OpenCode | 130 MB | 130 MB | Go | | Claude Code | 360 MB | 746 MB | Node.js/React | That's a 24x to 50x difference for tools that do the same thing: send text to an API. vmmap shows Claude Code reserves 32.8 GB virtual memory just for the V8 heap, has 45% malloc fragmentation, and a peak footprint of 746 MB that never gets released, classic leak pattern. On my 16 GB Mac, a "normal" workload (2 Claude sessions + browser + terminal) pushes me into 9.5 GB swap within hours. My laptop genuinely runs slower with Claude Code than when I'm running local LLMs. I get that shipping fast matters, but building a CLI with React and a full Node.js runtime is an architectural choice with consequences. Codex proves this can be done in 15 MB. Every Claude Code session costs me 360+ MB, and with MCP servers spawning per session, it multiplies fast.
- Weryj 9mo agoI believe they use https://bun.com/ https://bun.com/ Not Node.js
- atonse 9mo agoJarred Sumner (bun creator, bun was recently acquired by Anthropic) has been working exclusively on bringing down memory leaks and improving performance in CC the last couple weeks. He's been tweeting his progress. This is just regular tech debt that happens from building something to $1bn in revenue as fast as you possibly can, optimize later. They're optimizing now. I'm sure they'll have it under control in no time. CC is an incredible product (so is codex but I use CC more). Yes, lately it's gotten bloated, but the value it provides makes it bearable until they fix it in short time.
- bdangubic 9mo agoif I had a dollar for each time I heard “until they fix it in short time” I’d have Elon money
- 9mo ago
- flashgordon 8mo agoI am really flabbergasted. How are they thinking using React for a TUI is a flex? Having 5 sessions open - and all idea - is taking up 98% of CPU. Is this another case of - "When all you is hammer, everything looks like nails"?