Wave Terminal: A Modern New Terminal That You'll Love If You Hate Command Line(news.itsfoss.com)
news.itsfoss.com
Wave Terminal: A Modern New Terminal That You'll Love If You Hate Command Line
https://news.itsfoss.com/wave-terminal/
37 comments
I love the command line, and I doubt I'll use this terminal, but "each command and its output is a separate box" is a way of using a terminal that I've long wished for. My day is full of `clear && bazel build`, not because I want to clear my history, but because I want to treat the build output as a single unit.
warp (warp.dev) does this
yeah, though unlike wave, warp is not open source and only really works on mac
I wonder if the right way to sell this is really "CLI for CLI haters" -- if you really find the CLI scary/painful -- distinct from being frustrated with the typical Unix UI limitations -- this doesn't look any less scary.
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).
Spoiler:
> it is an Electron app
Saved you a download.
> it is an Electron app
Saved you a download.
Spoilers II and III:
> There's telemetry (and)
> a terms of service to agree toTelemetry is completely optional and anonymous (and we provide a switch to turn it off when you launch the app).
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.
No telemetry is anonymous, these days it's trivial to associate an IP with any number of personally identifying factors. All you need is partners.
Its true, that a browser engine has a higher resource usage initially - it can easily hog 50-100MB without any content being loaded, but seriously, thats not much of a concern anymore these days. On the other hand it provides a great programming environment for web devs with many bells and whistles (which arguably might not even be needed for certain electron apps).
What concerns me more is what web devs actually do within that environment - it's almost like many devs have lost a basic sense of resource management, like memory comes for free, gets garbage collected anyway, so why should I care. Many electron apps are overly shiny in appearance, backed by tons of graphics and animations, but in fact are lousy managed under the hood. I am not quite sure if this is a direct effect of using a GC language, or if Javascript+HTML in particular makes it too easy to get quite far without some comprehension of inner works of the browser and the machine underneath. This is also a pain with modern webpages - I really dont get it, why a browser with 8 tabs opened can easily grow to several GBs after a while.
There are a few counter examples - electron apps that do heavy lifting while still being nice to your RAM and CPU. Sadly thats exceptional, not the common case. I tend to blame sloppy web devs here.
What concerns me more is what web devs actually do within that environment - it's almost like many devs have lost a basic sense of resource management, like memory comes for free, gets garbage collected anyway, so why should I care. Many electron apps are overly shiny in appearance, backed by tons of graphics and animations, but in fact are lousy managed under the hood. I am not quite sure if this is a direct effect of using a GC language, or if Javascript+HTML in particular makes it too easy to get quite far without some comprehension of inner works of the browser and the machine underneath. This is also a pain with modern webpages - I really dont get it, why a browser with 8 tabs opened can easily grow to several GBs after a while.
There are a few counter examples - electron apps that do heavy lifting while still being nice to your RAM and CPU. Sadly thats exceptional, not the common case. I tend to blame sloppy web devs here.
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.
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.
> Saved you a download.
You did, thank you!
You did, thank you!
It's an electron app because there isn't a better alternative.
In what sense? There isn't a better alternative to package a web app as native, or there isn't a better alternative to writing Electron apps? I think many would argue native dev is a better alternative.
A windows native app? Or an osx one? Linux? Playstation 5 maybe?
Yes, a native application for each major operating system, that respects the OS's UI guidelines, and runs efficiently.
That would take 20x more work just to do a few OSs if were even possible, which it isn't.
Somehow we did this for 30 years, but now that Electron exists, it's impossible?
Fine. Pick a platform to support.
Fine. Pick a platform to support.
When did we do it 30 years ago? With java?
There were many attempts and electron beats them all.
There were many attempts and electron beats them all.
What I meant is that somehow companies released native applications for a multitude of operating systems in years past. Internet Explorer on Solaris, Windows, MacOS. Photoshop and AutoCAD on IRIX, Windows, MacOS. Netscape Navigator on anything with a screen and a keyboard. That's just the stuff I used off the top of my head.
>> You can edit files inline, be it on your local system or the remote machine. And there is no learning curve here. Just use it like a regular text editor.
Oh, like Vim, or Emacs.
Or like ed ?
Oh, like Vim, or Emacs.
Or like ed ?
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")
The next generation replacement for CLIs will be Raycast.com or similar. Seriously.
It's significantly more discoverable, faster to use, and provides a high quality interface out of the box.
Composability is currently lacking, but Launchbar shows how that could be done.
Most importantly, it's ridiculously easy to write extensions for. Chances are, if your shell script needs to handle interactive input, you can write a Raycast extension in fewer lines of code.
Developers who seek to advance the terminal should probably focus on building a FOSS equivalent to Raycast instead.
It's significantly more discoverable, faster to use, and provides a high quality interface out of the box.
Composability is currently lacking, but Launchbar shows how that could be done.
Most importantly, it's ridiculously easy to write extensions for. Chances are, if your shell script needs to handle interactive input, you can write a Raycast extension in fewer lines of code.
Developers who seek to advance the terminal should probably focus on building a FOSS equivalent to Raycast instead.
Terminals are primarily for folks who want to direct their computer, and not be controlled by it.
Always on chatgpt and cloud sync are non-starters in the first realm, terminals in the second.
Always on chatgpt and cloud sync are non-starters in the first realm, terminals in the second.
You just cherry picked two unrelated optional features to justify dismissing an entire interaction-concept.
As we know, defaults are powerful. Defaults that destroy privacy for one of the last trustworthy local-first interfaces left are quite informative.
Neither sync nor chatGPT are on by default in Raycast.
They have some 'splainin to do then, on their home page. Not to mention, I don't even want my local apps to have the potential to do it.
If you move the goalpost even more, it's gonna clip of bounds.
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:
1. The Command-Palette pattern. See [The History of Command Palettes: How Typing Commands Became The Norm Again](https://www.vendr.com/blog/consumer-dev-tools-command-palett...)
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.
[1] For example https://developers.raycast.com/api-reference/user-interface/...
1. The Command-Palette pattern. See [The History of Command Palettes: How Typing Commands Became The Norm Again](https://www.vendr.com/blog/consumer-dev-tools-command-palett...)
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.
[1] For example https://developers.raycast.com/api-reference/user-interface/...
Huh?!
"The perfect swimsuit for those who hate water?"
"The perfect swimsuit for those who hate water?"
Is it just me or does the article read a lot like disguised paid promotion? I have no problem with paid promotions at all, but rather would like to see a disclaimer then.
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.
Thx for clarification. And sorry that I raised that suspicion, seems I misinterpreted the enthusiastic style of the article.