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 :)
I agree that React is a good choice for extension developers, but not necessarily react-dom. The web lacks efficient keyboard navigation. What you have is effectively a Jupyter Notebook for the CLI. I by no means want to dismiss the value of that, but there are two possible paradigm shifts that also deserve your attention:
2. Keyboard-accessible UI primitives. Raycast have recognised common terminal use-cases and built general-purpose interface components [1]. They implemented a custom React reconciler for their UI.
The downside of Raycast is, that it's proprietary for MacOS only. I believe a Terminal that capitalises on the above two points while staying FOSS could revolutionise Unix/Linux CLIs.
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")
Anonymous really doesn't mean anything when you must (for technical reasons) send my IP address as part of making the HTTP request. IP addresses is unfortunately all it takes for malicious parties like Google or the various analytics providers to correlate events together with high enough certainty.
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.
I totally understand choosing a HTML engine for output rendering, given the type of additional content you want to provide on top of normal terminal stuff. This would be really painful and expensive to implement & maintain in native GUI libs across several platforms. And vscode kinda shows, that it is possible to maintain a reasonable resource footprint while delivering a productive app with electron. They also achieve that with a relatively small team, which prolly would not have worked out with platform native solutions.
May I ask how you drive the terminal emulation? Is this done by xterm.js or a custom terminal emulator? I am asking, because xterm.js put quite some effort into optimizing things to be on par with other fast desktop terminal emulators, speed and memory-wise.
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.
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.
i don't see any difference between this and what saltstack or ansible are doing. both can run a command on remote machines, and to do that they automatically connect to the machine and copy a program to be run there.
The biggest difference is that I install and execute salt and ansible in order to remotely install software, and I had no expectation that establishing an SSH connection would do that.
you install it locally, but not remote. then you run commands that get executed remotely by way of some tools that get automatically copied to the remote machine via ssh.
I do. And I do it in expectation that this is what will happen, because that's the whole point. Installing software on remote machines is normal for provisioning tools, but decidedly not normal for SSH clients.
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.
I dig it, honestly. Just surprised to see that in teh footer. It's kind of a dealbreaker for me though because so much of my workflow relies on tmux. I tend to align more with the camp that a terminal emulator is just a window into another world, not the world in and of itself. Makes it really easy to move between machines, too. mosh + tmux is half way there.
