anarcat/terms-benchmarks

benchmark Electron terminals

Closed this issue · 3 comments

Might be funny to compare to a few electron based terminals:

i deliberately avoided what i consider to be "webapps" in my review, as they require a more complex setup. for example, there's this thing called ajax-term which I considered for a while, but ended up ignoring. there's also anyterm for example.

i'm not a fan of electron apps either: in my mind, they are glorified web apps, and require a runtime much bigger than what i'm willing to tolerate for a terminal.

in the current stats I have, the largest memory-hungry terminal is konsole, at 55MB of ram. that's still almost an order of magnitude less than the single electron app I'm running here, which is currently using 300MB of ram.

in other words, i am worried that adding those to the benchmarks would require me to change the Y scale to be logarithmic, which would be silly.

but if you are ready to actually install and test those, i'd take the results (provided they sync with the other existing results of course).

FWIW, there's also a bunch of "native apps" terminal I haven't looked at yet either, even though I started those benchmarks 6 months ago: termit, kitty and, of course, terminology are the most notable ones.

To be honest, after messing around with all of those (and going through the trouble of actually compiling alacritty), I got tired and lazy and figured I would just use whatever is in Debian. (And yes, terminology is in Debian, but it's not (in) stable, so it got pushed back as well.)

So on top of using only free software, the stuff I'm testing here needs to be packaged in Debian stable. Alacritty is the only exception, as the poster child for "cool new language, GPU-optimized, leet terminal" bunch. ;) Obviously, I'm probably missing a hundred more, but we can't please everyone. ;)

Frankly, I'm not particularly interested in electron apps either. It was more for the lulz. A note in the article indicating

adding those to the benchmarks would require me to change the Y scale to be logarithmic, which would be silly

would be enough to satisfy me ;-)

Thanks for the lenghty explanation.

so basically i won't be doing this myself, but others are welcome to send pull requests. ;) (or discuss the issue here)