This is genuinely incredible but I’m not sure why people keep insisting on making TUIs. User interfaces are nice, of course, but the primary advantage of the terminal is the use of commands and the resulting reproducibility. If you take that away, I’m not sure what the point is over having a GUI. Which to be clear, is not a bad thing, GUIs solve an important problem.
Honestly the biggest difficulty if you’re not using, like, Java or C#, is that your UI choices are CLI stuff or, like, Electron. The cross-platform toolkits are all very bulky unless you decide to write your app in Tcl, the native stuff is not nice, and of course Electron introduces a whole other set of problems.
I think people would not be so hype on TUIs if platform owners had pushed a bit more on the learnings of stuff like React to offer easy ways to build up native applications. Unfortunately the “fun” languages all are pretty lacking/rough on that front.
Or maybe I’m just not good at GUI programming! But it’s not for lack of trying!
I think it is more a matter of culture than of technology, but I often like TUI’s because there is less visual noise and they have a higher information density. If you use the app on a regular basis it is just better to have as much useful information on the screen as possible, because you already know where to look. Mono spaced fonts help with that. It is possible to create interfaces like that with GUI’s too, of course, but no-one seems to do or like it.
This also means that I am not really a fan of frameworks like this that make it easy to create a “pretty” and extravagant TUI with lots of empty space. The retro look is cool, but they are as inefficient as the normal GUI’s. They bring the GUI culture to TUI’s and thus remove the benefits they had for me.
They require much less context switching and enforce keyboard operation and allow copy paste everywhere.
For example I’ve never seen a git exploration app better than tig. Fully keyboard driven. No unnecessary steps. The starting point / mode is selected at startup. I don’t need to think of which elements of the screen are selectable/copyable. I even use it in vscode embeded terminal, because it’s better than the included git lens.
I’m also trying very hard not to start writing an AWS tui - I really want one to exist, exactly because the web (i.e. GUI) one is so annoying to quickly interact with and takes me out of whatever I was actually doing.
I didn’t really consider tig a TUI, but now that I think about it, there’s no actual reason why it’s not. But it clearly is in a different “class” of TUI than those shown in the Textual demos and others like it.
I’m writing one for the Structural Simulation Toolkit to be able to organize information about the many different modules it comes with. A real GUI would be nice but SST is typically installed on a cluster and in my experience X forwarding rarely works. So I think a TUI is a better choice. And that choice looks even better now that Python TUI frameworks exist, as scientific clusters typically have very good Python support these days.
Strongly recommend checking out the tutorial, it’s a really well designed introduction to the capabilities of this framework: https://textual.textualize.io/tutorial/
The stopwatch app from the Textual tutorial starts running for me in less than a quarter of a second - it’s fast enough that I didn’t even notice the delay until I tried to eyeball-measure it just now.
The whole point of TUI apps is that you’re going to spend some time in them. Does a quarter of a second to show the initial screen really matter to anyone? That’s way faster than loading a web application in a browser tab.
Thinking about it, I don’t think I’ve ever used a TUI written in any language where the startup speed has bothered me.
To whoever is starting to write a reply - no, it cannot be optimized.
Python will always take a bit to start the program.
It depends.
Maybe startup time doesn’t really matter for someone’s particular use
case. While there will always be some baseline startup time from
Python, there are cases where you can optimize it and possibly bring it
down to a level you find acceptable.
At a job, I was tasked with figuring out and speeding up slow start of a
Python program. Nobody knew why the bloody thing was taking so long to
start. Part of it was network delays, of course, but part was Python.
I did some profiling.
This little Python program was importing a library, and that library
imported something called pkg_resources. Turns out that pkg_resources
does a bunch of work at import-time (nooo!). After some digging, I
found that pkg_resources was actually an optional dependency of the
library we were using. It did a try … import … except: …, and
could work without this dependency. After digging into the code (both
ours and the library’s), I found that we didn’t need the facilities of
pkg_resources at all.
We didn’t want to uninstall it. Distro packages depended on it, and it
was possible that there were other programs on the system that might use
it. So I hacked up a module importer for our program that raised
ModuleNotFoundError whenever something tried to import pkg_resources.
I cut a nearly one-second start time down to an acceptable 300
milliseconds or so, and IIRC a fair portion of the 300 milliseconds was
from SSH.
Know your dependencies (direct and indirect). Know what you’re calling
(directly and indirectly) and when you’re calling it. Profile. And if
your Python startup times are slow, look for import-time shenanigans.
Program startup speed is important for some applications but negligible compared to other aspects like usability, accessibility or ease of development, wouldn’t you agree?
Program startup speed and performance is an important part of usability. It’s bad for software users when the software they use is full of latency, or uses so many system resources it bogs down their entire computer.
Agreed, it’s part of usability. But it depends on the numbers. Saying “stop writing TUIs in Python” because of 200ms (out of which something can be shaved off with optimization) sounds extreme.
I completely agree with the unsuitability of Python for TUI / CLI projects! (Especially if these tools are short-lived in their execution.)
Long ago (but still using today) I’ve written a simple console editor that has ~3K lines of code (25 Python modules) which imports only 12 core (and built-in) Python modules (without any other dependencies) and mainly uses curses.
On any laptop I’ve tried it (even 10 years old) it starts fast enough. However recently I’ve bought an Android device and tried it under Termux. It’s slow as hell, taking more than a second to start… (Afterwards it’s OK-ish to use.)
What’s the issue? The Python VM is slow to bootstrap and load the code (in my case it’s already in .pyo format, all in a zip with zipapp). For example just calling (on my Lenovo T450) python2 -c True takes ~10ms meanwhile python3.10 -c True takes ~14ms (python3.6 used to take ~20ms). Just adding import json adds another +10ms, meanwhile import curses, argparse, subprocess, json (which is perhaps the minimal any current-day project requires) yields a ~40ms startup.
With this in mind, this startup latency starts to pile-on and it has no solution in sight (except rewriting it in a compiled language).
Granted, even other languages have their issues, like for example Go, which is very eager in initializing any modules you have referenced, even though will never use, and thus easily adds to startup latency.
(I’ll not even touch on the deployment model, where zipapp is almost unused for deployment and https://github.com/indygreg/PyOxidizer is the only project out there trying to really make a difference…)
Why would I? It only has buttons and checkboxes implemented. And according to comments in here is still taking 1/4 of a second to start on a modern CPU.
EDIT: In the demo video, the demo takes 34 frames to boot. At 60fps, that’s more than half a second.
The popularity of a chat app - particularly one that most people use because it’s what their workplace standardizes on - is driven much more by network effects than by the quality of the standard client app. It is bad that the Slack client is slow, and this is made worse by the fact that there aren’t a whole lot of alternative clients for the Slack network that a person who is required to use Slack as part of their job can use instead of the official, slow, one.
I think that the problem with your assessment is the assumption that the users of this framework have the knowledge to use a different language or want to use a different language than python. Nobody is forcing you to use it and if folks are releasing tools using it, nobody is forcing you to use those. For those that want to add a TUI front end to a script they made, this seems like a good option.
This is genuinely incredible but I’m not sure why people keep insisting on making TUIs. User interfaces are nice, of course, but the primary advantage of the terminal is the use of commands and the resulting reproducibility. If you take that away, I’m not sure what the point is over having a GUI. Which to be clear, is not a bad thing, GUIs solve an important problem.
Honestly the biggest difficulty if you’re not using, like, Java or C#, is that your UI choices are CLI stuff or, like, Electron. The cross-platform toolkits are all very bulky unless you decide to write your app in Tcl, the native stuff is not nice, and of course Electron introduces a whole other set of problems.
I think people would not be so hype on TUIs if platform owners had pushed a bit more on the learnings of stuff like React to offer easy ways to build up native applications. Unfortunately the “fun” languages all are pretty lacking/rough on that front.
Or maybe I’m just not good at GUI programming! But it’s not for lack of trying!
I think it is more a matter of culture than of technology, but I often like TUI’s because there is less visual noise and they have a higher information density. If you use the app on a regular basis it is just better to have as much useful information on the screen as possible, because you already know where to look. Mono spaced fonts help with that. It is possible to create interfaces like that with GUI’s too, of course, but no-one seems to do or like it.
This also means that I am not really a fan of frameworks like this that make it easy to create a “pretty” and extravagant TUI with lots of empty space. The retro look is cool, but they are as inefficient as the normal GUI’s. They bring the GUI culture to TUI’s and thus remove the benefits they had for me.
They require much less context switching and enforce keyboard operation and allow copy paste everywhere.
For example I’ve never seen a git exploration app better than tig. Fully keyboard driven. No unnecessary steps. The starting point / mode is selected at startup. I don’t need to think of which elements of the screen are selectable/copyable. I even use it in vscode embeded terminal, because it’s better than the included git lens.
I’m also trying very hard not to start writing an AWS tui - I really want one to exist, exactly because the web (i.e. GUI) one is so annoying to quickly interact with and takes me out of whatever I was actually doing.
I didn’t really consider
tiga TUI, but now that I think about it, there’s no actual reason why it’s not. But it clearly is in a different “class” of TUI than those shown in the Textual demos and others like it.I’m writing one for the Structural Simulation Toolkit to be able to organize information about the many different modules it comes with. A real GUI would be nice but SST is typically installed on a cluster and in my experience X forwarding rarely works. So I think a TUI is a better choice. And that choice looks even better now that Python TUI frameworks exist, as scientific clusters typically have very good Python support these days.
Strongly recommend checking out the tutorial, it’s a really well designed introduction to the capabilities of this framework: https://textual.textualize.io/tutorial/
Please stop releasing TUI frameworks for Python. The language is way too slow and makes these tools a pain to use.
To whoever is starting to write a reply - no, it cannot be optimized. Python will always take a bit to start the program.
I find this comment very surprising.
The stopwatch app from the Textual tutorial starts running for me in less than a quarter of a second - it’s fast enough that I didn’t even notice the delay until I tried to eyeball-measure it just now.
The whole point of TUI apps is that you’re going to spend some time in them. Does a quarter of a second to show the initial screen really matter to anyone? That’s way faster than loading a web application in a browser tab.
Thinking about it, I don’t think I’ve ever used a TUI written in any language where the startup speed has bothered me.
Java/scala usually has a 1-3 second startup time, which is too long for me, but I agree – that’s the only one I can think of.
It depends. Maybe startup time doesn’t really matter for someone’s particular use case. While there will always be some baseline startup time from Python, there are cases where you can optimize it and possibly bring it down to a level you find acceptable.
At a job, I was tasked with figuring out and speeding up slow start of a Python program. Nobody knew why the bloody thing was taking so long to start. Part of it was network delays, of course, but part was Python. I did some profiling.
This little Python program was importing a library, and that library imported something called pkg_resources. Turns out that pkg_resources does a bunch of work at import-time (nooo!). After some digging, I found that pkg_resources was actually an optional dependency of the library we were using. It did a try … import … except: …, and could work without this dependency. After digging into the code (both ours and the library’s), I found that we didn’t need the facilities of pkg_resources at all.
We didn’t want to uninstall it. Distro packages depended on it, and it was possible that there were other programs on the system that might use it. So I hacked up a module importer for our program that raised ModuleNotFoundError whenever something tried to import pkg_resources.
I cut a nearly one-second start time down to an acceptable 300 milliseconds or so, and IIRC a fair portion of the 300 milliseconds was from SSH.
Know your dependencies (direct and indirect). Know what you’re calling (directly and indirectly) and when you’re calling it. Profile. And if your Python startup times are slow, look for import-time shenanigans.
Program startup speed is important for some applications but negligible compared to other aspects like usability, accessibility or ease of development, wouldn’t you agree?
Program startup speed and performance is an important part of usability. It’s bad for software users when the software they use is full of latency, or uses so many system resources it bogs down their entire computer.
Agreed, it’s part of usability. But it depends on the numbers. Saying “stop writing TUIs in Python” because of 200ms (out of which something can be shaved off with optimization) sounds extreme.
I completely agree with the unsuitability of Python for TUI / CLI projects! (Especially if these tools are short-lived in their execution.)
Long ago (but still using today) I’ve written a simple console editor that has ~3K lines of code (25 Python modules) which imports only 12 core (and built-in) Python modules (without any other dependencies) and mainly uses
curses.On any laptop I’ve tried it (even 10 years old) it starts fast enough. However recently I’ve bought an Android device and tried it under Termux. It’s slow as hell, taking more than a second to start… (Afterwards it’s OK-ish to use.)
What’s the issue? The Python VM is slow to bootstrap and load the code (in my case it’s already in
.pyoformat, all in azipwithzipapp). For example just calling (on my Lenovo T450)python2 -c Truetakes ~10ms meanwhilepython3.10 -c Truetakes ~14ms (python3.6used to take ~20ms). Just addingimport jsonadds another +10ms, meanwhileimport curses, argparse, subprocess, json(which is perhaps the minimal any current-day project requires) yields a ~40ms startup.With this in mind, this startup latency starts to pile-on and it has no solution in sight (except rewriting it in a compiled language).
Granted, even other languages have their issues, like for example Go, which is very eager in initializing any modules you have referenced, even though will never use, and thus easily adds to startup latency.
(I’ll not even touch on the deployment model, where
zipappis almost unused for deployment and https://github.com/indygreg/PyOxidizer is the only project out there trying to really make a difference…)Have you tried the framework?
Why would I? It only has buttons and checkboxes implemented. And according to comments in here is still taking 1/4 of a second to start on a modern CPU.
EDIT: In the demo video, the demo takes 34 frames to boot. At 60fps, that’s more than half a second.
I guess it will never be succesful then, like that slow-as-hell Slack thing /s
The popularity of a chat app - particularly one that most people use because it’s what their workplace standardizes on - is driven much more by network effects than by the quality of the standard client app. It is bad that the Slack client is slow, and this is made worse by the fact that there aren’t a whole lot of alternative clients for the Slack network that a person who is required to use Slack as part of their job can use instead of the official, slow, one.
I think that the problem with your assessment is the assumption that the users of this framework have the knowledge to use a different language or want to use a different language than python. Nobody is forcing you to use it and if folks are releasing tools using it, nobody is forcing you to use those. For those that want to add a TUI front end to a script they made, this seems like a good option.
I think Ink is overall a better TUI framework than this, and let’s face it, Python really is slow, JavaScript is much better.
[Comment removed by author]
[Comment removed by author]