Claude Code is clearly a pile of vibe-coded garbage. The UI is janky and jumps all over the place, especially during longer sessions. (Which also have a several second delay to render. In a terminal).
Lately, it's been crashing if I hold the Backspace key down for too long.
Being open-source would be the best thing to happen to them. At least they would finally get a pair of human eyes looking at their codebase.
Claude is amazing, but the people at Anthropic make some insane decisions, including trying (and failing, apparently) to keep Claude Code a closed-source application.
I've actually heard a plausible theory about the TUI being janky, that being that they avoid use of the alternate screen feature of ANSI (and onwards) terminals.
The theory states that Anthropic avoids using the alternate screen (which gives consuming applications access to a clear buffer with no shell prompt that they can do what they want with and drop at their leisure) because the alternate screen has no scrollback buffer.
So for example, terminal-based editors -- neovim, emacs, nano -- all use the alternate screen because not fighting for ownership of the screen with the shell is a clear benefit over having scrollback.
The calculus is different when you have an LLM that you have a conversational history with, and while you can't bolt scrollback onto the alternate screen (easily), you can kinda bolt an alternate screen-like behaviour onto a regular terminal screen.
I don't personally use LLMs if I can avoid it, so I don't know how janky this thing is, really, but having had to recently deal with ANSI terminal alternate screen bullshit, I think this explanation's plausible.
Not disagreeing but scrolling works just fine in vim/emacs/etc. Wouldn't it be just managing the scroll back buffer yourself rather than the terminals?
Yes, but this does come with differences and tradeoffs. If the terminal isn't managing the scrollback, you don't get scrollbars and you lose any smooth/high resolution scrolling. You also lose fancy terminal features like searching the scrollback, all that needs to be implemented in your application. Depending on the environment it can also wind up being quite unpleasant to use with a trackpad, sometimes skipping around wildly for small movements.
The other part (which IMO is more consequential) is that once the LLM application quits or otherwise drops out of the alternate screen, that conversation is lost forever.
With the usual terminal mode, that history can outlive the Claude application, and considering many people keep their terminals running for days or sometimes even weeks at a time, that means having the convo in your scrollback buffer for a while.
I think they were saying that in "cup" screen mode (CUP: CUrsor Position, activated with smcup termcap), when you exit (rmcup) the text is lost, as well as the history since it was managed by the application, not the terminal.
Their hypothesis was that maybe there was aj intention to have claude code fill the terminal history. And using potentially harzardous cursor manipulation.
In other words, readline vs ncurse.
I don't see python and ipython readline struggling as bad tho...
To clarify: this is the terminal's scrollback buffer vs one managed by the application in the alternate screen.
When I scroll up in nvim, it will keep the editor frame in place (that's the top bar and bottom bar showing things like open buffers, git status, the scratch buffer or whatever it's called), but the file contents will scroll by because nvim at that point has exclusive ownership of the entire screen and can do anything with it, including repainting parts of it in response to motions or a mouse scrolling (if your terminal supports emitting mouse events).
This is in contrast to the `rmcup` "normal" terminal mode where it will scroll back in the terminal's history.
The best analogue I have for that last one is to use tmux with nvim open, and have a tmux visual selection going. You can scroll up and out of nvim, and keep scrolling to whatever was executed before neovim, and when you get out of tmux visual mode it'll snap back down to the bottom of your scrollback buffer, nvim (nominally) taking up the entire pane like nothing happened; but we can probably agree that outside of a few narrow use cases, this isn't a very desirable way to manage scrolling in a terminal.
I don't think that's likely to explain jankiness. I do know my way around terminal screens and escape codes, and doing flicker-free, curses-like screen updates works equally well on the regular screen as on the alternate screen, on every terminal I've used.
It's also not a hard problem, and updates are not slow to compute. Text editors have been calculating efficient, incremental terminal updates since 1981 (Gosling Emacs), and they had to optimise better for much slower-drawing terminals, with vastly slower computers for the calculation.
Yesterday, I resumed a former claude code session in order to copy code it had generated earlier in that session. Unfortunately, when resuming, it only prints the last N hundred lines of the session to the terminal, so what I was looking for was cut off.
I think that for this sort of _interactive_ application, there's no avoiding the need to manage scroll/history.
That conversation should still exist in the Claude Code log files. Just give Claude some context on how to find it, and it will pull whatever you need. I use this to recall particularly effective prompts later on for reuse.
> Claude Code is clearly a pile of vibe-coded garbage. The UI is janky and jumps all over the place, especially during longer sessions. (Which also have a several second delay to render. In a terminal).
Don't you know, they're proud of their text interface that is structured more like a video game. https://spader.zone/engine/
Not to stand up for Claude Code in any way, I don’t like the company or use the product. This is just a related tangent-
one of my favorite software projects, Arcan, is built on the idea that there’s a lot of similarities between Game Engines, Desktop Environments, Web Browsers, and Multimedia Players. https://speakerdeck.com/letoram/arcan?slide=2
They have a really cool TUI setup that is kinda in a real sense made with a small game engine :)
I mean if you want glitchy garbage that works in the happy path mostly then game engine is the right foundation to build on. Software quality is the last thing game devs are known for. The whole industry is about building clever hacks to get something to look/feel a certain way, not building robust software that's correct to some spec.
To offer the opposite anecdotal evidence point -- claude scrolls to the top of the chat history almost capriciously often (more often than not) for me using iterm on tahoe
To be fair, iTerm is likely to be the single most common terminal emulator used by Claude Code developers, so I'd hope that it would work tolerable well there.
i will note that they really should of used something like ncurses and kept the animations down, TTYs are NOT meant to do the level of crazy modern TUIs are trying to pull off, there is just too many terminal emulators out there that just don't like the weird control codes being sent around.
Not really. This guy expresses my feelings: https://www.youtube.com/watch?v=nxB4M3GlcWQ
I also prefer codex over claude. But opencode is best. If you can use a good model. We can via Github Business Subscription.
I don’t think that’s the reason, but using Bun for production this early is a bad idea. It’s still too buggy, and compromising stability for a 2–3% performance gain just isn’t worth it.
this is highly workload-dependent. there are plenty of APIs that are multiple-factor faster and 10x more memory efficient due to native implementation.
Almost all my computer science students are using Typst on my recommendation to write up their programming projects, vs most using Microsoft Word last year. Specifically, writing in VSCode with the Tinymist Typist extension. All going very well so far and no complaints.
I was with you when you explained how you got them off of MS Word (even worse if it was the web version!!), until you brought up VSCode. I get it, you are probably advocating very practical choices. Just that I wouldn't recommend students to become dependent on VSCode (due to its vendor and "telemetry"). Basically, that makes the students again dependent on MS. But I guess since you recommend an extension, you cannot recommend VSCodium and adding the extension store as someone in a teaching position? If you can, then I would strongly advocate recommending VSCodium instead (or non-electron app editors), to avoid spyware on their machines and to promote a healthier tooling.
I have not tried this one, but the predecessor (typst-lsp) was working fine with Neovim for me when I did my little Typst experiment last year. Whatever the VSCode plugin is offering should be possible to replicate on top of tinymist.
I'm writing this on a Unihertz Jelly Star which is tiny, and I consider it my "protest phone" at the lack of decent small phones.
A friend jokingly calls it my "microphone", another a "prison phone" (due to its size allowing for more easily smuggling in body cavities). Occasionally I go to mobile phone shops and ask if they have a case for it just for the fun of seeing the look on their faces when they see it (I don't actually want a case, and in fact it came with one which I threw in the bin).
Personally, I couldn't be happier with it.
Only problems: they don't do software updates; camera is poor; non-OLED screen.
In an ideal world I'd have a slightly bigger phone, but not too much bigger. I've grown very fond of this phone.
The lack of updates/general software sketchiness is what has me turned off from the Jelly. I know a product like that never has a chance in hell of running Graphene, I’d be way more interested if it could run Lineage.
Is OLED burn-in really something people still care about? I have a handful of OLED devices, some of which I've used daily for nearly 10 years, and none of them have any burn-in. I've never even seen burn-in on anything other than a signage TV, and that happens even on some LCDs.
> I've never even seen burn-in on anything other than a signage TV, and that happens even on some LCDs
AFAIK, the hardware still suffers from that problem, but it's been fixed in most devices by software fixes. Instead of displaying the exactly same content 24/7, it has "cleaning programs" or similar to runs once in a while to prevent the burn in from happening. Our OLED TV does the same I think too.
Of course, and many devices also use various pixel shift techniques. My point is that this isn't really a drawback from the user's perspective. Saying "I consider non-OLED to be a selling point because it won't burn in" simply doesn't make sense anymore.
I know someone who spends so much time with YouTube on their phone that the logo is visibly burned in to the screen. The phone is less than 2 years old.
Samsung smartphones are everywhere here and I've never seen a burn-in screen. Is there a difference between OLED and AMOLED? I thought that AMOLED was just a "flavor" of OLED.
The Jelly Star's battery life is surprisingly decent for its size - I get about 8 hours of moderate use, but it requires a mid-day charge if you're using GPS or watching videos.
The Jelly Max is 5" (so bigger than previous Jellies, smaller than mainstream phones). I'd strongly consider one except for their lack of software updates.
Yeah not ideal… then again… samsung actually pushed an update with an overlay that shows ads on some old models. I had one I used to show the forecast, attached to a wall. I had to reset and to factory and forbid all updates or ads would appear on top of my app.
I loved tixy when I first discovered it a few years ago so created this https://www.mathsuniverse.com/tixy (with permission from the original author) with puzzles to solve on the tixy grid. I use it with my computer science students who get really into it.
I was blown away by the little functions at first and I too made a clone to experiment with calculang [1].
I added an evaluation feature (F9) so you can select sub-expressions and see what they do, which was helpful to figure out some patterns (video in [2])
What's wrong with that statement? It has historically and traditionally been true for raster displays, even if there do exist ways to use standard Cartesian-style coordinates with a computer.
There top left has usually been (0, 0) for hardware pixel coordinates (although even then there’s plenty of exceptions, e.g. mode 13h scrolling) but as a blanket statement about computer graphics in general it’s misleading.
I'm struggling to see the problem with this statement, other than maybe to add in the word "usually". My students will know of graphs in maths where the origin is always bottom left. When working with HTML canvas and every other computer graphics situation I've worked in, it's top left instead.
"PostScript uses a coordinate system where the origin is at the bottom-left corner of the page, with the x-axis increasing to the right and the y-axis increasing upwards."
Oscilloscopes use middle-left.
Unreal engine and SketchUp use Screen middle with xy increasing to the right.
in AutoCAD, the user coordinate system is 1/3 of the screen to the left for the origin, with X increasing to the right, and Y increasing upwards.
Almost all raster displays, and memory based programs assume top left, because that is how it was done first - counter intuitive.
It it not counter intuitive and the decision extends far earlier than the first displays.
A raster image onscreen is displayed in the order that the data appears when written down. It stands to reason that a data depiction should be in the same orientation as the display orientation. Displays were created by people who read from left to right, top to bottom. If the displays did not follow that order. images would be flipped or rotated when displayed in a data form.
The first pixel written to the display is in the top left because we read from the top left. If writers of another language had have popularised the text, perhaps things might have been different.
A guerilla marketing plan for a new language is to call it a common one word syllable, so that it appears much more prominent than it really is on badly-done popularity contests.
Call it "Go", for example.
(Necessary disclaimer for the irony-impaired: this is a joke and an attempt at being witty.)
Amusingly, the chart shows Rust's popularity starting from before its release. The rust hype crowd is so exuberant, they began before the language even existed!
I'm not so sure, while Java's never looked better to me, it does "feel" to me to be in significant decline in terms of what people are asking for on LinkedIn.
I'd imagine these days typescript or node might be taking over some of what would have hit on javascript.
Recruiting Java developers is easy mode, there are rather large consultancies and similar suppliers that will sell or rent them to you in bulk so you don't need to nag with adverts to the same extent as with pythonistas and rubyists and TypeScript.
But there is likely some decline for Java. I'd bet Elixir and Erlang have been nibbling away on the JVM space for quite some time, they make it pretty comfortable to build the kind of systems you'd otherwise use a JVM-JMS-Wildfly/JBoss rig for. Oracle doesn't help, they take zero issue with being widely perceived as nasty and it takes a bit of courage and knowledge to manage to avoid getting a call from them at your inconvenience.
Speaking as someone who ended up in the corporate Java world somewhat accidentally (wasn't deep in the ecosystem before): even the most invested Java shops seem wary of Oracle's influence now. Questioning Oracle tech, if not outright planning an exit strategy, feels like the default stance.
Most such places probably have some trauma related to Oracle now. Someone spun up the wrong JVM by accident and within hours salespeople were on the phone with some middle manager about how they would like to pay for it, that kind of thing. Or just the issue of injecting their surveillance trojans everywhere and knowing they're there, that's pretty off-putting in itself.
Which is a pity, once you learn to submit to and tolerate Maven it's generally a very productive and for the most part convenient language and 'ecosystem'. It's like Debian, even if you fuck up badly there is likely a documented way to fix it. And there are good libraries for pretty much anything one could want to do.
a) Does your query for 'JS' return instances of 'JSON'?
b) The ultimate hard search topic for is 'R' /
'R language'. Check if you think you index it corectly. Or related terms like RStudio, Posit, [R]Shiny, tidyverse, data.table, Hadleyverse...
Claude code uses (and Anthropic owns) Bun, so my guess is they're doing a production build, expecting it not to output source maps, but it is.
reply