The landing page does a bad job at explaining what it is, same with the first page of the documentation.
I get it from the other comments that it's a terminal multiplexer, and considered an alternative to tmux. But tmux and screen are well established, and should take the opportunity to explain in what way it is different from those.
An endorsement: I freaking love Zellij. I mainly use it like one might use Tmux, to keep remote sessions alive so I can reconnect to them from another host than where I began the session:
* Ssh in to myserver.cloud from my laptop. Run Zellij. Fire off various long-running processes in multiple tabs.
* On my commute home, ssh in from my phone, run `zellij attach`, and check on the status of those processes.
* Once home, ssh in from my desktop, run `zellij attach`, and continue where I left off earlier.
Tmux is nice, but Zellij fits my brain a lot better. Plus, it has a lot of UI affordances to discover features without me having to memorize keystrokes. I use these kinds of tools often enough to care about them, but not so often or in such depth that I'm any kind of a power user. There are certain things I do so rarely in Tmux that I have to look up the manual every single time I do them. With Zellij, I don't have to.
I don't understand the idea to make everything terminal-centric. It should be one component of all the tools available to the programmer.
All text editors worth using have a way to open a terminal for that one time you need it, everything else should be a GUI (with all the advantages that come with it).
Extremes are on both ends. Some people want to use a terminal for all, some don't want a terminal at all.
I'm a terminal guy because most UI I use is just unintuitive and requires a lot of mouse clicking - using mouse is just inconvenient to me. And often there are no tools for what I want to do, or rather, I'd need to open many tools to do something simple like change a file on a remote machine.
But I like a nice IDE, I use DB explorers, I use cloud code to write GUI for data processing and reporting visuals. Terminal is just a "killer app" that's useful for almost everything. So, if you're using regardless, why not make the experience better?
I don't think terminal multiplexers (even Zellij which claims not to be one) make the experience better. They make it worse, actually, because when you have a problem there's one more thing to keep track of: Your terminal emulator, your terminal multiplexer and your TUI.
A decent terminal emulator like kitty solves all of this.
Horses for courses. A decent terminal emulator solves most of it. But I'm guessing there's a reason why there's so many terminal emulators and multiplexers.
Until a few months ago I used to use tmux + foot (tiny terminal), and I enjoyed the setup because I could copy over my tmux config to remote hosts and work as if nothing changed. As I'm mainly working local now, I'm now mostly using Kitty.
> It should be one component of all the tools available to the programmer.
> All text editors worth using have a way to open a terminal for that one time you need it.
Is this not somewhat self-contradictory? Having the terminal in the editor or having the editor in the terminal are both about having one tool that rules the others. The only difference is which one you choose to be the ruler.
For me it's because it's because most things are faster, easier, and don't change (what you learn retains it's value, and doesn't become worthless when the new hotness arrives). So for me it's the other way around; everything should be in the terminal, with a GUI for that one time you need it (`open .` on Mac to open Finder).
TUIs and CLIs are often keyboard centric only use as many resources as it takes to do the task, and then minimal resources to draw the text. Most CLIs also follow the Unix philosophy of doing one thing well, so you can get an output from a CLI and then pipe it into another.
At work I literally use the same workflow at home across two different operating systems because they both share a terminal. I don't even know how to switch workspace on a Mac because I don't need to, tmux sessions fulfil the same task.
>Most CLIs also follow the Unix philosophy of doing one thing well,
basi cli tools yes, but software like the one we're commenting on has a TUI so complex they simply emulate graphical user environments and widgets but on a text rendering stack, akin to web apps pretending to be graphical applications on top of a markup language, except they do it out of necessity because that's how the web works.
If you want to draw graphical user interfaces on an operating system just use the... actual graphics stack. There's terminal apps with widget frameworks now that painstakingly try to reproduce what every OS ships with just because it's.. cool to be a terminal hacker or something?
Because its convenient in a terminal flow to simply hot key through everything without ever touching a mouse. Most GUI programs are inherently mouse driven so if you never touch your mouse they are not very convenient.
It's quite often useful to have multiple tabs or panes in your terminal. Zellij does this. It's a terminal multiplexer, like tmux. Mostly just a bit more beginner-friendly and polished.
Emacs, and as soon as I spawn it, I send the shell process EOF, which is my way of saying, "I'm interested in seeing what you write on your stdout, but have no interest in conducting a dialog with you".
Keyboards are higher bandwidth man-machine interfaces than mouse + GUI unless what you're exchanging is spatial information, which is typically not the case for writing software.
There is a higher learning curve, and we can argue about the tradeoffs you make, but some powerful tools can be difficult to learn to use. Complexity != bad design; sometimes you're just exposing an underlying problem space that can't be simplified without being cut off from part of the solution space.
I use IDEA for most things and barely touch the mouse. It has its problems (like terrible performance), but it's a good example of a GUI done right.
Everything can be controlled through the keyboard, typing into every window does fuzzy search of its contents (and that window might contain a list of code symbols, a list of database tables, a list of search results, or many other things).
Every action can be bound to a key combo of your choice. Every interaction with the GUI can be stored as a macro, edited and replayed.
This 100%. For me, the philosophy is not so much a terminal-centric design but a keyboard-centric design. Sure, this could be done in a GUI, but even GUIs with a keyboard-centric design are not as fluid as a TUI.
I'll also add that (like the parent comment) I did not get the appeal. Not until I forced myself to use it more and saw the benefits.
I didn't understand much of you said but it sounded mathy so I'm going to reply with a counterexample,
just look up on youtube Russ Cox solving AoC with Acme and tell me that's not impressive!
By the way, using a GUI doesn't automatically using the mouse for everything, think of GVim or Emacs. the problem with terminal emulators is the emulating part, where they are forced to comply with the idiotic rules from the '70s.
Most of the time, my need for terminal multiplexers are accommodated by tiling window managers and workspaces. When I do use Zellij, it's when I'm on my laptop and no sockets are nearby. Then I boot onto console and use Zellij for the scroll, split panes, and session management. A replacement for the desktop if you will. Quite handy.
It is if the script is written badly, gets truncated while it's being downloaded, and fails to account for this possibility.
Look into tailscale's installation script, they wrapped everything into a function which is called in the last line — you either download and execute every line, or it does nothing.
Just living far from major datacenters is enough. I get truncated downloads pretty regularly, maybe a couple times a month or so. The network isn't really all that reliable when you consistently use it across the globe.
It usually happens on large files though, due to simple statistics, but given enough users, not hard to imagine it happening with a small script...
This "what if it gets truncated in the middle of the download, and the half-run script does something really bad" objection gets brought up every time "curl | bash" is mentioned, and it always feels like "what if a cosmic ray flips a bit in your memory which makes the kernel erase your hard drive". Like, yes, it could happen in the same way getting killed by a falling asteroid could happen, but I'm not losing sleep over it.
That's quite uncommon. Typically your distribution checks that the downloaded source/binary has the correct checksum and an experienced maintainer checked the (sandboxed) installation. Here someone puts an arbitrary script online that runs with your user's permission and you hope that the web page is not hijacked and some arbitrary dev knows how to write bash scripts.
My dream workspace is a real browser (with all dev tools), with integrated terminal emulator and integrated editor. Editor plugins could be prototyped with web technology and debugged on the fly (like Obsidian plugins). Is there anything like this?
As far as I understand, VSCode browser can't install browser extensions and doesn't even have Dev Tools. For example, IntelliJ IDEs ship with CEF-based browser that has Chromium Dev Tools, but it still doesn't support browser extensions.
I was being a little tongue in cheek, and my "basically" was doing a lot of heavy lifting. VSCode is electron based, so under the hood it's already doing the heavy lifting. It's got a first class editor, first class terminal, first class plugins developed using web tech, very easily and readily debuggable.
It has a browser built in, which is "just" an iframe, and it definitely doesn't function as a full blown web browser, but it does work for previewing your dev work, and given it's a dev tool it makes sense that the experience would be editor+debugger+tools first, with browser as a second class citizen (rather than chrome with an embedded terminal which would be the other way around).
Neat. Any idea how well it runs on the linux console, or fbterm perhaps? Maybe there is a better fbterm by now, remember it being a bit lacking as well.
Is there improved guidance on migrating from tmux to zellij?
I've attempted to move over a few times, and while this is certainly user skill, it just felt too different from screen/tmux. Perhaps I should bite the bullet and force myself to get used to a new paradigm...
For something as simple as a terminal multiplexer, if you aren't seeing immediate value in a switch maybe its fine if you stick with what you have. You don't always need to be on the newest thing. I prefer zellij over tmux, but it is evolutionary not revolutionary. Instead of forcing yourself, save the effort and focus on something more valuable.
It's not an alternative to kitty; it's an alternative to tmux or GNU screen.
I believe it's positioned to be more user-friendly than tmux but I've already got things memorised with tmux and it wasn't bringing anything new to the table, so I didn't try zellij for more than a few days.
I feel the same. If someone would ask me for a recommendation I would point them toward Zellij but if you've been using tmux for years it's probably not worth it.
The landing page does a bad job at explaining what it is, same with the first page of the documentation.
I get it from the other comments that it's a terminal multiplexer, and considered an alternative to tmux. But tmux and screen are well established, and should take the opportunity to explain in what way it is different from those.
An endorsement: I freaking love Zellij. I mainly use it like one might use Tmux, to keep remote sessions alive so I can reconnect to them from another host than where I began the session:
* Ssh in to myserver.cloud from my laptop. Run Zellij. Fire off various long-running processes in multiple tabs.
* On my commute home, ssh in from my phone, run `zellij attach`, and check on the status of those processes.
* Once home, ssh in from my desktop, run `zellij attach`, and continue where I left off earlier.
Tmux is nice, but Zellij fits my brain a lot better. Plus, it has a lot of UI affordances to discover features without me having to memorize keystrokes. I use these kinds of tools often enough to care about them, but not so often or in such depth that I'm any kind of a power user. There are certain things I do so rarely in Tmux that I have to look up the manual every single time I do them. With Zellij, I don't have to.
I don't understand the idea to make everything terminal-centric. It should be one component of all the tools available to the programmer.
All text editors worth using have a way to open a terminal for that one time you need it, everything else should be a GUI (with all the advantages that come with it).
Extremes are on both ends. Some people want to use a terminal for all, some don't want a terminal at all.
I'm a terminal guy because most UI I use is just unintuitive and requires a lot of mouse clicking - using mouse is just inconvenient to me. And often there are no tools for what I want to do, or rather, I'd need to open many tools to do something simple like change a file on a remote machine.
But I like a nice IDE, I use DB explorers, I use cloud code to write GUI for data processing and reporting visuals. Terminal is just a "killer app" that's useful for almost everything. So, if you're using regardless, why not make the experience better?
I don't think terminal multiplexers (even Zellij which claims not to be one) make the experience better. They make it worse, actually, because when you have a problem there's one more thing to keep track of: Your terminal emulator, your terminal multiplexer and your TUI.
A decent terminal emulator like kitty solves all of this.
Horses for courses. A decent terminal emulator solves most of it. But I'm guessing there's a reason why there's so many terminal emulators and multiplexers.
Until a few months ago I used to use tmux + foot (tiny terminal), and I enjoyed the setup because I could copy over my tmux config to remote hosts and work as if nothing changed. As I'm mainly working local now, I'm now mostly using Kitty.
> It should be one component of all the tools available to the programmer.
> All text editors worth using have a way to open a terminal for that one time you need it.
Is this not somewhat self-contradictory? Having the terminal in the editor or having the editor in the terminal are both about having one tool that rules the others. The only difference is which one you choose to be the ruler.
For me it's because it's because most things are faster, easier, and don't change (what you learn retains it's value, and doesn't become worthless when the new hotness arrives). So for me it's the other way around; everything should be in the terminal, with a GUI for that one time you need it (`open .` on Mac to open Finder).
With all the new CLI tools it looks like the opposite to me. For example the ag, ack, rg history.
VS Code still has the same style from 2018.
But... you don't have to use the new tools? The tools that ship with POSIX haven't meaningfully changed since like 2001 and work just fine today.
GUIs are often mouse-centric, resource-hungry.
TUIs and CLIs are often keyboard centric only use as many resources as it takes to do the task, and then minimal resources to draw the text. Most CLIs also follow the Unix philosophy of doing one thing well, so you can get an output from a CLI and then pipe it into another.
At work I literally use the same workflow at home across two different operating systems because they both share a terminal. I don't even know how to switch workspace on a Mac because I don't need to, tmux sessions fulfil the same task.
>Most CLIs also follow the Unix philosophy of doing one thing well,
basi cli tools yes, but software like the one we're commenting on has a TUI so complex they simply emulate graphical user environments and widgets but on a text rendering stack, akin to web apps pretending to be graphical applications on top of a markup language, except they do it out of necessity because that's how the web works.
If you want to draw graphical user interfaces on an operating system just use the... actual graphics stack. There's terminal apps with widget frameworks now that painstakingly try to reproduce what every OS ships with just because it's.. cool to be a terminal hacker or something?
Because its convenient in a terminal flow to simply hot key through everything without ever touching a mouse. Most GUI programs are inherently mouse driven so if you never touch your mouse they are not very convenient.
It's quite often useful to have multiple tabs or panes in your terminal. Zellij does this. It's a terminal multiplexer, like tmux. Mostly just a bit more beginner-friendly and polished.
So obviously it's terminal-centric.
The author's father agrees with you, which is pretty funny.
I don't even use a terminal to run shell commands.
Another fellow GVim user?
Emacs, and as soon as I spawn it, I send the shell process EOF, which is my way of saying, "I'm interested in seeing what you write on your stdout, but have no interest in conducting a dialog with you".
Keyboards are higher bandwidth man-machine interfaces than mouse + GUI unless what you're exchanging is spatial information, which is typically not the case for writing software.
There is a higher learning curve, and we can argue about the tradeoffs you make, but some powerful tools can be difficult to learn to use. Complexity != bad design; sometimes you're just exposing an underlying problem space that can't be simplified without being cut off from part of the solution space.
I use IDEA for most things and barely touch the mouse. It has its problems (like terrible performance), but it's a good example of a GUI done right.
Everything can be controlled through the keyboard, typing into every window does fuzzy search of its contents (and that window might contain a list of code symbols, a list of database tables, a list of search results, or many other things).
Every action can be bound to a key combo of your choice. Every interaction with the GUI can be stored as a macro, edited and replayed.
And so on, and so forth.
This 100%. For me, the philosophy is not so much a terminal-centric design but a keyboard-centric design. Sure, this could be done in a GUI, but even GUIs with a keyboard-centric design are not as fluid as a TUI.
I'll also add that (like the parent comment) I did not get the appeal. Not until I forced myself to use it more and saw the benefits.
I didn't understand much of you said but it sounded mathy so I'm going to reply with a counterexample, just look up on youtube Russ Cox solving AoC with Acme and tell me that's not impressive!
By the way, using a GUI doesn't automatically using the mouse for everything, think of GVim or Emacs. the problem with terminal emulators is the emulating part, where they are forced to comply with the idiotic rules from the '70s.
This is finally a terminal that gets panels and tabs right. Gonna try it without tmux
Most of the time, my need for terminal multiplexers are accommodated by tiling window managers and workspaces. When I do use Zellij, it's when I'm on my laptop and no sockets are nearby. Then I boot onto console and use Zellij for the scroll, split panes, and session management. A replacement for the desktop if you will. Quite handy.
2025 and actual devs are still recommending to type "bash <(curl -L ...)" into a terminal...
If the source is known, it is not less bad that downloading a program and running it
It is if the script is written badly, gets truncated while it's being downloaded, and fails to account for this possibility.
Look into tailscale's installation script, they wrapped everything into a function which is called in the last line — you either download and execute every line, or it does nothing.
Serious question, why or how would a script get truncated when transferred over https?
Just living far from major datacenters is enough. I get truncated downloads pretty regularly, maybe a couple times a month or so. The network isn't really all that reliable when you consistently use it across the globe.
It usually happens on large files though, due to simple statistics, but given enough users, not hard to imagine it happening with a small script...
You pull the Ethernet cable out before it finishes. Or your wifi router hiccups
Wouldn’t the download terminate without emitting the script?
This "what if it gets truncated in the middle of the download, and the half-run script does something really bad" objection gets brought up every time "curl | bash" is mentioned, and it always feels like "what if a cosmic ray flips a bit in your memory which makes the kernel erase your hard drive". Like, yes, it could happen in the same way getting killed by a falling asteroid could happen, but I'm not losing sleep over it.
That's quite uncommon. Typically your distribution checks that the downloaded source/binary has the correct checksum and an experienced maintainer checked the (sandboxed) installation. Here someone puts an arbitrary script online that runs with your user's permission and you hope that the web page is not hijacked and some arbitrary dev knows how to write bash scripts.
It's just assumed you'll run it in an isolated container, or some other sandbox...
My dream workspace is a real browser (with all dev tools), with integrated terminal emulator and integrated editor. Editor plugins could be prototyped with web technology and debugged on the fly (like Obsidian plugins). Is there anything like this?
You’ve basically described vscode!
As far as I understand, VSCode browser can't install browser extensions and doesn't even have Dev Tools. For example, IntelliJ IDEs ship with CEF-based browser that has Chromium Dev Tools, but it still doesn't support browser extensions.
I was being a little tongue in cheek, and my "basically" was doing a lot of heavy lifting. VSCode is electron based, so under the hood it's already doing the heavy lifting. It's got a first class editor, first class terminal, first class plugins developed using web tech, very easily and readily debuggable.
It has a browser built in, which is "just" an iframe, and it definitely doesn't function as a full blown web browser, but it does work for previewing your dev work, and given it's a dev tool it makes sense that the experience would be editor+debugger+tools first, with browser as a second class citizen (rather than chrome with an embedded terminal which would be the other way around).
Instead you can use https://github.com/coder/code-server, which is really vscode running in your browser. You then get all extensions, etc.
I built a project to add a terminal emulator to the browser (using a chrome extension): https://github.com/pomdtr/tweety.
I'm working on a `tweety edit` command which open arbitrary files in your $EDITOR of choice in a new tab.
Looks great, I'll give it a try!
I like Zellij, but one point of friction I ran into was it not loading profile configurations like .zprofile. https://github.com/zellij-org/zellij/issues/1434
Neat. Any idea how well it runs on the linux console, or fbterm perhaps? Maybe there is a better fbterm by now, remember it being a bit lacking as well.
Is there improved guidance on migrating from tmux to zellij?
I've attempted to move over a few times, and while this is certainly user skill, it just felt too different from screen/tmux. Perhaps I should bite the bullet and force myself to get used to a new paradigm...
For something as simple as a terminal multiplexer, if you aren't seeing immediate value in a switch maybe its fine if you stick with what you have. You don't always need to be on the newest thing. I prefer zellij over tmux, but it is evolutionary not revolutionary. Instead of forcing yourself, save the effort and focus on something more valuable.
i've switched over and really enjoy it. i feel like it's largely self documenting, what are your biggest hurdles?
I'm a terminal person and would love to try new things. But I just spent a few minutes on their page and have no idea why I would try to use it.
Can anyone help me learn why this over, say, kitty?
It's not an alternative to kitty; it's an alternative to tmux or GNU screen.
I believe it's positioned to be more user-friendly than tmux but I've already got things memorised with tmux and it wasn't bringing anything new to the table, so I didn't try zellij for more than a few days.
I feel the same. If someone would ask me for a recommendation I would point them toward Zellij but if you've been using tmux for years it's probably not worth it.
The modal nature of Zellij is nice though.
I like tmux better as well (muscle memory) but AFAIK you need tmuxinator for preconfiguring layouts?
You need a session manager like tmuxinator, tmuxp and tmux-sessionx are popular choices.
Does it support sending and executing commands to the panes like tmux does?
like this:
tmux send-keys -t 0:1.1 "ls" Enter
edit: well, yes, you can:
zellij action write-chars ls
zellij action write 10
Ha! I've been using tmux for years and I didn't realize one could do this.
Fwiw lots of submissions over the years. I thought there was one a couple weeks ago but not seeing it. https://hn.algolia.com/?q=zellij