The terminal is on life support. Is it worth saving?

This looks like a potentially cool project, but some of the marketing here is pretty off-putting. First of all the idea that the terminal is "on life support" is laughable, what tool is more universal? And

> Why doesn’t the terminal work like the rest of your apps? Developer tools have evolved towards reusability, composability, and collaboration.

Terminal workflows may be the single best tool in the first 2 of those 3 categories.

In case it wasn’t clear, this is a marketing piece by a startup producing this as a product. As far as I can tell, the main features are:

1. Terminal commands and outputs are divided into blocks

2. Input is handled as a text editor

3. Multiuser collaboration tools

Despite the over-the-top marketing hyperbole, I'm curious. I’d really have to see this in practice to know how practical some of these features are. The great thing about traditional terminals is that the bugs and quirks were generally ironed out years ago. I’m hesitant to introduce anything into my workflow where I might spend a lot of timing fighting the tool or chasing tweaks to get things to work right.

This actually looks pretty cool, but I can't help myself from some quick responses to their first bullets:

> Developers work in teams, but terminals don’t support collaboration

With SSH, tmux supports full terminal session sharing.

> Developers rely on sharing knowledge, but all my terminal work disappears every time I close a session

All shells I know of have configurable history settings. rlwrap will give you the ability to have history (and nice input) for anything shell-ish or interpeter-ish in the terminal.

> Developers work across machines, but my terminal environment is tethered to my computer

All configuration I care about within a terminal can move from machine to machine with typically a single rc file. Often, I don't even need to do this, thanks to remote file editing and being able to send commands via SSH without an interactive session.

> Developers are becoming accustomed to nice interfaces, but the terminal inflicts pain and makes me feel like an idiot when I try to do moderately complicated things

This one is purely subjective and I simply disagree. It's difficult to engage.

A day with your shell's manual and you should be good. Any other applications will have learning curves, and I don't find CLI to be significantly better or worse than a GUI for discoverability.

I don't know if I care about collaboration or the division into blocks, but there is something to be said about how inputting text into a terminal is a completely different mode of operation. I'm alright at getting around in a text editor with system-level keyboard shortcuts, but as soon as I'm typing into a terminal input buffer I feel like I'm in a weird uncanny valley version of typing. Like how I can't do shift + left/right to highlight text and instead it throws in some hexidecimal number that I then have to delete.

Did a startup writing a terminal replacement write this?

Have been doing development predominately in the terminal for the last 15 years... Have no idea what this guy is taking about...

IMO this is trying to fix something that isn't broken.

I agree that terminals have plenty of room for improvement, but this whole article feels like marketing fluff. My brain turned off in the middle of it.

I think you should have waited until you had a demo then did a show hn

The title and opening paragraphs of this article are so aggravating and misguided I almost didn't make it to the end to find out about the interesting technology they have to talk about. Now I can't remember it's name because of the stuff about "the terminal being on life support". Poor approach, hopefully it'll come up again later.

In the world of real advancements in terminal development, Plan 9 had come up with Blit and drawterm in the 90's -- so why haven't we made it back to there yet? the answer mostly lies in the lack of simple drawing primitives in X, the TTY interfaces, etc. People like this warp.dev guy come along every few months and poo-poo everything because secretly they do not want to learn it (and neither do we, really!). But nobody really comes along and tries to fix the termcap-brained mindset we still have when considering terminal design. It seems like after everyone got 256-colour and 24-bit colour support we have just accepted the state of things.

Thanks Peter for posting about us.

Hi HN,

I’m Zach, the author of the post and founder at Warp—a blazingly fast Rust-based terminal.

TLDR; The terminal isn’t built for how modern software engineers work. Software development moved to reusability, composability and collaboration years ago. Terminals are still inherently single-user, linear, and ephemeral because the terminal-shell interface was built during a time people were using physical teletype terminals. This makes it hard for teams to effectively collaborate on production issues, track what actions people are taking, and recall prior events. The terminal-shell interface, which hasn’t changed since the 80s, needs to be rethought if we want to bring the terminal into the modern age.

At Warp, we’re holistically rethinking how the terminal should work to bring it into the modern age. To start, we’ve built shell integrations into Bash, ZSH, and Fish as an additional interface between the terminal and the shell. This interface allows us to group commands and their outputs together, allowing users to take actions on “blocks” i.e. copy/paste, scrolling, sharing. We currently have integrations for bash, zsh, and fish.

We’ve also: * Replaced the prompt with a full-fledged editor * Added Visual menus for history & tab completions * Built a Command Palette to discover and access all shortcuts See a demo here: https://www.youtube.com/watch?v=X0LzWAVlOC0

Speed is our top priority and so we chose to use Rust and GPU rendering. See our engineering post for how we built Warp, including how we co-built our own UI framework for Rust: https://blog.warp.dev/how-warp-works/

Our terminal model code is based on Alacritty’s model code; we’re grateful that a few of the collaborators reviewed our early design docs. Huge thanks to our collaborators: Atom co-founder Nathan Sobo [1], Nushell co-founder Andres Robalino [2], and Fish shell lead developer Peter Ammon [3]! We hope to open source the client soon.

Ask me anything!

[1] https://github.com/nathansobo [2] https://github.com/andrasio [3] https://github.com/ridiculousfish

Anything beyond straight CLI commands which I can get from a man page is "power user" territory. You're working with a limited market by going after these people.

As I get older, I want less, not more. If I do decide for more, then it's going to be furthering my usage on what has already been available for decades, not the newest shiny thing. Further, I'm going to trust old tools which are still regularly updated over something I would place a significant chance on not being around in 5 years.

Developers make good or bad software regardless of the approach they have taken for the interface. There are CLI's which spark joy and GUI's which I won't waste time on. Will building a better terminal make a CLI better? I suppose it could, but terminal choice has usually been an after-thought for me (usually go straight to Tmux, which fancy terminal programs often screw up.)

Similar to the last point, building the sort of tools which are going to be central to my work is hard. I'm going to use whatever that happens to be regardless of what I feel is my ideal working environment.

For me, the ideal terminal is a modern GUI document, backed by a file, with cut-copy-paste, mouse editing, and an insertion point. Using the "terminal" shouldn't be a weird different mode of interaction.

BBEdit's Worksheet is the closest I've seen to this (and before that, MPW, but now I'm just showing my age). But BBEdit doesn't handle curses, which can be very limiting.

On the contrary, the terminal is experiencing something of a renewal with people suddenly caring enough to try ZSH to the point where MacOS is now pushing it, Fish getting traction, and there was a new BASH release in '19.

On a normal readline terminal like bash you already are basically using a text editor.

The terminal is only on life support if you aren't using it. Adding a command palette won't fix it, targeting Mac-first builds? Forget it, your project is already deader than the terminal it replaces.

It is really cool project. Thanks

I like my terminal as it is and I don't feel the pain outlined in the problem statement. The pain I feel is performance — I need my prompt to be instant; for a while I had to wait ~300ms for each render, which in terminal land is basically a year. For collaboration there's tmux/tmate. The completion examples already exist in my relatively meagre oh-my-zsh setup. The other completion stuff is done with fzf. I generally don't like GUI stuff, and as for "developers work across machines", well, this old Steve Losh gem[0] comes to mind:

> I can count on my balls how many times I've sat down to program at someone else's computer in the last five years. It just never happens.

That said, I think Warp looks great, and there's definitely space in the world for more terminal options. This could be an excellent gateway drug to entice more developers over to using the CLI, which is an obvious positive. Way too many programmers are hampering themselves by not working with the terminal.

[0]: https://www.reddit.com/r/vim/comments/2c3cuu/a_quick_tour_of...