Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Waveterm

waveterm.dev

Post reply on HN
Print view View original

101–110 of 132 posts

Re: Waveterm

#101

Post by sgt »

hnlmorg wrote: post #39
sgt wrote: post #32

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.

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 d…

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.

Re: Waveterm

#102

Post by codetrotter »

tssva wrote: post #88
krzyk wrote: post #76

Reading the page and encountering "web standards" got me thinking (red flag #1), why would I care for web standards in a terminal ? Another red flag is bashing vim. Final - looking at the code and seeing "electron".

"Another red flag is bashing vim." The website in context of discussing their inline editor says, "Ditch vim for quick updates.". You seem to have a very low threshold for what is considered bashing.

I use vim and like vim. I think that sentence is not aimed at us, and you have to read the whole paragraph as one.

I use vim keybindings in the JetBrains IDEs I use. And that’s because I came from vim. For me vim is the natural choice. And I use my JetBrain IDEs most of the time because of the added features.

But for people who don’t like vim particularly much but who only use vim because they need “something” for small edits, I can see that it would be attractive to them to have a small VSCode-like editor for quick edits, when they normally use VSCode as their IDE.

That’s the context you need to see it from, I think. For those people, it’d be an advantage to ditch vim, as they never particularly liked vim in the first place.

Re: Waveterm

#103

Post by esafak »

jay-barronville wrote: post #73

I haven’t tried this yet (so please take my commentary with a grain of salt), but my initial thoughts are: (1) it looks interesting, (2) it looks overwhelming (there’s a lot going on in those screenshots), and (3) it’s likely slow (I might be completely wrong). To elaborate a bit… 1. I love good design work and well-designed (UI-wise) software, and it certainly looks like the creators of Wave Terminal have made that…

2. I agree that the UI needs a lot of polish. I would get a designer if you don't have one, and have another designer critique it if you do.

Re: Waveterm

#104

Post by hnlmorg »

sgt wrote: post #101
hnlmorg wrote: post #39

Earlier quoted context omitted.

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 d…

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.

> 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

> 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.

Re: Waveterm

#105

Post by sawka »

krzyk wrote: post #76

Reading the page and encountering "web standards" got me thinking (red flag #1), why would I care for web standards in a terminal ? Another red flag is bashing vim. Final - looking at the code and seeing "electron".

No offense intended to vim! I've been using vi for over 25-years, and I use emacs as my primary code editor. I love the terminal. That being said, it can be daunting to use vim on a remote machine when you're just getting started (think intro CS class). Knowing input modes, dealing with strange copy/paste behavior, and no vi configuration out of the box is not a good experience. With Wave you get an option -- if you like vim, great, use it, if not, you have an alternative.

Re: Waveterm

#106

Post by sawka »

tssva wrote: post #88
krzyk wrote: post #76

Reading the page and encountering "web standards" got me thinking (red flag #1), why would I care for web standards in a terminal ? Another red flag is bashing vim. Final - looking at the code and seeing "electron".

"Another red flag is bashing vim." The website in context of discussing their inline editor says, "Ditch vim for quick updates.". You seem to have a very low threshold for what is considered bashing.

Didn't realize that was offensive (although I am an emacs user)! Just updated the website to change that wording to "Great alternative to vim for new terminal users or quick updates!" :)

Re: Waveterm

#107

Post by sawka »

tonnydourado wrote: post #97

Browser based terminals look like one of those bad ideas that people just refuse to give up on. Like singletons and graphical imperative programming.

Certainly not for everybody, but using web tech we can move faster, improve accessibility, and create a consistent cross-platform app much faster than with native UI. It also makes it much more accessible for plugins (in the future), and to receive open-source contributions.

Re: Waveterm

#108

Post by sawka »

enriquto wrote: post #69
rogual wrote: post #21

First time I saw an idea like this was with termkit [1], which I thought was great and was sad to see it didn't get continued development. I really feel like we overlook the ways in which we limit ourselves by having our CLI interfaces be tied to a thing that emulates a terminal from the 80s. The composability, scriptability, history, etc. of CLIs is great, but why should that preclude us from being able to quickly s…

> we limit ourselves by having our CLI interfaces be tied to a thing that emulates a terminal from the 80s > why should that preclude us from being able to quickly show a PNG or graph a function? I'm confused by this comment. The quintessential "terminal from the eighties" is xterm [0], that exists today and supports all kind of graphics protocols, like sixel [1]. I use it everyday, and it is very handy to graph func…

Showing graphics using Sixel is an improvement, but is just a hack to get images to show in a text-only interface. You really do want a native image, so why not get one that you can also right-click and "save as...".

The terminal's text interface is amazing, no one wants to mess with that. But when you look at TUI frameworks, they are using text as UI which is not great. Instead of showing a table with dashes and pipes, why not show an HTML table that you can interact with and can copy/paste directly into excel or google sheets?

Re: Waveterm

#109

Post by sawka »

lijok wrote: post #75

Is anyone actually looking to use one of these "style over substance" terminals? Sure they look pretty at first glance, but instill significantly more cognitive load on the reader to understand what information it's trying to present. If people are really interested in using terminals like this, is there a business case to be made for incredibly visually-stylish programming languages as well?

We aren't just doing style (although that's the headline feature). There are real underlying improvements as well by moving terminal/shell state local. Wave also gives universal history, persistent/resumable sessions, and metadata about commands (exit code, duration, cwd, environment, etc.). Lots more is possible (and will be shipped) in the future.

Re: Waveterm

#110

Post by sawka »

wredue wrote: post #90
lxe wrote: post #83

Why do I need to agree to the terms of service to run a terminal program?

This is not the terminal for me, but it looks like a pretty typical “as is, no warranty, no liability, telemetry is collected” TOS. Even if I was on the market for a slow, space wasting terminal, it appears venture backed, so enshitification is guaranteed making this terminal unusable from the onset.

I understand your concerns, but in this case venture backed means we have the resources to put full-time resources on it and push it forward quickly (as opposed to just being an interesting side project). We need an open source modern terminal alternative, otherwise this market will be taken over by closed source alternatives.
Post reply on HN