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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
