3 ms·

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 bein

by jemmyw 3y ago

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.

jauntywundrkind 3y ago
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.
- jemmyw 3y ago
  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.
  - jauntywundrkind 3y ago
    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.
    - jemmyw 3y ago
      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.
      - jauntywundrkind 3y ago
        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.
        jemmyw 3y ago
        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.

by jemmyw 3y ago

jauntywundrkind 3y ago

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.

jemmyw 3y ago
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.
- jauntywundrkind 3y ago
  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.
  - jemmyw 3y ago
    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.
    - jauntywundrkind 3y ago
      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.
      - jemmyw 3y ago
        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.