Waveterm(waveterm.dev)
waveterm.dev
Waveterm
https://www.waveterm.dev/
131 comments
I thought it was just the marketing trying to show off too many features at once, and I'd really like a more workspace-centric approach to terminals, so I gave it a download -- unfortunately the actual UI is worse than the screenshots they show.
- 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.
- 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.
I haven’t tried this yet (so please take my commentary with a grain of salt), but my initial thoughts are: (1) it looks interesting, (2) it looks overwhelming (there’s a lot going on in those screenshots), and (3) it’s likely slow (I might be completely wrong).
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.
[0]: https://sw.kovidgoyal.net/kitty
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.
[0]: https://sw.kovidgoyal.net/kitty
Tried Kitty for a few months. Didn't like the developer's attitude when people raised concerns and asked for "tabs". He said "just go use tmux on top of Kitty." I use tmux sometimes, but the idea that you have to glue together several pieces of software (each of which can break at any point) just to get basic functionality (like tabs that some people want) is insane.
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 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.
Umm kitty has native tabs and the developer never tells anyone to tuse tmux, on the contrary he tells people not to use tmux. You are confusing kitty with alacritty.
2. I agree that the UI needs a lot of polish. I would get a designer if you don't have one, and have another designer critique it if you do.
First time I saw an idea like this was with termkit [1], which I thought was great and was sad to see it didn't get continued development.
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.
[1] https://github.com/unconed/TermKit
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.
[1] https://github.com/unconed/TermKit
> we limit ourselves by having our CLI interfaces be tied to a thing that emulates a terminal from the 80s
> 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!
[0] https://en.wikipedia.org/wiki/Xterm
[1] https://en.wikipedia.org/wiki/Sixel
> 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!
[0] https://en.wikipedia.org/wiki/Xterm
[1] https://en.wikipedia.org/wiki/Sixel
Showing graphics using Sixel is an improvement, but is just a hack to get images to show in a text-only interface. You really do want a native image, so why not get one that you can also right-click and "save as...".
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?
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?
> You really do want a native image, so why not get one that you can also right-click and "save as...".
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.
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.
TermKit was one of the inspirations for Extraterm ( https://extraterm.org/ ). It separates command output, allows for reuse of previous output, as well mixing content types.
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.
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.
Terminal interfaces are devs due for an upgrade, but this doesn’t feel like a genuine solution to that, this feels like just try to pollute CLI land with the web-tech everyone already complains about.
I don't know who this tool is for but it is certainly not designed for me. Unrelated but I recently learned the magic of
vim scp://1.2.3.4/file_to_editReading the page and encountering "web standards" got me thinking (red flag #1), why would I care for web standards in a terminal?
Another red flag is bashing vim.
Final - looking at the code and seeing "electron".
Another red flag is bashing vim.
Final - looking at the code and seeing "electron".
"Another red flag is bashing vim."
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.
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 and like vim. I think that sentence is not aimed at us, and you have to read the whole paragraph as one.
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.
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.
I've never seen 'ditch' being used in a flattering context.
Didn't realize that was offensive (although I am an emacs user)! Just updated the website to change that wording to "Great alternative to vim for new terminal users or quick updates!" :)
Agree, but I think the usage of “ditch” is a bit snarky.
"Ditch Vim" is definitely weird wording for people (like myself) that consider Vin great. I can understand it for those who don't grok it though, then it's rather frustrating.
> Reading the page and encountering "web standards" got me thinking (red flag #1), why would I care for web standards in a terminal?
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.
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.
No offense intended to vim! I've been using vi for over 25-years, and I use emacs as my primary code editor. I love the terminal. That being said, it can be daunting to use vim on a remote machine when you're just getting started (think intro CS class). Knowing input modes, dealing with strange copy/paste behavior, and no vi configuration out of the box is not a good experience. With Wave you get an option -- if you like vim, great, use it, if not, you have an alternative.
[deleted]
It looks really nice!
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.
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.
Back when I used a debian based distribution I made use of https://bedrocklinux.org/ to make use of the AUR. It's not for everyone though.
Wow, that is super clever and really cool!
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
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
It certainly comes with some craziness. But most of it is documented[1]! For instance using BTRFS and GRUB with Bedrock currently causes issues.
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
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
Browser based terminals look like one of those bad ideas that people just refuse to give up on. Like singletons and graphical imperative programming.
Certainly not for everybody, but using web tech we can move faster, improve accessibility, and create a consistent cross-platform app much faster than with native UI. It also makes it much more accessible for plugins (in the future), and to receive open-source contributions.
This isn't really a terminal app at this point — it's more like a dedicated GUI for bash. While you can launch zsh from bash, then this app sees it as an infinitely-running subprocess of one command, which basically breaks this app's central feature (treating each command as its own entity). You can't use the app normally anymore, as now you are typing in the embedded subcommand rectangle and not the main CLI.
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).
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).
Neat, you can setup SSH connections as native terminal sessions.
When you type in your server info and click connect, this happens:
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...
Not to shill, but WezTerm can also do this and isn't built on web stacks, if anyone is looking for something similar.
And not backed by venture capital.
The wezterm built-in mosh+tmux I use all.the.time and it works great. Working from my personal macbook I have a wezterm window running on my work Linux machine with multiple screens and windows and having first-class multiple window support in the terminal has been nice.
Wezterm rules…
That is my main issue as well. What is mshell? Why do I have to install it on my remote? Surely a dependency like that should be pointed out front and centre...
[deleted]
My first thought when seeing the screenshot was that it feels like it should just be a vscode extension.
Is anyone actually looking to use one of these "style over substance" terminals? Sure they look pretty at first glance, but instill significantly more cognitive load on the reader to understand what information it's trying to present.
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?
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?
I don't know. I feel like __some__ additional features in terminal would be nice. Like having the new vscode sticky scroll, incorporating a file manager like ranger into common terminals, being able to display long (CURL) commands in a more structured way (maybe a hierarchical tree that you can traverse), etc. I use Vim on Fish shell but it'd be nice to have Vim baked right in the terminal as well.
We aren't just doing style (although that's the headline feature). There are real underlying improvements as well by moving terminal/shell state local. Wave also gives universal history, persistent/resumable sessions, and metadata about commands (exit code, duration, cwd, environment, etc.). Lots more is possible (and will be shipped) in the future.
Looks very cool. Happy to see some innovation in a space where I feel some people are oddly resistant to change (as we see in a few cases in this thread).
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).
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).
Why do I need to agree to the terms of service to run a terminal program?
This is not the terminal for me, but it looks like a pretty typical “as is, no warranty, no liability, telemetry is collected” TOS.
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.
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.
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.
There’s lots of not venture backed open source terminals right now and even more being worked on.
Nobody who’s been paying any attention to the strong correlation of venture to enshittification is going to give this a second look.
Nobody who’s been paying any attention to the strong correlation of venture to enshittification is going to give this a second look.
Difficult to find due to the keywords involved. In point form:
-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.
-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.
A terminal that streams telemetry. Just what we needed.
Get this BS out of here.
Get this BS out of here.
Something about this design make it seem more like a chat interface to the terminal, and after using ChatGPT the idea of chatting to a raw computer terminal instead of one way commands seems so obvious... the future interface for everything looks more and more like it's just going to be chat based, or like a Jupyter notebook, and that seems amazing to me... because it's getting us ready for voice-based computing like Star Trek.
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.
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.
> voice-based computing like Star Trek.
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.
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.
I found the prompt at the bottom irritating, and I still find it irritating for ChatGPT. But chat apps are probably the apps that normal people spend most of their time in, so for them it's intuitive.
[deleted]
Was using vim for quick edits on files instead of vscode a significant pain point?
Yes, for me an absolute killer feature. If a terminal had only that feature I'd switch to it, but Wave looks a bit too complex for me, since I mostly use VS code anyway. (I use micro, rather then vim, which is still not as good as VS code's editor, and also not fully consistent with it.)
Electron…
It's Electron/TS based. I seriously doubt I can get used to using an Electron based beast for something as critical as a terminal.
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.
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.
Actually - VSCode comes with a built-in Terminal that's also built using Electron and TS.
Never had any issues with it while using it as built-in Terminal from time to time.
Never had any issues with it while using it as built-in Terminal from time to time.
The VSCode terminal is the first time I've felt input lag in a terminal emulator before. When a program shits out thousands of lines of text (like catting a long log file), it takes forever to catch up compared to any other terminal (except the JetBrains builtin terminal, which is almost as slow but still noticeably faster).
In fact, some people still swear by xterm or rxtv alone due to sheer speed. I use Terminal.app on Mac which is also very fast but not xterm/rxvt fast.
I have to agree that this makes it a non-starter for me, for those reasons. If I ever, ever feel the tiniest bit of latency in a terminal, or see the slightest bit of slowness when some program dumps a bunch of text to stdout, it's failed its one job as a terminal. Nah, I don’t think this one’s for us.
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’m not a fan of Electron either, but I don’t see how latency and resource usage are any more important for a terminal than other apps, like editors or messaging apps or email etc.
I made the mistake of using Tabby (another electron terminal) a while back, and it convinced me electron terminals shouldn't exist. Its easy to accidentally run a command to print out a lot of text in a terminal, at which point the slow rendering pace means you'll need to kill your session and restart (or wait 5 minutes). That just can't happen with emails in the same way because the displayed content is more predictable.
I’m not the biggest fan of electron generally speaking but I don’t agree with your argument that Electron is too slow to work as a terminal emulator. Yes speed matters, but not nearly as much as you claim. Commands are run as separate processes so 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, you’re not going to experience any difference in performance.
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).
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).
I disagree with this sentiment (I didn't downvote you though). Most serious terminal users are in fact concerned with millisecond latency.
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.
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.
> I disagree with this sentiment (I didn't downvote you though). Most serious terminal users are in fact concerned with millisecond latency.
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.
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.
I played around with adding 1ms and 5ms etc to each keystroke and when typing very fast (e.g. 60-70wpm) you will definitely notice it. It's not even "imperceptive", it's in fact highly noticable. I guess I'll need to find a way to bring that hack back to life in order to show this to HN.
what's the likelihood that your routine to make the delay isn't itself adding additional delay with the call overhead? I ask because this topic has been the subject of extensive scientific research already and their evidence doesn't back up your findings.
The scientific research you refer to is basically looking at the equialent of a single keypress, or a specific delay to a frame or similar. Once you have a whole burst of sequential keypresses with an interactive interface, it becomes very evident. I'll see what I can do in terms of the experiment.
Keyboarders are prolly the ppl with fastest trained finger action on earth, be it on a computer keyboard or a music keyboard. In digital music production there is a magic threshold of 15-20ms latency for input signals - if a signal takes longer to process through your DSPs/computers lineup, any good musician will start to perceive the latency (btw thats more like an on/off phenomenon). Below that range we cannot detect any latency chance anymore, as our neural system is not made for higher time resolution (also the reason why 60 FPS gives us the illusion of a movie).
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.
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.
[deleted]
This looks nice, but I am very, very, very wary of adopting a tool like this without understanding the business model. There are two possible ways I've seen this go:
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.
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.
My concern with all attempts these days to reinvent the terminal is that they will phone home. This is a security and privacy nightmare considering what terminals are used to do, especially for devops working on production.
Any terminal app that has telemetry is a hard absolute no.
Any terminal app that has telemetry is a hard absolute no.
I agree. Two points:
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.
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.
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!
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!
Thank you.
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!
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!
[deleted]
This looks cool and I could get over my worries about Electron as a terminal except for the fact that it requires that you install something on the remote machine to get any of the benefits. I really don't like that it tried to do that before I had done anything but add a connection (there was no warning or indication that something would be installed).
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.
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.
I liken this more to how vscode operates. I use that to develop remotely inside a vdi (or inside a local vm over ssh). It will install an instance of itself on the remote host and then it's like I'm operating "locally" out of that host. For work, I use one vm for all my development. For personal, I have a desktop computer I dedicate to development that I often access remotely via laptop/vscode.
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.
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.
[deleted]
But like…why?
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!”??
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!”??
> They’re about the fastest people on a computer I’ve seen in my life.
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.
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.
> 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.
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.
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.
It feels like it's for developers using VSCode, who are not comfortable with a terminal. It is likely meant to be easy-to-use with a mouse-friendly user interface and lots of built-in functionalities.
I'm not the average vim user. I'd like to use only one tool to edit code (the monaco editor), whether in VS code, in web interfaces like the cloudflare workers playground or the deno playground, and also in the terminal.
[deleted]
An Electron terminal with a EULA backed by two venture capitals. What's the world coming to?
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.
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.
I use VSCode's integrated terminal all the time and its performance and latency is indistinguishable from Gnome Terminal.
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?
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?
It's buried in the FAQ:
> 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.
> 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.
> What's their business plan?
"telemetry"
"telemetry"
> What's their business plan?
Mumble wango cloud mumble collaboration features...
But basically, to burn through millions in VC money I think.
Mumble wango cloud mumble collaboration features...
But basically, to burn through millions in VC money I think.
[deleted]
I hope your vim doesn't take hundreds of milliseconds for anything, other than possibly opening huge files.
I said I want a latency within the hundreds of milliseconds. vim and most terminal emulators are well within this threshold, a very complex UI in Electron is not.
It looks fancy but after using it for a while I can't really see what are the benefits of using it over something like tmux which is battle tested, fast, robust available everywhere, etc.
I haven't tried this, but I'm always frustrated that tmux doesn't have sane scroll and copy/paste behavior out of the box. I'm not even sure how to configure it properly to have sane behavior. If this could solve that by default, as well as making it easier to restore sessions I might be in.
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?
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?
While I use tmux and don't like this new Wave app, tmux is not entirely battle-tested. For example, displaying images in terminal is a problem with tmux.
[deleted]
"Cross-platform"
Doesn't support Windows...
Doesn't support Windows...
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.
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.
[deleted]
a1o(1)
Fischgericht(1)
i thought this was about PPG synths but no
This looks nice! Editing in a proper editor is for sure nicer than Vim - does that work even over SSH without having to install anything? Proper history search also sounds nice.
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.
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.
> Vim sucks.
Why?
Why?
Two main reasons:
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.
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.
Vim isn’t for you, and that’s fine. Statements like “all Vim users…” aren’t really a great contribution to the discussion.
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.
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.
> Vim isn’t for you, and that’s fine.
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.
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.
It's not the default everywhere. Some platforms default with nano.
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
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
99%? Really?
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.
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.
Most people who use vim absolutely love it, otherwise they wouldn’t use it on day to day basis. Those who don’t usually don’t care.
> It has a ridiculous learning curve to get to the same editing proficiency as just having multiple cursors.
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.
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.
Meh, I'll stick with vim. Thanks for the advice though.
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?