Tabby – A Terminal for the Modern Age
tabby.sh
tabby.sh
That's bigger than my kernel, my initramfs, all my terminal emulators, my media player, glibc and the gnu coreutils together, and I'd still have room to spare for some mp3s.
No.
And even if it were, the size of an application in relation to its purpose is a relevant metric.
Our ancestors would argue that a 1MB application was bloated. Our children will complain about 1000GB bundles.
The programs, of course, do vastly different things as the realm of what is possible with technology inexorably advances.
Comparing a complete bundle for an advanced graphical application framework with a TUI application is apples to oranges, and the curmudgeons who are shaking their collective canes at the kids on their lawn are actually technically competent and can recognize this if they choose.
There are legitimate technical criticisms to doing things with JS and Electron and whatnot; but "the bundle is hundreds of megabytes" isn't that.
No, we really don't, because these libraries are available to other programs as well, whereas a huge packaged application is availabe to nothing than itself.
> To really compare them properly, you'd also need to make the typescript compiled into equivalent JS VM assembly.
That's like saying, to compare Usain Bolt and myself in terms of sprinting performance, you should consider the fact that I'm chubby for a fair comparison.
(I know of the suckless community and of st in particular (I've never tried it)).
"It is 250MB" alone isn't.
This slowness costs users so many hairs pulled out. Programmers who think that "this is acceptable" lack the awareness that they haven't even tested the software under only slightly unusual conditions which is when everything is already crawling to a halt.
When that "bundle" is 1000MB while technically there is no reason it should be more than ~1MB, many operations that you might want to do as a developer / trying-outer of the bundle take 1000x longer (no shit). Not unlikely, in some cases that even applies to runtime performance.
Why in the world would you accept that when it takes only a little discipline to get it down to a "reasonable" overhead of say, 10x???
Not all software is getting slower faster than hardware is getting faster.
It has always been possible to write slow software.
But to your actual point, of course you can write software that runs not slower, or even runs much faster, than the software of 30 years ago that ran on machines of the time. The exception proves the rule (while I feel it's always been so obvious that there was never a proof needed).
And the important point is: it _is_ annoying, an actual bootup in 5 seconds is easily possible from a technical perspective, and would much improve the user experience.
Take systemd, I remember it brought a lot of startup time improvements for a while, or at least promised them. I don't follow Linux very much these days, but when I do a standard installation of a popular distro - sloooow startup. Last I looked I had an issue with tons of virtual serial devices created serially, took probably 10 seconds alone.
Parkinson's law at work.
And no one listened, so now -- despite our computers being thousands of times faster -- basic applications are hundreds of times slower to open. And we're junking a bunch of "old" machines that are considered too slow even though they're technically capable of performing rapid operations at levels our brains can barely comprehend.
They still do, thank you very much.
Our children will still complain about a 10MB application, if it does something that could be done by a 500KB solution.
>Comparing a complete bundle for an advanced graphical application framework with a TUI application is apples to oranges,
And what do I need a "advanced graphical application framework" for if the intended use case is displaying text in a grid?
Good for you, I guess. I, myself, have 120GB.
Given it won't run on my Raspi. But there can still be value in things that don't run on micro computers.
And neither is battery power. A terminal application is supposed to be small, and next to invisible in terms of resources required. If it isn't, it will be uninstalled.
According to whom? The terminal gods?
According to wikipedia:
"A terminal emulator, terminal application, or term, is a computer program that emulates a video terminal within some other display architecture. Though typically synonymous with a shell or text terminal, the term terminal covers all remote terminals, including graphical interfaces."
I don't see anything in there about "invisible in terms of resources required"
In that strictest sense of the word, even an RDP client onto a windows desktop is a "terminal".
As the article points out itself however: The colloquial semantic meaning of the word, aka. what is usually meant by it, is TEXT TERMINAL.
And btw.: Even for a fully featured RDP client, I wouldn't accept a size of 200+MB. The one I use at work is barely 4MB.
Your parent isn't forcing anyone to choose the same way as them. They're just advertising facts that inform a buyer when choosing. Your aggression, on the other hand ...
> ... pooh poohing something just because it doesn't fit your idea of productivity apps isn't very helpful.
The way you're pooh poohing your parent's criticism because it doesn't fit your idea of what matters and what not, isn't very helpful.
I'm not in the camp of Electron-haters, you just have to understand what it is and isn't. Nobody (including the author) is advertising Tabby as a lightweight terminal with high-performance GPU acceleration or anything.
And on the flipside, you get a cross-platform terminal app that supports a lot of really handy features like zmodem transfers and an easy interface for port-forwarding and session management.
On the off-chance the author is reading this comment, tmux command-mode integration would be a killer addition to Tabby. It's the one feature that keeps me on iTerm2, and by extension on MacOS. I've never seen the feature on a Windows terminal, and it's a great "this feels like magic" way to have persistent tabs/windows that survive a disconnect.
IMO it’s a far better alternative for you Windows folks out there.
I use Cmder which is a bundling of conemu with clink (provides stuff like tab completion) and git but it's more bloated. Especially in large git directories, opening the terminal can take a few seconds.
Hard pass.
An a very bloated one at that.
My comments below
oh my god, the .tar.gz is 90MB compressed, uncompressed its 265MB. The xterm source code is 7-8MB. We dont need a terminal 33 times the size of a basic terminal.
While I entertain the idea of a terminal in a web browser, I dont believe it has the ability to capture the keyboard entirely for tmux, emacs, etc to work. I also think the use of a web based terminal is quite limited to specific scenarios. Perhaps it would be nice to connect to a k8s cluster on a remote machine.
https://github.com/Eugeny/tabby-clippy :)
Seriously though, I've got a potential use-case where I want to cobble together a few related scripts into an an ad-hoc REPL that supports HTML and image output. A key library I have to use is written in JS.
Granted, this is my first time seeing Tabby so I'm not sure if it will work - just that I might see a use for it.
I agree with your sentiment 100% though - this is way too heavy for a day-to-day shell.
The website has a list of things it can do. What specifically does iTerm2 not do that I need?
Unclear what specific problem this solves. I’d highly recommend making that clear front and center. Otherwise… my response is: “oh, another piece of software someone wrote. Maybe just for fun. That’s nice.”
This looks like it's "modern" mostly in the sense of "uses Webtech and has no respect for your system resources".
Not on most of the devices that can run Tabby.
agreed that you were mis quoted, but i don't think they were wrong.
It was pretty hyped back when it was released, but I was worried about performance and never gave it a shot. I'm using the new Windows terminal now, and even this is sometimes slow. And if the main input mode is text, you don't want slowness.
IMO apps based on browser framework need to die.
> What Tabby is and isn't
Tabby is an alternative to Windows' standard terminal (conhost), PowerShell ISE, PuTTY, macOS Terminal.app and iTerm
Tabby is not a new shell or a MinGW or Cygwin replacement. Neither is it lightweight - if RAM usage is of importance, consider Conemu or Alacritty
This is changing (improving) with recent Windows versions, but you can still totally end up with competing installations by doing fairly normal things.
Edit: damn you autocorrect. However, this is correct https://github.com/Eugeny/tabby/issues/4088
(I know, I need to look at syncthing or some other such tool)
Most of the "upgrades" (since to me, they are not upgrades) revolve around making it pretty or constantly showing irrelevant data or "helpers" on screen.
The downside and upside of a shell is that you need to have a mental map of what you want to do before you can do it. That is not how the current generation seems to approach technology at the foundational level anymore and thus the 'need' for making it pretty and shove potential 'answers' to what you wanted to do in your face is what we get from the 'new' incarnations.
I have no idea if it would actually be better or if it is a discoverability or usability issue, but after learning how to use a shell I personally never found the need for a shell or terminal emulator that does more than accept my commands and show the results. To me, it's almost like it needs to be as close to a system monitor as possible while still allowing high-level interaction with the operating system. Not an 'environment' separate from the system.
It's the same with powershell. I get that it is more of a mini-os inside the os with its own things and data structures passing between commands (which sometimes are actual commands, sometimes are not... and I'm not talking about shell bultins), but if I wanted a REPL I would choose to use a REPL. (but one could argue that a POSIX shell is just as much a REPL shell)
Creating a terminal emulator that 'connects to SSH' is of a similar issue to me. The SSH-client connects to SSH, not the terminal emulator. And the SSH-client runs as a program in the shell in the terminal emulator. You could have some sort of weird GUI-shortcut to open a terminal emulator window or tab, which starts a shell and an SSH-client inside that shell, but what is the point of that if you are going to open a shell anyway? You're essentially adding an extra step (the mouse) where there was none. And now, instead of having the model in your mind where you think "I am going to use an ssh client to connect to an ssh server on a system somewhere" you have the "I click some buttons, fill in a form, and now I am 'on' the other system somehow". The first part is portable as you can swap out the program with another program and your model works, where the second one isn't and you essentially end up remembering waste for every single command that is GUI-fied and you have to think about them in pictures and locations instead of commands and goals.
And now this rant is over before I make it worse.
This is the best newer terminal replacement I have seen in years for quickly opening multiple serial tabbed connections with SFTP and xmodem (still used for backups on legacy devices like my door maglock system and SFTP for recovery flash restore on some embedded devices) If I am not running a setup script, the terminal is much nicer.
Too bad it does not support the legacy VT terminal modes I still require for extreme legacy devices. Telecom does not retire a device still carrying traffic until replacement parts on the second hand market are not available anymore so this is an edge case and not something 98% of people would desire anymore.
Yes, a lot of that can be done in different config files, but in Tabby it is right there, no sweat.
Every now and then the HN comment section reminds why I don’t engage that much anymore in the Open Source community. It used to fun and cool, now it’s all… nasty.
I wouldn't use it for the reasons stated in other comments (quite happy with iTerm), but it's a cool endeavor and reminds me of Hyper.sh.
(their deb install is 13MB, and it's native code using the QT ui framework)
"Tabby is not a new shell or a MinGW or Cygwin replacement. Neither is it lightweight - if RAM usage is of importance, consider Conemu or Alacritty"
Kinda make sense. RAM usage should be of importance to No one. I wonder if it would take Presidential Executive order to get lowlife low RAM people banned from internet.
Sure, not everyone has tons of RAM, but some people do and it is okay to write applications catered to either. E.g. I could use something efficient to write code in like EMACs, but I choose to use the "RAM hog" that is Intellij.
Bundling all legitimate criticism as a "rant-fest" is an unfair take.
Sure, there are legitimate things to criticism Electron for, but it is not very helpful to dog-pile on every project that uses the framework _just for using it._
In this case you have a literal webapp that they also want to bundle as a desktop application. Turns out Electron is the most convenient way to do this.
The overwhelming majority of it? Yes.
>In this case you have a literal webapp that they also want to bundle as a desktop application. Turns out Electron is the most convenient way to do this.
That's just it, though: Developer convenience; at the expense of the user's experience and resources. So many developers digging-in their heels, refusing to use any other GUI framework because they can't be bothered to learn or use anything beyond JavaScript. If that isn't the excuse then it's because an MVP is needed and, because the market is replete with JavaScript developers, Electron was chosen as the platform on which to build. But after the project is green-lit, surely the product will be built using a more performant, lower-weight framework, right? Well, no, because that only benefits the end user.
For open source projects in particular it seems like having a tech-stack that many people are familiar with and like to code, is easy to "hack", and publish to multiple platforms in is a clear benefit.
Edit: And, yes, the performance for the end user suffers because of these concessions to the developer. But in my experience with open source projects, these trade-offs can make the difference between having a viable application and not. I would love efficient, optimized, native apps, but given the choice between an Electron app and nothing, I would rather have the Electron app.