4 ms·

It's Electron/TS based. I seriously doubt I can get used to using an Electron based beast for something as critical as a terminal. This is the one power user a

by sgt 3y ago

It's Electron/TS based. I seriously doubt I can get used to using an Electron based beast for something as critical as a terminal. This is the one power user app where speed is factually of utmost urgency, and latency is non negotiable. I also don't like it using tons of memory. While this may be possible with Electron from what I have heard, I have yet to have seen it. So generally I stay away.

wg0 3y ago
Actually - VSCode comes with a built-in Terminal that's also built using Electron and TS. Never had any issues with it while using it as built-in Terminal from time to time.
- franga2000 3y ago
  The VSCode terminal is the first time I've felt input lag in a terminal emulator before. When a program shits out thousands of lines of text (like catting a long log file), it takes forever to catch up compared to any other terminal (except the JetBrains builtin terminal, which is almost as slow but still noticeably faster).
  - sgt 3y ago
    In fact, some people still swear by xterm or rxtv alone due to sheer speed. I use Terminal.app on Mac which is also very fast but not xterm/rxvt fast.
hnlmorg 3y ago
I’m not the biggest fan of electron generally speaking but I don’t agree with your argument that Electron is too slow to work as a terminal emulator. Yes speed matters, but not nearly as much as you claim. Commands are run as separate processes so as long as the terminal reads from its PTY fast enough not to block those processes, which in all bar a very few edge cases it will be, you’re not going to experience any difference in performance. Besides, if you’re concerned about millisecond latency, then the issue you actually have is with multimedia content being rendered in the terminal rather than Electon itself. So no terminal emulator of this generation is going to meet your needs irrespective of what technologies it’s built from. Edit: downvoted for stating a fact. Maybe I should have also stated that I’ve also been working on this exact problem. In fact I’ve already got a shell that provides the CLI parts and been playing around with different technologies to handle the multimedia parts of the terminal emulation. It’s a harder problem to solve than people hand wave away when they complain about electron (hence why I only have a shell available for public use at this stage).
- sgt 3y ago
  I disagree with this sentiment (I didn't downvote you though). Most serious terminal users are in fact concerned with millisecond latency. Consider also that typing with 1ms additional latency per keystroke is noticable - even though it sounds counterintuitive. And note the other threads here with people noting that even the VS Code terminal can get very slow.
  - hnlmorg 3y ago
    > I disagree with this sentiment (I didn't downvote you though). Most serious terminal users are in fact concerned with millisecond latency. SOME are concerned with millisecond latency, I agree. My point wasn't that there aren't users who care. It's that IF you care, then you shouldn't be using a multimedia terminal emulator. Putting rich content into the terminal will always add overhead. It doesn't matter if your terminal emulator is written in Electron or Rust, graphics is always going to be slower than text. So if you care about millisecond latency, then the problem with this terminal isn't the Electron part. I also disagree with your point that most serious terminal users care about millisecond latency. A lot probably do but I'm about as serious a terminal user can get; I've literally written and use my own shell because existing shells weren't powerful enough for me yet I didn't want to leave the terminal. The reason I don't care about millisecond latency is because you literally don't notice millisecond latency. More on that below. > Consider also that typing with 1ms additional latency per keystroke is noticable - even though it sounds counterintuitive. 1ms is literally imperceptive. There's plenty of evidence to back that up but I'll quote a SO answer: "The 100 ms threshold was established over 30 yrs ago. See: Card, S. K., Robertson, G. G., and Mackinlay, J. D. (1991). The information visualizer: An information workspace. Proc. ACM CHI'91 Conf. (New Orleans, LA, 28 April-2 May), 181-188. Miller, R. B. (1968). Response time in man-computer conversational transactions. Proc. AFIPS Fall Joint Computer Conference Vol. 33, 267-277. Myers, B. A. (1985). The importance of percent-done progress indicators for computer-human interfaces. Proc. ACM CHI'85 Conf. (San Francisco, CA, 14-18 April), 11-17." source: https://stackoverflow.com/a/2547903 https://stackoverflow.com/a/2547903 > And note the other threads here with people noting that even the VS Code terminal can get very slow. ...under some very specific workflows. I literally explained that workflow in my post as well: "as long as the terminal reads from its PTY fast enough not to block those processes, which in all bar a very few edge cases it will be..." I do acknowledge that Electron is going to be slower than native code. Of course it's going to be slower. The question isn't whether Electron is as performant as native code, the actual point the GP made before their edit (a very cheeky edit on their part too) was that processes run slower in an Electron terminal. Which is horsehit in all bare a few edge cases.
dontlaugh 3y ago
I’m not a fan of Electron either, but I don’t see how latency and resource usage are any more important for a terminal than other apps, like editors or messaging apps or email etc.
- benrutter 3y ago
  I made the mistake of using Tabby (another electron terminal) a while back, and it convinced me electron terminals shouldn't exist. Its easy to accidentally run a command to print out a lot of text in a terminal, at which point the slow rendering pace means you'll need to kill your session and restart (or wait 5 minutes). That just can't happen with emails in the same way because the displayed content is more predictable.
deleted 3y ago
[deleted]
kstrauser 3y ago
I have to agree that this makes it a non-starter for me, for those reasons. If I ever, ever feel the tiniest bit of latency in a terminal, or see the slightest bit of slowness when some program dumps a bunch of text to stdout, it's failed its one job as a terminal. Nah, I don’t think this one’s for us.
- sawka 3y ago
  Most terminal latency comes from the network overhead. We're running a golang process behind the electron app to do the underlying terminal integration. There is no lag as we can get sub-millisecond response times locally. In fact, because of that, cat-ing a 1GB file on Wave can actually run faster than on iTerm because golang buffers and processes the output and we just drop UI screen updates when we're behind.

by sgt 3y ago

wg0 3y ago

Actually - VSCode comes with a built-in Terminal that's also built using Electron and TS. Never had any issues with it while using it as built-in Terminal from time to time.

franga2000 3y ago
The VSCode terminal is the first time I've felt input lag in a terminal emulator before. When a program shits out thousands of lines of text (like catting a long log file), it takes forever to catch up compared to any other terminal (except the JetBrains builtin terminal, which is almost as slow but still noticeably faster).
- sgt 3y ago
  In fact, some people still swear by xterm or rxtv alone due to sheer speed. I use Terminal.app on Mac which is also very fast but not xterm/rxvt fast.

hnlmorg 3y ago

I’m not the biggest fan of electron generally speaking but I don’t agree with your argument that Electron is too slow to work as a terminal emulator. Yes speed matters, but not nearly as much as you claim. Commands are run as separate processes so as long as the terminal reads from its PTY fast enough not to block those processes, which in all bar a very few edge cases it will be, you’re not going to experience any difference in performance. Besides, if you’re concerned about millisecond latency, then the issue you actually have is with multimedia content being rendered in the terminal rather than Electon itself. So no terminal emulator of this generation is going to meet your needs irrespective of what technologies it’s built from. Edit: downvoted for stating a fact. Maybe I should have also stated that I’ve also been working on this exact problem. In fact I’ve already got a shell that provides the CLI parts and been playing around with different technologies to handle the multimedia parts of the terminal emulation. It’s a harder problem to solve than people hand wave away when they complain about electron (hence why I only have a shell available for public use at this stage).

sgt 3y ago
I disagree with this sentiment (I didn't downvote you though). Most serious terminal users are in fact concerned with millisecond latency. Consider also that typing with 1ms additional latency per keystroke is noticable - even though it sounds counterintuitive. And note the other threads here with people noting that even the VS Code terminal can get very slow.
- hnlmorg 3y ago
  > I disagree with this sentiment (I didn't downvote you though). Most serious terminal users are in fact concerned with millisecond latency. SOME are concerned with millisecond latency, I agree. My point wasn't that there aren't users who care. It's that IF you care, then you shouldn't be using a multimedia terminal emulator. Putting rich content into the terminal will always add overhead. It doesn't matter if your terminal emulator is written in Electron or Rust, graphics is always going to be slower than text. So if you care about millisecond latency, then the problem with this terminal isn't the Electron part. I also disagree with your point that most serious terminal users care about millisecond latency. A lot probably do but I'm about as serious a terminal user can get; I've literally written and use my own shell because existing shells weren't powerful enough for me yet I didn't want to leave the terminal. The reason I don't care about millisecond latency is because you literally don't notice millisecond latency. More on that below. > Consider also that typing with 1ms additional latency per keystroke is noticable - even though it sounds counterintuitive. 1ms is literally imperceptive. There's plenty of evidence to back that up but I'll quote a SO answer: "The 100 ms threshold was established over 30 yrs ago. See: Card, S. K., Robertson, G. G., and Mackinlay, J. D. (1991). The information visualizer: An information workspace. Proc. ACM CHI'91 Conf. (New Orleans, LA, 28 April-2 May), 181-188. Miller, R. B. (1968). Response time in man-computer conversational transactions. Proc. AFIPS Fall Joint Computer Conference Vol. 33, 267-277. Myers, B. A. (1985). The importance of percent-done progress indicators for computer-human interfaces. Proc. ACM CHI'85 Conf. (San Francisco, CA, 14-18 April), 11-17." source: https://stackoverflow.com/a/2547903 https://stackoverflow.com/a/2547903 > And note the other threads here with people noting that even the VS Code terminal can get very slow. ...under some very specific workflows. I literally explained that workflow in my post as well: "as long as the terminal reads from its PTY fast enough not to block those processes, which in all bar a very few edge cases it will be..." I do acknowledge that Electron is going to be slower than native code. Of course it's going to be slower. The question isn't whether Electron is as performant as native code, the actual point the GP made before their edit (a very cheeky edit on their part too) was that processes run slower in an Electron terminal. Which is horsehit in all bare a few edge cases.

dontlaugh 3y ago

I’m not a fan of Electron either, but I don’t see how latency and resource usage are any more important for a terminal than other apps, like editors or messaging apps or email etc.

benrutter 3y ago
I made the mistake of using Tabby (another electron terminal) a while back, and it convinced me electron terminals shouldn't exist. Its easy to accidentally run a command to print out a lot of text in a terminal, at which point the slow rendering pace means you'll need to kill your session and restart (or wait 5 minutes). That just can't happen with emails in the same way because the displayed content is more predictable.

deleted 3y ago

[deleted]

kstrauser 3y ago

I have to agree that this makes it a non-starter for me, for those reasons. If I ever, ever feel the tiniest bit of latency in a terminal, or see the slightest bit of slowness when some program dumps a bunch of text to stdout, it's failed its one job as a terminal. Nah, I don’t think this one’s for us.

sawka 3y ago
Most terminal latency comes from the network overhead. We're running a golang process behind the electron app to do the underlying terminal integration. There is no lag as we can get sub-millisecond response times locally. In fact, because of that, cat-ing a 1GB file on Wave can actually run faster than on iTerm because golang buffers and processes the output and we just drop UI screen updates when we're behind.