I thought that peoples' reactions to electron apps was way overblown, and it certainly comes with benefits, like customizability. So I thought I'd try hyper shell on windows. It was unusable. I expected terminal windows to open right away but there's a really annoying delay every time you open a new one. Really, everything was slow. Maybe it was just my computer. I would definitely prefer to use a less capable terminal that's fast.
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.
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.
Looks... slow. Terminal.app comes pre-installed and has excellent input latency and general responsiveness. Linux and the BSDs have several decent-performing terminal emulators available.
This looks like it's "modern" mostly in the sense of "uses Webtech and has no respect for your system resources".
it may be one of three listed platforms, but this product seems pretty clearly targeted at windows users, so that will not account for anything close to one third of the potential users.
agreed that you were mis quoted, but i don't think they were wrong.
It is true (and I'm not even snarking) that this might be a desirable option on Windows, mostly due to the other options being fairly weak in a variety of ways. I don't know enough about 3rd-party terminal emulators on there to say for sure, but from what I do know I wouldn't rule that out. That's a good point.
Easy pass. I wonder what the reasoning is for creating this, Hi native hosting apps for shell are so small and fast, and have simple dependencies, lets use code base from one of the worlds most complicated and biggest apps with constantly changing code to create a "app" with colors from latest google trends and call it modern.
I agree with you, and I wonder what would take for people to stop having Electron as their first choice when implementing a GUI app. I guess there's no other killer cross-platform library that is as friendly for GUI, maybe?
I currently use iTerm2. Why/when would I consider ditching it with this one?
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.”
The gzipped tar for this is 90MB. It's 265MB unzipped.
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.
I don't think bundle size is a legitimate/relevant criticism of a modern graphical application, unless we're talking double- or triple-digit gigabytes. I have 8000GB in my portable machine.
The overton window of "acceptable program size" has shifted so many times as technology advances, surely you can recognize that your own personal attachments to a given SI suffix are irrelevant?
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.
Just because that window shifts over time doesn't mean that we need to push our boundaries for acceptable program size, nor is it an excuse not to optimize our software. This kind of mindset is how we end up with terminal emulators that take more than 500ms to launch, and how we end up with systems that take on unconscionable amounts of bloat. I use Konsole as my terminal, which is a 50kb binary. If your replacement is orders of magnitude larger than my current option, it had better brew my coffee and have bacon ready by the time I wake up every morning. Instead, all we got was a lousy authy sync.
Konsole is not actually 50kb, you need to include the libraries it imports to do an apples to apples comparison. What is going on here is tabby is the equivalent of statically linked + a virtual machine OS called a browser, while konsole is not. To properly compare the two, you need to compare source code size, as if you downloaded tabby and ran it an browser. To really compare them properly, you'd also need to make the typescript compiled into equivalent JS VM assembly. There you'll find them probably to be significantly closer in size
>Konsole is not actually 50kb, you need to include the libraries it imports to do an apples to apples comparison.
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.
Konsole itself could probably be considered bloated. You can easily write a super functional and performant terminal emulator in 50-100K by only using the external dependencies that are absolutely required - i.e. on Linux, the POSIX/Linux syscall interface and Xlib. You shouldn't even need libc, but AFAIK on Linux it's extremely hard to not use it, for stupid reasons.
> 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.
See, this is what I mean by a legitimate criticism. I agree that a new version of a critical tool like this should do a bit more than have tabs and sync.
This attitude is exactly why Wirth's law is a thing - software is getting slower, faster than hardware is getting faster. That is not in all metrics, of course, but in some - like typically in response latency to user inputs.
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???
Alacrity would like a word. In my experience, software is generally getting faster these days, after a period of UI latencies getting worse for a while.
Not all software is getting slower faster than hardware is getting faster.
It has always been possible to write slow software.
It's funny, while I've never tried Alacritty (and I'm not likely given the posts I'm reading about it around here), I'm still stuck with xterm, which in some ways has a terrible UX. But it's the fastest I've used, has the most correct VT-100 emulation (or at least programs do work), and it has by far the crispest fonts - if you're using bitmap fonts, which most modern terminals don't support anymore.
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 30 of the time. The exception proves the rule (while I feel it's always been so obvious that there was never a proof needed).
Or consider that the startup time of OSes still hasn't changed much. It was much faster for a while when SSDs came around, and Windows generally has become faster with their not-quite-shut-down technique. But normal bootups, around 30-60 secs on normal machines, 25 years ago and still now.
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 seem to 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 use it - sloooow startup. Last I looked I had an issue with tons of virtual serial devices created serially, took probably 10 seconds alone.
> Our ancestors would argue that a 1MB application was bloated.
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.
Their website seems to download a minimal Linux webassembly to provide the demo something to connect to. That probably accounts for most of the perceived slowness of page load and the terminal
I don't get this focus on file size, really. 256 MB is ~0.02% of my current disk space. If the product is fine and the tools the developers choose to build it demand for this space – so it be, I couldn't care less.
Given it won't run on my Raspi. But there can still be value in things that don't run on micro computers.
As I have written elsewhere in this thread: Storage is free, RAM isn't.
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.
"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"
Considering this is a basic tool the assumption isn't completely wrong to have a small footprint. Allowing to have a myriad of tools with each a memory footprint equivalent to Chrome is a recipe to hog all your RAM.
What is this, code golf? Why does it matter in the end? People are allowed to choose, and pooh poohing something just because it doesn't fit your idea of productivity apps isn't very helpful.
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.
My main concern with something like this is the fact that it advertises an "ssh client". I've spent years refining my ~/.ssh/config and integrations with OpenSSH client. I think the best way you can implement a good and compatible ssh experience is by shelling out to OpenSSH, always. Reinventing the wheel usually results in a worse wheel.
Windows tools often vendor in SSH implementations, which can get super annoying if you're trying to just shell out to one and find you're in some other tool's version that they added to the path... which further encourages bundling your own SSH, if you're distributing software to Windows.
This is changing (improving) with recent Windows versions, but you can still totally end up with competing installations by doing fairly normal things.
There seems to be an inverse relationship between how good a project's website looks vs how well the application runs. Probably a "here be Electron" warning sign?
For those on Windows who would rather avoid yet another electron bloatfest, Microsoft’s new “Windows Terminal” app, available through GH and their App Store, is native and extremely good. Not quite on par with iterm2 for Mac, but damn close. (Look it up on GH or search via DDG, on mobile right now so I can’t dig up the link).
IMO it’s a far better alternative for you Windows folks out there.
Windows Terminal is very good. Conemu is another option on windows, also native (not electron) and more featureful.
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.
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.
It's almost inevitable that when something says "for the modern age" it means "built with electron or some other web tech". What would actually be a terminal for the modern age is a native tabbing UI etc wrapped around Alacritty.
"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.
This is an unfair take. The author is being clear that low resource usage is not one of the priorities of the project. (Maybe because he knew the HN crowd was going to go on yet another Electron rant-fest.) They even helpfully link to efficient alternatives.
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.
Seriously? You are going to call the hyperbole in this thread "legitimate criticism"?
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.
>Seriously? You are going to call the hyperbole in this thread "legitimate criticism"?
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.
I get what you are saying. I recently watched this presentation from DevGAMM 2019: https://www.youtube.com/watch?v=pW-SOdj4Kkk. The TLDR is that software is experiencing reverse evolution such that we are regressing in terms of most metrics that we care about (user experience, performance, reliability, etc), most of which I agree with. If what you are trying to build is a low-level portable system utility, then sure Electron is the "wrong" choice. But this feels a lot like the argument around low vs high level languages. Sure, coding in assembly has the potential to be more efficient, but it does not make sense in every (most?) cases. There are valid use case for high-level languages.
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.
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.
Yes! I have used Hyper quite a bit and been happy with it over the years. This feels very similar and I will definitely be giving it a shot. (At first glance it already seems more fully-featured and polished.)
Just to give a point of contrast to the mainly negative comments here: I've been using Tabby for the last three years (it used to be called Terminus) as my daily driver on Windows, mainly with WSL. Coming from terminal.app on OSX, I wanted a terminal with tabs, and at the time (2019) this was the best I could find. It's still a good choice, IMO, and Eugeny does a great job solo-maintaining it.
There seems to be quite the influx of "the shell and terminal emulator, but better" and nobody makes it actually better.
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.
Replying to myself for some sort of nuance: at the same time, just as 'yet another application' it doesn't look bad and it's not unusable... it's just not a replacement for a terminal emulator.
Wow, there is a lot of hate for what is a pretty cool project. Yes, Electron isn’t great, but Tabby (formerly Terminus) is a pretty decent term and is cross platform, which is actually a big deal for me. It allows me to assign “copy on select” and “paste on right click” which, a few years back, many other term apps decided I didn’t want or need anymore. It’s sensible about a bunch of other stuff, and allows me to easily transfer files from within the same terminal. It’s also simple to define jumphosts etc.
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.
Even with all the modern features, I still cannot replace Procomm+ due to the hundreds of aspect scripts I have painstakingly created to setup many devices out of the box. This is for use in a telecom data center.
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.
Hard pass.
reply