sawka

Been hard at work on a new rendering engine for Wave Terminal (https://github.com/wavetermdev/waveterm). Coded up a quick proof of concept for 4th of July showing fireworks rendering in the terminal, triggered by a CLI command. New version is not live yet, but hoping to go into beta soon :)

Interesting take! By implementing our UI in React, we're hoping to make it significantly easier and more accessible to write cross-platform terminal extensions (and renderers / apps for different types of content). One of the interesting directions we're looking at is providing native web-based UI for terminal programs. Like a TUI library that renders to actual UI :)

Hah, 100% not a paid promotion, although it is kinda awesome that you think it is! We were thrilled with the coverage (our first article!) after we soft launched on /r/opensource.

Hah, we did not come up with the headline :). Really the vision for Wave is to have an out-of-the-box excellent terminal experience that's consistent across all of the machines that you log into. We also bring cool new features to the terminal like command blocks, output renderers, persistent sessions, and universal history (across all of your sessions, local and remote).

Wave is a terminal, so you're free to use any editor you'd like, including vim, emacs or ed. We just provide another option for users who don't find vim or emacs very intuitive. I've used emacs to code for over 25 years and have no problem using the CLI or text editors (and it seems like neither do you), but there is a learning curve to teaching intro CS students or semi-technical folks how to use vim on the CLI ("type escape colon w q enter to save")

Telemetry is completely optional and anonymous (and we provide a switch to turn it off when you launch the app).

Wave uses electron for rendering, but a Golang backend for networking and heavy lifting. This gives Wave the ability to be cross platform and still efficient under the hood.

We're looking into Wails! Definite benefits with tighter integration with Go (and we can ditch the node server).

absolutely no telemetry in the helper, full stop. you can inspect the code yourself.

we do hear the feedback though and are working on a popup/notification that will prompt you before we push the helper program for the next release.

yes! would love to do this. the biggest issue is security and how to sandbox that html from the rest of the terminal. we have some ideas on how to do this (iframes, postMessage, etc.) that i think could work.

agree in principle, but i will split some hairs here. if you type "ls" into your local terminal, there's an implicit agreement that it will run the remote "ls" program. the helper program facilitates that in the same way that any other terminal + ssh + shell combo does. it only runs commands in response to your activities in the terminal.

the helper program is completely open source (waveshell) it is similar to the shell scripts or additions to your rc files that other modern terminals might add when connecting to a remote machine to support advanced features. the helper does not need any additional permissions, does not open any ports, runs only for the duration of the connection, and communicates exclusively via stdout/stdin over your standard ssh connection.

i think the terminal can be much better than it is today. i quit my job and started working on this full time after making the prototype because i was convinced that universal history, inline rendering, and persistent sessions just needed to happen. that being said, building a new terminal is hard and requires direction and a full-time team. these things are expensive and venture money will help us bring this idea to life quickly.

i also want to point out that the main competitor in this space is also venture backed and is closed source. we need the money to keep up (with help from the OSS community) and make sure there is a great open alternative in the market.

ya, i love iTerm. been a loyal user for more than 10 years. that is until Wave of course :)

i'd love to figure out what is causing this as we haven't been able to repro it. if you don't mind adding a comment to the issue with anything novel or interesting in your .bashrc / .bash_profile or your machine setup it would be much appreciated.

zsh support and international character support are our top two issues right now. I know the intl chars can work, we just didn't do enough international testing before launch. sorry to hear that it didn't work out of the box for you (the big profile files are also on our radar).

Would love to get any suggestions for what people would like to see rendered inline in the terminal. Things like graphs, audio/video streams, filesystem view (that supports drag&drop from your local machine), graphviz, pdfs. Maybe a graphical way to view a JIRA or Github issue and add a comment? Visual diff? Let me know what you think?

I used Discord for Wave because it is real-time, free, and has a lot of community and auto-moderation facilities built in. It also seems to scale well to large communities. Because you asked, I think it is fair game to share our discord link here: https://discord.gg/XfvZ334gwU

I hear you. That is a problem with a lot of (bad) UIs and why I think people love text-UI (because it is harder to screw up). First, I don't want to get rid of the text UI -- you can always render your commands using the traditional terminal interface. We just want to provide an option to display the output in a richer way. I think Github does a good job of this. You can view a file with line numbers and annotations on the side, but copy/paste won't grab that content because of how the HTML is structured. We hope be similarly attentive to things like that (but of course it is still a WIP).

Haven't tested it myself, but some people have gotten it to run on Windows via WSL. We'll have a true Windows port at some point as well.

a couple that have come up a lot in my talks with devs who use the CLI, but don't necessary live in it are: copy/paste, dealing with tmux, getting disconnected, using 'vi' remotely, having to setup prompts/colors/aliases on every new remote machine, editing commands without using the mouse. I'm not saying there aren't ways to do all of this now (especially when you have a lot of experience), but there can be a steep learning curve for new devs.

All of the tty processing, networking, and stream processing is done in Go, so it is fast. There is obviously more performance work to do, but in some situations our model can actually be faster than other terminals. If you cat a 1GB file in Wave, it actually runs quickly because the frontend can drop frames, while the Go backend is buffering the stream (so to answer your question, JS is not in the hot path, only Golang is).

https://waveterm.dev has some screenshots. Also checkout our twitter feed https://twitter.com/wavetermdev . I couldn't post the homepage as the main link because of a dup check on HN (someone unaffiliated with the company posted the link last week).

Yes, and we own commandline.dev! I wanted, and got, the email address mike (at) commandline.dev :)

thanks, appreciate it! you also get the award for first comment :)

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.

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?

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!

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.

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.