Waveterm
waveterm.dev
waveterm.dev
It’s also kinda weird how they try to add styling everywhere possible… except remove the styling from the output of ls so you can’t distinguish between file vs directory, executable vs non-executable, symlink vs regular file, etc.
I really don’t understand what they are getting at with the copy either:
> The modern terminal that keeps your flow in line
> Keep development moving forward without the copy, pasting, saving, and exporting headache.
What copy, pasting, saving, and exporting headache are they talking about?
- Sidebar that is either HUGE (and branded) or nonexistent (I'd like to see something like Discord's approach here)
- Only UI settings are a font size selector
- The input and cwd are on different lines for some reason (though it shows huge helper text inline with the input)
- Weird borders and shadows on elements that are super jarring.
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 a priority.
2. UX-wise, there’s just too much going on. As someone who lives in my terminal (with the exception of browsing the web, I do virtually everything in my terminal), it’s the single most critical piece of software on my computer and it can never get in my way. I used the same terminal for many years and only switched to kitty [0] a couple years ago after testing it for months. In all of those years, every single terminal I tested managed to get in my way. Somehow, kitty manages to be packed full of features without ever—not even once—getting in my way, being slow, or freezing up on me.
3. Generally speaking, I think building on open web standards is a great thing and a plus. Unfortunately though, even in 2023, my experience has been that it’s really hard to build performant software meant to be run on native platforms using web technologies; the few who get this right—e.g., Figma—are anomalies and they generally invest an enormous amount of time and engineering capital into squeezing out as much performance as possible. As I explained in #2, for something as critical as my terminal, not being performant is simply not an option, so as much as I love the idea of building on open web standards, it actually scares me for software like this.
That said, I’m obviously judging before trying here, so I’ll make some time to test Wave Terminal.
I stopped using Kitty and switched over to iTerm2 and have been happy ever since. Most importantly, it allows me to set a custom keyboard shortcut to summon my terminal any time on macOS.
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 show a PNG or graph a function?
Maybe it's an idea whose time has come.
> 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 functions inline (via gnuplot) and to quickly show png files.
If anything, it is more "modern" terminals that lack these basic functionalities. Bu this is hardly a problem of being stuck with old technology. It is exactly the opposite!
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?
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.
The terminal VSCode has been picking up on these kinds of features lately. Now they can even "sticky" the previous command line at the top of the window when scrolling through long output.
It has taken a long time, but these ideas are slowing spreading around.
vim scp://1.2.3.4/file_to_editAnother red flag is bashing vim.
Final - looking at the code and seeing "electron".
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 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.
In part, I assume that "powered by open web standards" is a euphemism for "built with Electron". It likely also speaks to its inline rendering support, its extensibility model, and its ability to leverage Monaco for code editing.
Ubuntu has made me slightly spoiled and less willing to try anything that's not packaged in the core repos, but maybe I'll make an exception.
VS Code's integrated terminal is pretty great though.
I can't imagine there not being some sort of Arch/Gentoo/LFS style Random Tech Trouble with that much custom craziness, but it does look kind of fun
But when I turned my Linux Mint installation into Bedrock Linux I encountered no weird things. Eventually I starting booting into Arch instead of Linux Mint, but I can still boot Linux Mint if I want and I have access to all of its applications.
It helps that the developer is very active, and often online on IRC for a chat.
One functionality I still hope to see is the ability to use desktop environments across strata. Maybe in the next release.
[1]: https://bedrocklinux.org/0.7/feature-compatibility.html
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).
When you type in your server info and click connect, this happens:
prompt> connecting to user@host...
prompt> error connecting to remote: mshell client not found
prompt> trying auto-install
prompt> installing mshell v0.3.0 to user@host...
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?
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).
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.
Nobody who’s been paying any attention to the strong correlation of venture to enshittification is going to give this a second look.
-rcan used to generally lean slightly left, and banned terrible sources, bigotry as well as outright fake news
-metacanada didn’t like that white nationalism wasn’t allowed, and that far right “sources” weren’t allowed
-metacanadians get a couple people on the mod team who pretended for years to being more centrist/slightly left
-metacanadians began whining for MONTHS that the right wing had no representation on the mod team (except the couple that were there pretending to be reasonable)
-/r/Canada sleuths demonstrate that multiple mods on the team were in fact alts of metacanadians already, and that further implementing metacanadians mods would lead to a takeover
-/r/Canada mods disagreed, and installed a couple more /r/metacanada mods
-/r/metacanada now has the majority moderator total and begins a full takeover by actively harming the moderation and “showing the moderation is ineffective” which can lead to Reddit admins “stealing” a sub from you (and in this case did)
-/r/Canada is now essentially just an alt-right propaganda outlet that actively allows bigotry, and, in true conservative fashion, instantly bans criticism of the sub and mods.
Get this BS out of here.
I wish one day I can just turn on my computer and it does nothing but chat, no distracting apps or web browsers, just a minimalist chat interface.
It sure if you’re remembering most of Star Trek very well, the crew evidently, and demonstrably does more work on their consoles, which have actual UI’s.
Can you imagine trying to navigate to a sub directory and run a binary but your LLM-assistant has decided that it thinks you want to search for the file name on the web? And you can’t just do it yourself, because they’ve taken away the actual tools from you.
I think I’d actually go and become a goat-farmer at that point.
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.
Never had any issues with it while using it as built-in Terminal from time to time.
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).
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.
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.
Typing latency on modern computers is really high compared to electronic or semi-digital typewriters of the 80s - those old machines had very little circuitry between the keypress and some output action, they were like hard-wired realtime machines to some degree. On today's machines there are tons of buffers, clocks, context switches etc. to pass, with no realtime promises anymore (at least not on typical consumer OS). We really have a "long line" in our machines today.
Electron adds another buffer stack to this madness - the browser engine needs to get the PTY chunks somehow, which is often done with websockets as IPC. Which means put chunks into a http frame, send through network stack to the electron browser engine, decode there - and finally the terminal sees the data as input. A desktop TE does not have to go through that, it can simply write the PTY chunk to its data structures in the same process. Thats the real overhead happening for data IO intensive electron apps regarding input latency.
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 prerequisite -- but half of open-source is about transparency. The web site should clearly explain who built this, why, and how they plan to pay the bills.
This could be sleazy and evil or good. If it's good, explaining that generally provides business value, so most good players will do it proactively. A missing explanation is a yellow flag pointing towards "sleazy and evil."
I understand this is version 0, so please take this as constructive feedback and not an attack. This is my perception as a potential customer, and I hope it provides some value.
Any terminal app that has telemetry is a hard absolute no.
1) The telemetry here can be disabled, which is an upside, but it's default-on.
2) I'm not sure this will be an option forever. Tools like co-pilot MUST phone home, and WILL be increasingly critical to being competitive. Free market forces will likely eventually force universal telemetry (even if not phrased as such).
With ML, we're heading back to the mainframe era, where a central computer center has petaflops of computing power and terabytes of models loaded into memory. I'm not quite sure the answer there, if any.
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 HN posts are early-stage, where things are unfinished and mistakes happen, and are posted by the founder / creator for feedback (in part to catch those; we all have a blind spot with our own products!), so I wouldn't worry about it. At least with my community, such posts don't impact your reputation at all. General mantra is to share early precisely to catch those things, and it's important before adopting a tool, but unless things are secretive, it's best to share version 0.1 for feedback rather than to wait for something finished and polished.
My advice is to take what you wrote above, write it in enforceable legal language, and post it on your web site. It will go a long ways to driving adoption.
Once you add team and enterprise features, post similarly strong language about privacy and security. If I am managing regulated data in my day job (which I am), there had better be darned tight guarantees that FERPA/HIPPA/attorney-client/classified/etc. data doesn't end up sold to the highest bidder when your business goes under, gets bought by IBM, repackaged and sold to Oath, and finally resold to the Russian mafia.
Footnote: I would likely pay for the right enterprise features, especially around collaboration. On the other hand, with progress in LLMs, AI features can very much run locally on a $350 Arc 770 16GB GPU. The newer 7B models are very competitive with ChatGPT!
Thankfully (?) FreeBSD is not supported so nothing was installed but I was still surprised that it even tried without some kind of prompting, ideally with "ask me each time" or "install automatically" options.
The terminal I use can't go dropping software on boxes I connect to (literally hundreds), I guess I'll stick with iTerm 2.
But I wouldn't use vscode to connect to all the random hosts I need to throughout, especially if it's going to drop software.
Where I might consider a tool like is is if I connected to something along the lines of a jumpbox. Some primary host from which I launch most of my other work out of. Once it opens on that jumpbox, I could then ssh out from there. That would possibly make the session sidebar useless - unless I had a "jumpbox" per client/region/project.
At the risk of being “HN talks about rsync on the Dropbox thread” what’s this offering that can’t already do, for free, without a EULA, and inevitable VC-enshittification risk?
> ditch vim for quick updates
Bruh, have you seen the average vim user? They’re about the fastest people on a computer I’ve seen in my life. This is not exactly a convincing argument.
> Render code, images, markdown, and CSV files without ever leaving the terminal.
So like, bat/cat/any number of other tools that already exist, and dont require me to run a whole web-browser to operate?
I just, don’t get the appeal, and I’m so curious as who is the target market for this? Are there armies of devs out there who are like “please, I wish my terminal was actually a web browser with a EULA, pls build a product for me!”??
I've seen plenty of people using vim that seemed fast (as in plenty of keys pressed, screens changed, etc), and thought they were fast but actually were pretty slow compared to some vs code users. I don't think the app makes a huge difference, rather the mentality to improve your workflow and be more efficient.
Once or twice a year I'll see a PR with "<<<<<<< HEAD ... ====== ... >>>>>>> some-branch" in the code merged in (an unresolved merge conflict). Each and every single time, it's a vi or vim user.
Even Warp.dev had the nous to implement their mOdErN terminal in Rust.
I'd rather keep something as crucial as a terminal emulator open-source, and with a latency within the hundreds of milliseconds. For the fancy remoting capabilities there's Emacs.
This appears to be open source. But I don't know how you could make a viable business out of this. I mean it looks nice, but nice enough to pay for? I doubt it. And it's free...
What's their business plan?
> In the future we may launch cloud features to support terminal sharing, shared workspaces, shared playbooks, and terminal backup/sync.
Presumably these cloud features will come with a subscription.
But yeah, the VC backing combined with no solid business model makes me wary. It seems unlikely that the community will be super excited to start building integrations and extensions here to benefit some SV bros.
"telemetry"
Mumble wango cloud mumble collaboration features...
But basically, to burn through millions in VC money I think.
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?
Doesn't support Windows...
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.
I think I will probably stick to VSCode's integrated terminal tbh because it's well integrated. But if I was doing system admin rather than programming this looks awesome.
Don't listen to the predictable HN nonsense. Electron is plenty fast enough for this. Vim sucks. Modern tooling is good.
Why?
1. It has a ridiculous learning curve to get to the same editing proficiency as just having multiple cursors. All Vim users imagine themselves to be editing text at the speed of light while users of "lesser" editors struggle with scalar editing. I have seen zero evidence of that. Anyone of my colleagues that use Vim struggle to do basic tasks because remembering the gazillions of mnemonics is too onerous. Meanwhile I can do anything I want very quickly in VSCode, and with immediate feedback!
2. It infests Unix by being the default editor in many situations (Git commit editing is probably the worst offender). Fine if you want to use your weird editor, but it should 100% not be the default editor EVER. There's a reason exiting Vim is a meme.
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 where it belongs.
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.
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
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.
It takes completing vimtutor to be faster than your average editing experience. What does it even have to do with multiple cursors?
> All Vim users imagine themselves to be editing text at the speed of light while users of "lesser" editors struggle with scalar editing. I have seen zero evidence of that.
I see it every day at work. Those who use vim are much faster on average.
> Meanwhile I can do anything I want very quickly in VSCode, and with immediate feedback!
Read and edit 100k lines file with syntax highlighting. I’d like to see that.
> It infests Unix by being the default editor in many situations (Git commit editing is probably the worst offender). Fine if you want to use your weird editor, but it should 100% not be the default editor EVER. There's a reason exiting Vim is a meme.
Right, because internet memes are a serious indicator of anything.