alt Hacker NewsThis might explain it, in the opposite way it was meant to:
https://fxtwitter.com/trq212/status/2014051501786931427
> Most people's mental model of Claude Code is that "it's just a TUI" but it should really be closer to "a small game engine".
Replies
As someone who maintains a roguelike with a terminal-like UI that:
1. Maintains an internal representation of what the game thinks is on screen.
2. Runs the game for one frame which updates that representation.
3. Generates a diff to see how that differs from what's actually on screen.
4. Executes the minimum set of draw calls to get the screen to match the internal representation.
It's really not that hard. It's a few hundred lines of code.
I hadn't seen that quote before, what an embarrassing thing to go on the internet and write...
Why the hell does it need to be so complex? People have been making TUIs for decades. Did we need a small game engine to run claude code?
~ "it's not a TUI! <describes an outrageously overengineered TUI> and my dad works at Nintendo"
curses, bud. curses.
It's genuinely difficult to tell how much of this is true. The post is obviously 100% posturing, but some of the words describe things that could be done.
Very few game engines do anything I'd describe as rasterisation. That's kind of the point of a GPU. Well, it used to be. I suppose "small game engines" might be more likely on average to include a rasteriser. The typical reason for this is because the author wanted to write it. Whereas big engine make triangle give hardware go brrr.
So I assume here 'rasterize' means 'printf'. And diffing screens means diffing 50..150 lines of text. And "generating ANSI sequences to draw" means 'printf' with some ANSI sequences interpolated in.
Then there's the frame budget. You have to understand they are operating within a strict frame budget -- they're not messing around, OK. They have a 16 ms frame budget, so they burned 11 ms and now have a (roughly) ~5 ms approx. budget for the final 'printf' in the chain???
I can't still conceive the fact that a tool that only send/receive text from an external API consumes an absurd amount of RAM
> For each frame our pipeline constructs a scene graph with React then -> layouts elements -> rasterizes them to a 2d screen -> diffs that against the previous screen -> finally uses the diff to generate ANSI sequences to draw
That’s rather sickening.
Maybe Claude is operating at a higher, self-improving level than all of us poor HN commenters. Wasting the local machine's resources to look pretty is a plausibly deniable way to make the Claude Code FE unusable with local LLMs, starving the competition.
this allows for comfortable ergonomics IMO
not that it could be leaner for sure but i get the reasoning behind the tui rendering layer
when they announced /pet mode or whatever - that was really the end of the line for me.
Well it runs on something they didn't design (Electron) using GUI library they didn't design (React)
For company with that much AI you'd think if it was actually good, doing that part in fast and performant way would be "easy"
And yet, nobody that writes game engines would do it this way because game engines need to be efficient..
If they used an actual game engine to render a 3D UI from scratch it would be more efficient
> For each frame our pipeline constructs a scene graph with React then
> -> layouts elements
> -> rasterizes them to a 2d screen
> -> diffs that against the previous screen
> -> finally uses the diff to generate ANSI sequences to draw
Yup. Overengineering.