There isn’t anything fundamentally slower about using a GUI vs just text in a console. There’s more to draw but it scales linearly. The drawing things on the screen part isn’t the slow bit for slow programs. Well, it can be if it’s coded inefficiently, but there are plenty of programs with GUIs that are snappy… Like games, which generally draw even more complex things than your average GUI app.
Slow apps are more likely because of an inefficient framework (like running in a web browser with heavy reliance on scripts rather than native code), inefficient algorithms that scale poorly, poor resource use, bad organization that results in doing the same operation more times than necessary, etc.
E.g. From the terminal, I open a known file far more quickly then through an gui. Even if I want to use a gui for the file, issuing the opening command is quicker in the terminal.
GUIs often require the user to scan the interface to find the relevant information as the developer didn’t know what you are actually searching.
With a terminal, the user can be much more precise in what they seeking and consequently, less information is provided and less information needs to be scanned by the user.
The average user doesn’t want to remember and type a specific phrase to do something though. Even if it is “faster” and more “efficient”, the user want to be guided towards the information. The user wants a good user experience, not a fast/efficient one.
Pretty and guided, that is what the average user wants. Modern software is pretty and guided, not efficient and fast. Yes, developer became lazy in optimisation and like to use some big framework to save dev time. But the user also wanted it that way by wanting pretty GUIs because that is easier with the big frameworks.
Ah, that’s efficiency of use and depends more on how familiar you are with the software as well as the design and task. Like editing an image or video is going to be a lot easier with a gui than a command line interface (other than generating slop I guess).
When people talk about how efficient software is, it’s usually referring more to the amount of resources it uses (including time) to run its processes.
Eg an electron app is running a browser that is manipulating and rendering html elements running JavaScript (or other scripts/semi-compiled code). There is an interpreter that needs to process whatever code it is to do the manipulation and then an html renderer to turn that into an image to display on the screen. The interpreter and renderer run as machine code on the CPU, interacting with the window manager and the kernel.
A native app doesn’t bother with the interpreter and html renderer and itself runs as machine code on the CPU and interacts with the window manager and kernel. This saves a bunch of memory, since there isn’t an intermediate html state that needs to be stored, and time by cutting out the interpreter and html render steps.
I know. That is why I started my statement by stating that I don’t like the framing. It treats “efficiency” as the point of software. As the thing, that we should care about when judging software.
But it isn’t. It is user experience. And yes, efficiency is part of that. Both, efficiency in execution and efficiency of use.
And the user experience has improved a lot (ignoring intentional anti patterns to exploit the user that are fairly common, but i think we can agree to ignore that for the sake of the conversation)
Technically true, but there’s a threshold on responsiveness. If both user interfaces respond in milliseconds, it doesn’t matter if one is more efficient
It does because it highlights that instead of being excited to “have to use the terminal” as it is more “efficient” but instead they prefer the “slower” prettier gui. The user want the stupid animations and the flashy nonsense. The user doesn’t want quick software. They want pretty software.
There isn’t anything fundamentally slower about using a GUI vs just text in a console. There’s more to draw but it scales linearly. The drawing things on the screen part isn’t the slow bit for slow programs. Well, it can be if it’s coded inefficiently, but there are plenty of programs with GUIs that are snappy… Like games, which generally draw even more complex things than your average GUI app.
Slow apps are more likely because of an inefficient framework (like running in a web browser with heavy reliance on scripts rather than native code), inefficient algorithms that scale poorly, poor resource use, bad organization that results in doing the same operation more times than necessary, etc.
The terminal is quicker. Not because of the image is drawn more quickly but because it is more efficient to do anything.
Can you elaborate on that? I disagree but would like to understand why you think that. Maybe you’re referring to something I wouldn’t disagree with.
E.g. From the terminal, I open a known file far more quickly then through an gui. Even if I want to use a gui for the file, issuing the opening command is quicker in the terminal.
GUIs often require the user to scan the interface to find the relevant information as the developer didn’t know what you are actually searching.
With a terminal, the user can be much more precise in what they seeking and consequently, less information is provided and less information needs to be scanned by the user.
The average user doesn’t want to remember and type a specific phrase to do something though. Even if it is “faster” and more “efficient”, the user want to be guided towards the information. The user wants a good user experience, not a fast/efficient one.
Pretty and guided, that is what the average user wants. Modern software is pretty and guided, not efficient and fast. Yes, developer became lazy in optimisation and like to use some big framework to save dev time. But the user also wanted it that way by wanting pretty GUIs because that is easier with the big frameworks.
Ah, that’s efficiency of use and depends more on how familiar you are with the software as well as the design and task. Like editing an image or video is going to be a lot easier with a gui than a command line interface (other than generating slop I guess).
When people talk about how efficient software is, it’s usually referring more to the amount of resources it uses (including time) to run its processes.
Eg an electron app is running a browser that is manipulating and rendering html elements running JavaScript (or other scripts/semi-compiled code). There is an interpreter that needs to process whatever code it is to do the manipulation and then an html renderer to turn that into an image to display on the screen. The interpreter and renderer run as machine code on the CPU, interacting with the window manager and the kernel.
A native app doesn’t bother with the interpreter and html renderer and itself runs as machine code on the CPU and interacts with the window manager and kernel. This saves a bunch of memory, since there isn’t an intermediate html state that needs to be stored, and time by cutting out the interpreter and html render steps.
I know. That is why I started my statement by stating that I don’t like the framing. It treats “efficiency” as the point of software. As the thing, that we should care about when judging software.
But it isn’t. It is user experience. And yes, efficiency is part of that. Both, efficiency in execution and efficiency of use.
And the user experience has improved a lot (ignoring intentional anti patterns to exploit the user that are fairly common, but i think we can agree to ignore that for the sake of the conversation)
Technically true, but there’s a threshold on responsiveness. If both user interfaces respond in milliseconds, it doesn’t matter if one is more efficient
It does because it highlights that instead of being excited to “have to use the terminal” as it is more “efficient” but instead they prefer the “slower” prettier gui. The user want the stupid animations and the flashy nonsense. The user doesn’t want quick software. They want pretty software.