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

111–120 of 132 posts

Re: Waveterm

#111

Post by sawka »

kstrauser wrote: post #71
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 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.

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.

Re: Waveterm

#112

Post by sawka »

frognumber wrote: post #47

This looks nice, but I am very, very, very wary of adopting a tool like this without understanding the business model. There are two possible ways I've seen this go: 1) Build out a userbase. Once it's sufficient, monetize by screwing the userbase over in some way. 2) Take a bunch of VC money to build something awesome and open-source. Implode when there is no business model. I'm glad this is open-source -- that's pre…

founder/creator here. unfortunately this got posted without us being able to provide the proper HN background information, but i'll try to respond here.

we are committed to open-source. we are committed to providing a free terminal (both free as in speech and free as in beer) to individual users. it doesn't cost us anything to have you run Wave locally, so we don't need to charge. plus if we did charge, open-source lets you fork it, remove the monetization code, and just run it anyway!

but, yes, we do plan on making money at some point. we plan on building out (completely optional, opt-in) team and enterprise features, like collaboration, sharing workspaces/tabs, sharing playbooks, shared history, multi-machine sync, and AI features. these would be paid upgrades. for us there is a clear line -- if you need an account and it touches the cloud, it is a paid. if it runs locally on your machine, using your own resources, it is free.

we plan to add this information to the project and the website!

Re: Waveterm

#113

Post by sawka »

Darmody wrote: post #61

It looks fancy but after using it for a while I can't really see what are the benefits of using it over something like tmux which is battle tested, fast, robust available everywhere, etc.

we don't have parity with tmux yet. in terms of scripting and screen splitting, tmux is better. but, we will get there for most of the features, and i hope we'll be able to deliver those features in a more user-friendly and accessible way to non-power users. by using web tech, we know it is (relatively) easy and possible.

imo, building these types of features into your terminal make a lot more sense than having them run on every remote machine. ever run tmux inside of tmux?

Re: Waveterm

#114

Post by hnlmorg »

IshKebab wrote: post #100
jzb wrote: post #81

Earlier quoted context omitted.

Vim isn’t for you, and that’s fine. Statements like “all Vim users…” aren’t really a great contribution to the discussion. I’ve used Vim for 20+ years. I like it, you don’t have to. I don’t try to shove it down anyone’s throat - nor do I try to tell you why your favorite tool sucks. Because it probably doesn’t suck - for you. Tell me what you like or what doesn’t work for you and leave the middle school attitude wher…

> Vim isn’t for you, and that’s fine. See point 2. Vim isn't for 99% of people but it's somehow the default editor? Most people do not like Vim. That's why this project advertises not having to use Vim, because to 99% of people Vim is something that they don't want or like and can't even quit.

It's not the default everywhere. Some platforms default with nano.

The reason vi(m) and nano are defaults is because they're included in base installs (which a default would need to be). And the reason they're part of base installs is because they have a low footprint. Having, for example, VSCode as the default wouldn't make much sense because base installs might not even have Xorg / Wayland installed.

Changing the default is easy though, it's literally just an environmental variable named $EDITOR

Re: Waveterm

#115

Post by sawka »

pastacacioepepe wrote: post #66

"Cross-platform" Doesn't support Windows...

not yet, but it will. using electron will let us get there quickly, especially if we base support on WSL. honestly it is more of a problem with packaging and testing at this point vs some underlying incompatibility.

note that our windows port will be more like a replacement for PuTTY than a replacement for powershell (at least in the first version). so it will make it easier to log into and administer remote (linux) machines.

Re: Waveterm

#116

Post by jzb »

IshKebab wrote: post #100
jzb wrote: post #81

Earlier quoted context omitted.

Vim isn’t for you, and that’s fine. Statements like “all Vim users…” aren’t really a great contribution to the discussion. I’ve used Vim for 20+ years. I like it, you don’t have to. I don’t try to shove it down anyone’s throat - nor do I try to tell you why your favorite tool sucks. Because it probably doesn’t suck - for you. Tell me what you like or what doesn’t work for you and leave the middle school attitude wher…

> Vim isn’t for you, and that’s fine. See point 2. Vim isn't for 99% of people but it's somehow the default editor? Most people do not like Vim. That's why this project advertises not having to use Vim, because to 99% of people Vim is something that they don't want or like and can't even quit.

99%? Really?

I’ve noticed that nano has replaced vi/Vim in a lot of cases. I’m not a nano fan, but I also don’t feel the need to rant about it. It’s a default, it’s easy to change. Big Vim isn’t plotting to keep a monopoly.

Re: Waveterm

#118

Post by enriquto »

sawka wrote: post #108
enriquto wrote: post #69

Earlier quoted context omitted.

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

> You really do want a native image, so why not get one that you can also right-click and "save as...".

This sounds great!

At least, nowadays you can take a screenshot of the terminal and crop it as you want. Not sure what would you want the "right-click" to do in a terminal... terminal graphics can be overlaid with text and with other images; where does your image actually begin? Screenshoting and cropping is exactly what you need. The only evident case for right-click+save is when the image comes from a png file. But in that case, why do you want to save it again? You already have the file.

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

That would be an amazing feature! Selecting rectangular regions of text in your terminal, instead of whole lines. On the other hand, I feel that excel and google sheets could easily understand a simple table written with dashes and pipes and paste it the right way.

There is a huge room for improvement in terminals. However, it is mostly boring compatibility stuff, to implement protocols in other terminals that they were developed in. There are many existing protocols for nice things, like sub-character mouse interaction and image/video support. Sadly, they are not universally implemented along the terminal space.

Re: Waveterm

#119

Post by rsanek »

Looks very cool. Happy to see some innovation in a space where I feel some people are oddly resistant to change (as we see in a few cases in this thread).

The concept of workspaces makes alot of sense to me, and I love the UI for "you're connected to [x], do you want to change it?"

Not sure if this is just my computer but the `imageview` preview feature seems to have pretty high latency. Looking at over a second to preview a larger jpeg (12MB), which opens <300ms in Mac's Preview or Chrome. This issue is also there if I switch between workspaces (though it's not as bad as on first load).

Re: Waveterm

#120

Post by veidr »

This isn't really a terminal app at this point — it's more like a dedicated GUI for bash. While you can launch zsh from bash, then this app sees it as an infinitely-running subprocess of one command, which basically breaks this app's central feature (treating each command as its own entity). You can't use the app normally anymore, as now you are typing in the embedded subcommand rectangle and not the main CLI.

Sort of interesting, but not if you don't use bash (which I haven't for years, even on Linux, and almost no Mac user does either since Apple ditched it for zsh).

Post reply on HN