Vibe coding is soooo awesome!
And people thought that Electron was a resource pig. You ain't seen nothing yet.
A 386 could run NetHack at blazing fast speeds and read the news in a TTY perfectly well.
A multicore machine can't get the basic thanks to the 'wonderful' JS. Heck, even s9 Scheme from http://t3x.org ships a Curses module, enough to drive some text and maybe boxes/menues and it should fit in two floppies. A single one if the image it's generated later on-disk.
What kind of Karen are you that you expect me to check if it works for other people? I mean you have Claude, too, so fix it yourself. I've got more code to vibe and vibe to code. Later for you.
Note: this is dark sarcasm just in case somebody thinks I'm serious. The problem is that I'm not really laughing because I have heard very similar to this and had to be the one harshing both their vibes very much.
Software bloat fills a void created by itself.
And people would be angry if you even note what you don't need it.
I propose we should have some global switch to on/off these type of things, something like kern.fidget.widget=off or $VANILLA_PUMPKIN_LATTE=BROYEETSURE
Kitty is a magnificent piece of software that has radically enhanced the interface between me and my computer. And it does this while consuming negligible resources.
I also use its shell integration features, such as putting the scrollback into a pager, constantly.
Can't wait for this style of prose to become an incredibly embarrassing faux-pas.
Something that has cropped up from time to time in the art world since at least the Dadaists was the idea that rather than distribute the artefact, you distribute the instructions to construct the artefact.
So, my terminal, while it could perhaps improve in its battery usage, does not behave like this.
I won't use neither Claude, nor a MacBook; I would just keep chilling out programming with decent tools and a bare XTerm to accomplish the rest. I can get Aragonese bricks ^U sweets in the meanwhile.
On Terminal.app, I wonder if the GNUStep eversion and the ones bundled with Mac OSX shared some code.
If you're not benefitting from the ability to offload your terminal rendering to GPU, why are you using a terminal that offloads terminal rendering to GPU in the first place?
Imagine running something massively CPU bound, but you've still got to spin up perhaps tens of terminals in order to simultaneously ssh in to multiple servers because you don't want to set up a remote monitoring solution because you don't want each of the servers to be running a docker image where SSH>htop would suffice.
There are plenty of situations in which one might want a terminal emulator offloaded to gpu. That you are not in any of those situations is no reason to write a hit piece throwing shade as if the packages mentioned are somehow bloated or inefficient.
Imagine whining about how you've got to pay adobe and use several gigabytes of ram to resize jpgs. You'd obviously be outside Photoshop's ideal customer profile, just as you are outside ghostty et al's.
Let me do that now: hmm, this article seems to be a complaint about applications that waste energy.
There are lots of distributions that ship emulators that don't have modern features, and even among those that do, I still don't want to learn the individual quirks every time I hit a shell.
Gnome terminal, yakuake, ptyxis, cosmic, konsole, xfce4-terminal, qterminal, etc all have slight variations between simple things like rendering and more important things like hotkeys. It's nice to have an alternative that I can install on any system such that I can get comfortable with just the one. If I can't install anything I'm often stuck poking around to find whatever the devs version of correct is, or else asking the owner of the machine "okay, how the hell do I do {x}?" if they're comfy with their cli, but chances are if I'm sitting there it's because they're not comfy with their cli.
I could cover a lot of it with a bashrc file, but I wouldn't want anyone fucking with mine, so I'm not touching anyone elses.
edit: distrObutions->distrIbutions
Those would be handled by your shell, not your terminal, right?
> multiplexing
If you have a good window manager, then there is no reason to have a bespoke multiplexing implementation in your terminal. I can stack my terminals and _any other window I want_ with tabs and switch between them using the same hotkeys/interface that I use for my whole system, rather than each app implementing their own tabs.
All the bells and whistles people have shown me over the years... it never even gets close to making me think "oh yea, that's better than basic tab/window management and the terminal app that comes with my OS".
[0] https://github.com/peters/horizon [1] https://github.com/Xpra-org/xpra/
<nerd snipe>
Game changer
if you are thinking of tmux then the problem here is that tmux is in itself a terminal.
to get session management away from the terminal it would need to be done in such a way that when the session tool connects the session it merely acts as a proxy or less, but does not interpret and then translate the signals that come from the session like tmux does.
this is not trivial, at least with the current way terminals work.
we need to entirely rethink the terminal protocol: https://news.ycombinator.com/item?id=47941354
I’m currently trialing https://tangrid.app/ and it’s got some nice features.