That’s the state of computing in 2023: a browser disguised as a native app running 15 layers of Javascript is used as a friggin terminal. And nobody bats an eyelids, as if the utter insanity of it made any sense.
And the installer is 117M compressed. That’s MEGABYTES… For a terminal!
I’ve been using Alacritty for the last 4 years, it’s kinda the opposite of this nonsense. It’s written in Rust, it’s super light weight, highly optimised, and uses hardware acceleration to render the terminal. It’s top of the chart for every terminal performance benchmark conceived.
However, that lightness and fastness comes at a cost. There are some basic features they just won’t add because they’re outside the scope of the project. Eg, tabs (“just use a tiling wm and do your own tabs in the wm”) or a scrollbar (“just use a shell with a scrolling screen buffer like Tmux”), or different coloured backgrounds for each opened window (“why would anyone ever want to do that?”).
My holy grail terminal would be something like Alacritty, written in Rust, blisteringly fast and light weight, but with tabs, scrollbar, bookmarks, etc.
I find myself falling back to using Konsole a lot these days, it’s got all the features I want, is fast enough, and already installed on every system I use Plasma on.
I never understand the whole thing around “fast” terminals. How can a terminal be “slow”? Surely the terminal you’re using has no effect on the programs you’re calling, so what’s being measured here?
I get what you mean, it is an interesting question to explore.
For me, it think it appeals to my obsessive engineer-brain, I am hooked on chasing efficiency.
Eg, if one tool uses 10MB ram and takes 1second to complete a task, and another tool takes 50MB ram and 5 seconds to complete the same task, then clearly I want to use the more efficient one. The other must be wasting resources, right?
When it comes to real life software and real tasks, it is a lot more complicated than that, there are hundreds of variables to take into account and compare. But if one tool stands out among the others, optimising to achieve the best number (fastest time, lowest power draw, lowest ram use, etc) in each comparable variable, then I absolutely must use that one, it would be irresponsible not to, right?
Throw hardware acceleration into the mix, and it takes the situation to a new level. Why make my poor CPU render the text on the screen 60 times per second, when I can get the GPU to do it? It’s just sitting there doing nothing, and it’s better at the job anyway, and as a bonus you get even lower CPU utilisation and lower ram usage.
However, as I described in my previous post, chasing these numbers can come at the cost of usability. That’s the case with Alacritty, and why I will be switching to wezterm.
Wow, just had a look at the Wezterm GitHub page, read the features and the docs. I think you’re right, it does look like it will replace Alacritty for me.
For anyone else wondering about the differences between Alacritty and wezterm, or still on the fence, read this thread, particularly the comment from wez: https://github.com/wez/wezterm/discussions/1769
I am using Konsole currently, as it works best in KDE. Should I switch to Alacritty? I like to have one window and the rest in tabs, its pretty great. I guess alacritty doesnt have that right? What all does fit in the config? Konsole has tabs with special descriptors using path, host, program etc. You can change the color scheme, its pretty nice.
I swear. I quit using iTerm and moved to Kitty because it was too inefficient and was eating up my battery on the go. There are so many apps that are just diguised browsers that eat too much memory and processing power and they make needing a powerful machine a requirement if you want to have multiple apps open. It’s getting to a ridiculous point and it’s inconvenient.
I don’t understand why desktop JS apps don’t use React Native at least. It’s still JavaScript but doesn’t use a browser, and renders to native UI widgets. Far lighter than Electron.
Well with react native you still have to deal with the native problem which a developer doesn’t want to deal with, you know… You could… But if they really cared about making the app efficient and well they would have had a different decision making process… People nowadays don’t really just the right tool for the job, they just have a tool and try to turn it in a universal hammer and solve everything with it
The disadvantage with React Native is that you still have to maintain a UI for each platform because it maps to native widgets while a web UI works the same on every platform.
Business/application logic can be 80-90% of an app’s code, and all of it can be reused across platforms. The actual UI rendering is just a small part of it.
In the UI code, some of it does have to differ across platforms but it’s mostly the lower level components like buttons, text fields, etc. Some product UI code built on top of those abstractions can be reused across platforms.
Sure, but it’s still more work than a web UI, and using a web UI is a lot more flexible. For example, say you want to render a chart or some other visualization. It’s trivial to do with a web UI, but can be a tricky problem with native widgets, especially if you want to keep the UX consistent across platforms. I agree that using React Native can work fine in a lot of cases, but I can also understand the appeal of using the web UI stack. Another aspect is likely familiarity, people use the tools they know, and if somebody is already comfortable with a particular ecosystem they’re likely to leverage it.
Exactly, your program using the minimum of RAM allows more for other programs to run and gives more memory for the OS to cache literally anything that isnt their web app, likely the filesystem, and that is a much better use of the RAM then letting electron or some such eat it all.
The only stupid part is bundling a whole browser for a webpage. HTML5 as an executable format is fantastic - all the bullshit Java promised, except people actually use it. But for some godforsaken reason, everybody ships a platform-specific… portable OS… with every single program.
Electron and whatnot have turned “Java but good” into “Docker but awful.”
That’s the state of computing in 2023: a browser disguised as a native app running 15 layers of Javascript is used as a friggin terminal. And nobody bats an eyelids, as if the utter insanity of it made any sense.
And the installer is 117M compressed. That’s MEGABYTES… For a terminal!
The mind boggles…
I’ve been using Alacritty for the last 4 years, it’s kinda the opposite of this nonsense. It’s written in Rust, it’s super light weight, highly optimised, and uses hardware acceleration to render the terminal. It’s top of the chart for every terminal performance benchmark conceived.
However, that lightness and fastness comes at a cost. There are some basic features they just won’t add because they’re outside the scope of the project. Eg, tabs (“just use a tiling wm and do your own tabs in the wm”) or a scrollbar (“just use a shell with a scrolling screen buffer like Tmux”), or different coloured backgrounds for each opened window (“why would anyone ever want to do that?”).
My holy grail terminal would be something like Alacritty, written in Rust, blisteringly fast and light weight, but with tabs, scrollbar, bookmarks, etc.
I find myself falling back to using Konsole a lot these days, it’s got all the features I want, is fast enough, and already installed on every system I use Plasma on.
I never understand the whole thing around “fast” terminals. How can a terminal be “slow”? Surely the terminal you’re using has no effect on the programs you’re calling, so what’s being measured here?
I get what you mean, it is an interesting question to explore.
For me, it think it appeals to my obsessive engineer-brain, I am hooked on chasing efficiency.
Eg, if one tool uses 10MB ram and takes 1second to complete a task, and another tool takes 50MB ram and 5 seconds to complete the same task, then clearly I want to use the more efficient one. The other must be wasting resources, right?
When it comes to real life software and real tasks, it is a lot more complicated than that, there are hundreds of variables to take into account and compare. But if one tool stands out among the others, optimising to achieve the best number (fastest time, lowest power draw, lowest ram use, etc) in each comparable variable, then I absolutely must use that one, it would be irresponsible not to, right?
Throw hardware acceleration into the mix, and it takes the situation to a new level. Why make my poor CPU render the text on the screen 60 times per second, when I can get the GPU to do it? It’s just sitting there doing nothing, and it’s better at the job anyway, and as a bonus you get even lower CPU utilisation and lower ram usage.
However, as I described in my previous post, chasing these numbers can come at the cost of usability. That’s the case with Alacritty, and why I will be switching to wezterm.
The very few times your programs end up spamming a ton to stdout I guess
Konsole is my second favorite terminal app. Wezterm may be your holy grail.
Wow, just had a look at the Wezterm GitHub page, read the features and the docs. I think you’re right, it does look like it will replace Alacritty for me.
For anyone else wondering about the differences between Alacritty and wezterm, or still on the fence, read this thread, particularly the comment from wez: https://github.com/wez/wezterm/discussions/1769
Give tmux or emacs a try. Or just use Kitty.
I am using Konsole currently, as it works best in KDE. Should I switch to Alacritty? I like to have one window and the rest in tabs, its pretty great. I guess alacritty doesnt have that right? What all does fit in the config? Konsole has tabs with special descriptors using path, host, program etc. You can change the color scheme, its pretty nice.
If you’re happy with your tools just keep using them.
I like using kitty personally. I mostly chose it because of the cute name but it does everything I need.
I swear. I quit using iTerm and moved to Kitty because it was too inefficient and was eating up my battery on the go. There are so many apps that are just diguised browsers that eat too much memory and processing power and they make needing a powerful machine a requirement if you want to have multiple apps open. It’s getting to a ridiculous point and it’s inconvenient.
I don’t understand why desktop JS apps don’t use React Native at least. It’s still JavaScript but doesn’t use a browser, and renders to native UI widgets. Far lighter than Electron.
Well with react native you still have to deal with the native problem which a developer doesn’t want to deal with, you know… You could… But if they really cared about making the app efficient and well they would have had a different decision making process… People nowadays don’t really just the right tool for the job, they just have a tool and try to turn it in a universal hammer and solve everything with it
The disadvantage with React Native is that you still have to maintain a UI for each platform because it maps to native widgets while a web UI works the same on every platform.
Business/application logic can be 80-90% of an app’s code, and all of it can be reused across platforms. The actual UI rendering is just a small part of it.
In the UI code, some of it does have to differ across platforms but it’s mostly the lower level components like buttons, text fields, etc. Some product UI code built on top of those abstractions can be reused across platforms.
Sure, but it’s still more work than a web UI, and using a web UI is a lot more flexible. For example, say you want to render a chart or some other visualization. It’s trivial to do with a web UI, but can be a tricky problem with native widgets, especially if you want to keep the UX consistent across platforms. I agree that using React Native can work fine in a lot of cases, but I can also understand the appeal of using the web UI stack. Another aspect is likely familiarity, people use the tools they know, and if somebody is already comfortable with a particular ecosystem they’re likely to leverage it.
deleted by creator
Oh that one pisses me off so much… they act like its the only damn thing i have open.
Exactly, your program using the minimum of RAM allows more for other programs to run and gives more memory for the OS to cache literally anything that isnt their web app, likely the filesystem, and that is a much better use of the RAM then letting electron or some such eat it all.
Except it’s not: free ram is where disk cache lives, so the more free ram you have - the faster your system is (kinda)
The only stupid part is bundling a whole browser for a webpage. HTML5 as an executable format is fantastic - all the bullshit Java promised, except people actually use it. But for some godforsaken reason, everybody ships a platform-specific… portable OS… with every single program.
Electron and whatnot have turned “Java but good” into “Docker but awful.”