I see some electron stuff in there, looks to be another electron one?
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
The number of us that run vscode is very high. Vscode is exceedingly performant & efficient. I doubt I lose 20 minutes of my 8+ hour runtime on those days I switch from Neovim to Vscode fulltime. It's just not a factor, and hemming & hawing is a waste of emotion. Being a fidgety worry-wort here is a waste of my vital life energy, would make my life worse.
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.)
Vscode does a ton of stuff though and it can perhaps justify it's electron with a broad set of features, the performance work they've put in to it and that being based on electron really helped their extension ecosystem. I don't quite see the same justifications for a terminal.
If vscode can do so much and have such a slim profile, it's hard for me to grapple with the idea that we need to justify using the same technologies for a terminal. The impact is negligible, for a massive incredibly capable & superbly complex app.
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.
Vscode doesn't have a negligible impact on battery life though. Depending on the project I'm working on it can be the most battery draining program. That's the cost of the features. Can a terminal justify those kind of features for the same exchange? I've tried various and settled on kitty.
What's your impact? For me, vscode under 5% difference in battery life (as per the math on my original post, 20 minutes across an 8 hour work day). With an 8 hour battery, that just doesn't matter to me.
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.
If I look at the top 10 CPU used time items for me, with an uptime of 14 days, it's 6 vscode processes and 4 macos processes (I count 15 other vscode processes in the whole list which seems insane!)
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.
Top 10 on my MacBook is usually still gaspingly tiny utilization; it means almost nothing. I feel like we are back where I started: I doubt your vscode would be significantly different than my neovim. That's been my experience. I definitely lose some power keeping tsc watch running and having LSP update itself. And having projects reload. But these aren't fault of vscode - these all run when I'm using neovim too. Amid these processes vscode seems unimportant. If it is a drain, evaluate your plugins & find who is the problem.
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.
It is vscode's built in typescript lsp as far as I can tell.
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.
iTerm2 I agree with, but Warp? Does it have any real adoption? The company has taken ~$70 million in venture capital funding and the product requires an account/sign-in. Even if the product itself has good features I would not touch it.
I watched a coworker screen share using Warp & was heavily impressed.
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).
See that's one of the things that _didn't_ impress me. It's basically just a fancier way of doing what's already available in stock Fish installs and slightly tuned zsh ones.
Well I apologize I guess for not making my case clearer. It's not easy to describe in words.
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.
I've also been rejecting it out of hand, but downloading it now having read your comment. It would need to go a long way to supplant my iTerm2 / Fish set-up, but I'm intrigued.
I have a powerful desktop with good cooling. I still care. I sometimes get really annoyed when I see a non-productivity or non-game software using more than 500MB of RAM. It just doesn't have to, but it does it anyway.
I'm not sensitive to minor performance issues, but I am very sensitive to apps that don't behave like a native macOS app. I want all my preference windows to look the same, I want to use native spellchecking everywhere, I want to use the Applescript/Automator/Shortcuts that I've been adding to the services menu over the years.
I believe the suckless project is going way into the other direction. There is a reasonable middle ground of having proper, 21st century features, yet not using much more resources than needed.
Konsole, alacritty, gnome-terminal all manage to struck that niche well.
iTerm2 and Kitty both cover the specific kind of terminal Tabby seems to be going after in particular: 'batteries included', modernized, extended with new features, tight integration with the shell, special SSH and tmux integrations, etc. If you're into bells and whistles and moving beyond xterm's capabilities, there are multiple strong contenders for Mac, and both eschew web tech in favor of native code.
What made you go for Wezterm over kitty? That one's on my list of terminals to give a try in place of iTerm2 this year but I don't know much about it. (I just use DE defaults on Linux, but I'm back on macOS again at work and Wezterm is a lot more mature now than it was last time I was here.)
iTerm2 is a great terminal for macOS. I use it extensively every day. Despite that, I would gladly try out other terminals because it's fun and because I'm always open to finding something superior to even the great tools I use.
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 recently tried both Alacritty and Kitty out of curiosity and went back to iTerm ASAP. For me, on OSX, iTerm is the only one that gets the font handling right.
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.
I’ve been using kitty for a few months now as my primary editor and have tried out about a dozen coding fonts because I think they’re neat, I’ve never had an issue getting kitty to find and load them.
ditto for me, the font rendering for kitty and alacritty (I tried various fonts + knobs macos_thicken_font, text_composition_stratgegy ...) and they just don't appear as crisp as fonts in iterm2 on macos
I wrote a terminal-agnostic approximation of that called tmuxc - https://github.com/zdykstra/tmuxc . It's very much tailored my exact workflow, mainly because nobody else seems interested in it. With a bit of hacking around you could probably make it work on macOS. I use it on both Linux and HaikuOS.
I must be missing something fundamental. tmux is a terminal multiplexer, as in you get to run multiple virtual terminals over a single actual terminal (eg ssh). And then tmuxc breaks these virtual terminals out into actual terminals?
Why do you need tmux at all in that case, just fire up a bunch of terminals?
tmux, for me, is about session persistence. I run multiple tmux sessions on a bastion host at work. tmuxc lets me reconnect to them each morning and then move them around my monitors as I see fit. I can hit a single key combination and have a new terminal open up with a shell on my bastion host - or any other host that I have a tmux/tmuxc session on.
I don’t use that feature often but it sure is nice. It will take a lot to move me away from iTerm 2. I’m incredibly happy with it and it’s rock solid (and fast).
If you're not married to it being in tmux, you can use wezterm's SSH integration will open new tabs and panes in your current SSH session, which is most of what I use iTerm's tmux mode for.
I use it for that + session persistence. The latter is as important as the former to me. I imagine wezterm's doesn't do that, is that right?
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.
Interesting, this is coming on the heels of my own terminal [0] finally being announced to the public. I hope the plug is fair game - friendly competition in this space has been sorely missing!
I'm much more interested in your product, and wouldn't have known about it otherwise. Is there a way to be notified when you actually allow public access? Happy to pay for the final product.
If I were debuting a product, I think I'd feel a bit hurt and/or frustrated to see a competitor getting a big spotlight on the post.
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.
It was a mistake for me as the author to do the direct comparison here.
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.
I feel like there's only 2 kinds of new terminals:
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.
It's not minimalist to that like urxvt and st, but it does cater to a different crowd. Loving kitty by the way, 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 instead of an abomination of an pbcopy/ssh script, it actually almost feels like a real editor now.
I guess I know what you mean, since kitty is decidedly more my bag than iTerm2 is. But while they have very different UI design philosophies, I think Kitty and iTerm2 have a lot in common in terms of that basic drive to make terminal emulators do things they never could before (even if that requires new extensions and/or clever tricks).
> 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.
I gave a talk at the SeaGL conference called "Features of a Modern Terminal Emulator"[0] which goes into pretty good detail about cool things that "modern" terminal emulators do, including OSC-52, xterm mouse support, font rendering, image support and more.
I have an odd sense of deja vu, I'm certain it's not the first time I've seen an Electron based terminal with the same exact "for a modern age" descriptor.
I'm also not sure what's "wrong" with existing terminal emulators, except render acceleration when you do a lot of text I/O, but I think urxvt already had that solved.
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.
It's a teletype terminal emulator, probably with pretty things and stuff. Who cares what language it is written in? Will writing it in Rust ensure that PF1-4 emulation will work properly?
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)
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