I fell for the hype that Textual always gets on HN and actually used it for a mid-sized commercial app a few months ago. I figured it was a 'safe' choice, given all the developers here who seem to like it, and it was the only TUI library I could find with corporate backing. Here are my notes.
1. Considering it has actual paid developers working on it for quite a while and VC funding, it still lacks a great many features that I took for granted in all the non-commercial TUI libraries, e.g. menus and dialog boxes.
2. The async nature of the library is unpleasant. Can never be sure when/where your code will run.
3. Lots of 'magic' Python variables and methods that you have to override, but there's no way to discover them in your IDE through the type system.
4. Using CSS for laying out a TUI app makes no sense (unless you are a web developer and have Stockholm syndrome from using it for web apps?)
5. It seems to leak memory.
Eventually re-wrote the app from scratch using a different library that gets far less hype and spends no time marketing itself. The result was much better in every way.
> 4. Using CSS for laying out a TUI app makes no sense (unless you are a web developer and have Stockholm syndrome from using it for web apps?)
Fun fact: CSS had, since CSS 2.0, the media type ‘tty’, for use in media queries targeting text browsers like links or lynx or such:
@media tty {
body {
max-width: 80ch;
}
}
With the powers of flexbox and grid and a limitation on those new character-based lengths I could imagine an alternative future with TUIs in a CSS layout.
But afaik ‘tty’ has never been implemented and as such never been used. In CSS Media Queries Level 4 all media types outside of ‘all’ and ‘screen’ have been deprecated.
(Also observe the note: “it is expected that all of the media types will also be deprecated in time, as appropriate media features are defined which capture their important differences.” Although features are a technically superior approach, replacing print in this way is never going to be particularly practical or pragmatic. I’m not convinced they’ll ever get to that point, and am confident they will never take the same deprecation route for ‘print’ as they have for the rest, making them never-matching (and ‘all’ and ‘screen’ are certainly not going to get that treatment).)
When did you try it out? Textual is still at zero-ver but has come a long way recently.
You can build menus and dialogs with Textual with a little effort, but you are correct that there is no explicit builtin widgets for those yet. The type of apps we've been building are more like web-apps than desktop apps, which is why we've eschewed the classic menu bar and drop down menus. But I'd expect to see both in the widget library (https://textual.textualize.io/widget_gallery/) soon.
I don't know what you find unpleasant about async. Personally I enjoy async. But you barely need to use async with the current iteration of the API. See this example in the docs https://textual.textualize.io/guide/widgets/#attributes-down No async or await in sight.
Re "magic methods". I guess you mean the message passing system, which uses a naming convention rather than names defined in a base class. This is because you can send arbitrary messages from one widget to another, and if we didn't use a naming convention you would have to implement your own dispatch method anyway. Yeah, the downside is that tooling might not pick up on `on_click` and similar messages but the convention is staightforward enough.
CSS makes a lot of sense to lay out a TUI. You can get a dynamic layout up and running in minutes, and refine the UI by tweaking a few lines. It lets you iterate faster, and separates the logic in your app from the presentation. Similar benefits to the browser.
I'm not aware of Textual ever leaking memory. If there was a memory leak, I'd make it a priority to fix.
Hey Will, thanks for building Textual! I'm using it in a simple side project and really enjoyed using Textual. However, I do feel that the magic methods used in the message passing system and reactive system are questionable, especially in large projects.
You recently renamed the widget "Checkbox" to "Switch" in a newer version. I easily did a rename in my single file app. But imagine that someone built an extremely complicated TUI app containing dozens of files, you can easily miss a rename, which won't be caught by any static checking tools and only result in runtime error.
I had fun building simple apps using Textual, but I probably won't use it to build any complicated TUI apps. I feel that IDE/static checking tools unfriendly magic may directly hurt Textual adoption because it doesn't work with automated tasks like refactoring, and that prevents people from using it in large projects.
Related to #1 you mentioned, to me Textual looks just ugly - like if someone thought it wasn't enough for desktop GUIs to be infested with mobile phone UIs, it also has to be the terminal apps too.
Like, hell, their examples have some *HUGE* buttons, starting with a calculator app that is all buttons - who is going to click on those? The calculator-with-buttons barely makes sense for desktop GUI apps (it was helpful back in the 80s when everyone had a physical calculator on their desk to help see the metaphor of the "virtual desktop" and it is arguably helpful on touch screen devices today for obvious reasons, but on a machine with a keyboard it is superfluous), let alone TUIs.
If you want to see a TUI that actually looks good (though a bit too much on the fancy side, but it doesn't pretend to be something it isn't) check btop:
What coldtea mentioned, the examples in the site you linked look better (well, most of them, some still use these pointless gigantic buttons). And the thing is every time i see the Textual linked here, it isn't with screens/examples like in the site you linked but with screens/examples like in the official site linked above.
From what i see the screenshots in the site you linked at are from programs made by others instead of Textualize themselves, so perhaps they should take a note of how the people who actually use their library and make TUI applications style their programs and redesign theirs accordingly.
>2. The async nature of the library is unpleasant. Can never be sure when/where your code will run.
>3. Lots of 'magic' Python variables and methods that you have to override, but there's no way to discover them in your IDE through the type system ...
Python libs can and do use dunder method overrides, operator overloading, and so on. If it was common to rewrite the AST, or have other action-at-a-distance, I'd give this some credit, but those are still century old PL features, and well specified mechanisms, not something one can't reason about.
Python I find to be (and I'd say most find it to be, hence its popularity on fields like Physics and such, even by non-programmers by trade) one of the easiest languages to read programs in and understand their intent.
Which exacly library, say of the 100 most commonly used ones on Pypi to keep this focused, is particularly problematic?
Exact same experience I had. I would also add that the CSS styling doesn't really work. And it's frustrating because I would prefer if it didn't work all time, but it seems to only not work some of the time and I can't figure out the algorithm of when it doesn't work.
I tried to use urwid too and gave up. Python needs a library as good as ftxui for C++
> unless you are a web developer and have Stockholm syndrome
Reminder that “Stockholm Syndrome” is not only universally invoked as a dismissive, thought-terminating cliché, it was also literally invented out of a whole cloth for just that purpose, as a pretext for dismissing legitimate criticism by a person with significant responsibility for the decision being criticized.
ld: library not found for -liconv
clang-13: error: linker command failed with exit code 1 (use -v to see invocation)
`clang' failed in phase `Linker'. (Exit code: 1
I’m not sure that’s really accurate. I found the API rather unpythonic, with lots of use of magic variables and things.
The only criticisms above that really apply to Python are the async nature, and that’s only because getting async right in Python frameworks and libraries is hard, it is possible though, Django being a great example.
1. Considering it has actual paid developers working on it for quite a while and VC funding, it still lacks a great many features that I took for granted in all the non-commercial TUI libraries, e.g. menus and dialog boxes.
2. The async nature of the library is unpleasant. Can never be sure when/where your code will run.
3. Lots of 'magic' Python variables and methods that you have to override, but there's no way to discover them in your IDE through the type system.
4. Using CSS for laying out a TUI app makes no sense (unless you are a web developer and have Stockholm syndrome from using it for web apps?)
5. It seems to leak memory.
Eventually re-wrote the app from scratch using a different library that gets far less hype and spends no time marketing itself. The result was much better in every way.