Tabby: A terminal for a more modern age
github.com
github.com
I’m genuinely curious if people just don’t care. I’m very battery aware and when I’m operating on battery power I make a conscious decision to not use electron or chromium stuff, so: sublimetext, kitty, safari, and so on. My battery on M1Max lasts me ages this way
On AC power I don’t care and have a bazillion electron things running, but I still notice a pretty big difference in battery drain when unpowered
Terminal emulator is just too competitive a market to even consider one implemented in Electron, particularly on macOS where iTerm2 exists.
Any replacement terminal emulator has an uphill battle against iTerm2 and Warp. Making it Electron is needlessly hamstringing.
Warp have set a big hurdle to get over by making the top-of-funnel so harsh a winnowing function. But every time I see criticism against Warp, it's one and only one point. I'm not so willing to completely rule out & discard technology because it has one particular gotcha that yes i too snobbishly would reject.
Letting oneself be too quickly polarized is a weakness. We have to be willing to consider that we're wrong, that factors we think are important might not matter as much as they do. Or to consider that our perspective/assessment is wrong (such as assuming Electron is always a enormous resource hog).
The separators between commands enhanced readability in ways I would never have guessed possible.
The visual indicators here were incredibly clear. The terminal's ability to go beyond textual representations & to clearly delineate - with nice slick graphics that far surpass the terminal - what's happening was deeply compelling, in a way I never would have guessed before seeing it.
I've tried some pretty nice/fancy neovim setups (mostly discarded, now on AstroVim 3) and while I appreciate what they can offer, I can't emphasize enough how great Warp was at presenting information in an effective fashion. The visual experience really understood what helpful information it could present in a powerful way.
Being skeptical that "just a fancier version" has nothing to offer you seems like a callous & shallow disregard. My experience was brief, maybe 30 minutes, and I want to do better justice & I'm sorry I haven't. But you also haven't left the door open to maybe consider that the fancier version is fancy for good reasons, that it has real & competent ergonomic & informational value. Let's meet in the middle & both try to do better.
Fucking... what? AI built into a terminal emulator? Huh??
Into a shell or a text editor I could understand, but into a terminal emulator?
Like any application, enough bad code can ruin a good thing. If you install a couple dozen extensions in vscode, there's some odds one or two will have a real impact on resource usage. And I think all codebases are like this: performance is fragile. It has to be cared for, ongoingly. Projects tend to become slower over time. It doesn't matter your stack, your technology: vigilance is required. Caring is required.
When people think of Electron, they think of Slack. (Or maybe Discord, but honestly it's way down on my list of cpu used versus other things, and it's <200MB RSS across dozens of servers & hundreds of rooms is tiny.) These form very strong preconceptions. I wont tell you you're wrong, but you need to think very clearly about what could possibly change your mind. There's a lot of people not open to the possibility that they're wrong, that Electron has no problem and is fine, or even worse of a locking-yourself-in tragedy, could ever possibly become fine. And that's a problem.
(I do wish we had a shared-library alternative to Electron, which would lower effective memory use heavily. Alas, alternatives like the well known Tauri use a woefully inferior Webkit2 engine, which is a cure far worse than the disease.)
Many of us spend enormous times in our terminal. If we are going to likewise have a nearly negligible impact on battery life and memory usage, it feels like such an effete elite overconcern to fret about the technology. If Tabby can create a much more malleable flexible terminal that lets us explore possibilities quickly, at such a minimal cost, I think it would be foolish to spend time weighing & "justify" that price. We should explore what possibilities this opens.
If we kept having to add up 20 minute penalties maybe we'd get somewhere, but I doubt we'd see that kind of direct add. The simple logic is: it's unlikely that multiple apps are both being heavily used.
I just can't see it making a real difference for even 1% of people even 10% of the time. It's just not a real problem. I'd say there's too much clutching at pearls, but people have a right to be sad about bad apps, and there are bad apps built in Electron. Just like there are bad native apps that suck battery & have to be left on for work too, but people never credit in that consideration.
Calculating battery usage is pretty hard, I can only go by the observation that I have 2 vscode projects. One is a rails app and vscode doesn't do a heap of stuff for ruby code, battery drops very slowly. The other is a typescript project and when I work on that my laptop steams through the battery, and I know its vscode because I see its usage go up as I edit files. It's not insignificant.
As I said, vscode gives me a lot in return for this. It has 2 windows open. I've got 10 terminal windows open and kitty has 1 process. That is a program with actually negligible impact on battery life, lag, memory usage etc. If every program is electron then the problem compounds.
I already explained why having multiple electron apps likely doesn't compound the problem: you're only one user. It's very infrequent that you'll be heavily using multiple apps. Even if you are, the likelihood is that the resource usage is being spent on real work, doing heavy transportation or type checking or whatever it is pumping data at your console. There's a significant chance that worrying about the cpu usage of the gui is pointless & irrelevant by comparison.
I'm not sure what you're arguing at this point. I use vscode, its fine, it has a lot of gui and I'm happy with it. I don't mind its electron. It uses a lot more resources than my terminal. It has a non-negligible affect on the battery life. As do the 2 chromium based browsers I use and slack.
This is about features vs resources. Vscode, lots of gui, extensions, tons of features, I think the tradeoff is fine. Browsers, even more flexible interface, the tradeoff is OK. Slack - not ok, I do not feel it offers enough for the resources and sluggishness it uses. How many times have I had to kill a runaway slack or browser process? Too many. It's very irritating to realize your battery has been drained because of one of these things.
Now you seem to be blaming the authors of these programs because not every electron based program has this kind of issue (actually if I think back I think vscode is the only one that has never had a repeating runaway process problem that I've used on a regular basis). My argument is that it seems to happen often enough that its something inherent to electron apps. I don't want another common application in electron, one that really doesn't need the benefits that electron provides. The terminal is one. IMO text chat is another.
Edit: I had to go out before I could edit this unintelligible mess. Bottom line, I'm not anti electron. It has benefits. But there are real tangible downsides too and I've experienced those downsides. I think it's not the right tool for a terminal program or a chat program. It makes sense for a rich dynamic ui where the kind of layouts a browser engine is capable of is beyond the complexity of native widgets.
This speaks volumes
If you feel similarly, then you might enjoy https://st.suckless.org/
Konsole, alacritty, gnome-terminal all manage to struck that niche well.
Won't touch that application with a stick, especially from my laptop.
That said, there is exactly 1 feature that seems to only exist in iTerm2, and until another terminal emulator appears that has it, I'm staying put: tmux control mode.
I remember trying it out a while back and not liking something. IIRC I found the configuration pretty arcane and hard to grok but I could be wrong. Also it could have improved since. It was a while ago.
font_family SF Mono
But, depending on what you're doing with fonts, iTerm could be better suited to your tastes, sure.
The problem with Alacritty is that there is no (documented) font fallback and the author's slept on that for a few years. The (main) problem with Kitty is that font selection via font_family doesn't work. The author says it works for him, with the font I was using, so I left it at that.
If by "better suited to your tastes" you mean is able to find fonts, then, yes iTerm is better suited to my tastes. I've a few ideas as to why the author wasn't able to repro the issue but no real reason to dig any deeper because iTerm works for me.
I've rotated through Fira Code, Source Code Pro, and now I'm on IBM Plex Mono. iTerm just works for me without having to debug anything or wade through an issue tracker.
Why do you need tmux at all in that case, just fire up a bunch of terminals?
But on the other hand, many (if not most!) F/OSS projects I browse on GitHub include direct links to antecedents, competitors, and clones in their READMEs. When something is a project rather than a product, I don't think authors always worry about having the spotlight the same way. At least, many authors seem to have no problem with their work being presented in the context of a range of alternatives.
Tbh, I don't think there's a singular answer here, even to the question of what empathy recommends.
I tend to agree with the other comment - it's common for terminals to list / contrast each other rather openly. I don't know, I'm noticing people's opinion are split down the middle.
abner at terminal dot click
1) UX-focused: Most of these use electron/web technologies and pray nobody notices how much slower it is.
2) Performance-focused: minimal features, but using modern rendering APIs. AFAICT, everything in this category is just taking advantage of people not knowing Kitty already exists.
What I do think is interesting about tabby, which I haven't seen mentioned too frequently by other terminals in category #1, is the ability to embed in a webpage. I'm definitely open to more products having a nice web terminal embedded in a page.
> I run `emacs -nw` on big remote servers and performance is top notch and now I have copy paste through kitty with OSC-52 escape codes
That sounds great! I'm still getting my feet wet with kitty. I should make a list of the special functionality I want to explore, including OSC-52.
Other items seem to be solved outside of the terminal like 'bookmarks' or 'connection managers' and 'profiles'. Some emulators seem to focus more on style or discoverability, but one of the upsides of the existing learning curve is that you have to mentally organise and plan what you were going to do, instead of trying to manufacture a solution in the moment.
The performance reference is xterm. If you cannot beat that, don't bother.
You say that xxx is totally the wrong tool to use in the face of evidence that it might not be (Tabby is a tty emulator written in xxx). Why Rust and not Typescript?
I use a TTY rather a lot - konsole or Linux native and I can't really get too excited about what provides it these days. I recall discovering Gentoo back in around 2000 and the shell just looked lovely compared to all other distros. Do bear in mind that you have a shell running in your TTY. Nowadays I run Arch and its shell setup looks a lot better now than it did - strangely close to Gentoo.
#----------- I'm cough updating (repairing) my Arch laptop and sorting out a smart new Electron versioning snag (bye bye vscode for a while). Oh dear the CPU fan sounds rather Gentoo - I've been binging the AUR too much 8)
My HP PC from 2015. Can’t afford something better atm.