<story><title>Textual is a beautiful Terminal User Interface library in Python</title><url>https://textual.textualize.io/</url></story><parent_chain><item><author>billyjobob</author><text>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 &amp;#x27;safe&amp;#x27; 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.&lt;p&gt;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.&lt;p&gt;2. The async nature of the library is unpleasant.  Can never be sure when&amp;#x2F;where your code will run.&lt;p&gt;3. Lots of &amp;#x27;magic&amp;#x27; Python variables and methods that you have to override, but there&amp;#x27;s no way to discover them in your IDE through the type system.&lt;p&gt;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?)&lt;p&gt;5. It seems to leak memory.&lt;p&gt;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.</text></item></parent_chain><comment><author>ttepasse</author><text>&amp;gt; 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?)&lt;p&gt;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:&lt;p&gt;&lt;pre&gt;&lt;code&gt;  @media tty {
    body {
      max-width: 80ch;
    }
  }
&lt;/code&gt;&lt;/pre&gt;
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.&lt;p&gt;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.</text></comment>
<story><title>Textual is a beautiful Terminal User Interface library in Python</title><url>https://textual.textualize.io/</url></story><parent_chain><item><author>billyjobob</author><text>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 &amp;#x27;safe&amp;#x27; 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.&lt;p&gt;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.&lt;p&gt;2. The async nature of the library is unpleasant.  Can never be sure when&amp;#x2F;where your code will run.&lt;p&gt;3. Lots of &amp;#x27;magic&amp;#x27; Python variables and methods that you have to override, but there&amp;#x27;s no way to discover them in your IDE through the type system.&lt;p&gt;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?)&lt;p&gt;5. It seems to leak memory.&lt;p&gt;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.</text></item></parent_chain><comment><author>willm</author><text>When did you try it out? Textual is still at zero-ver but has come a long way recently.&lt;p&gt;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&amp;#x27;ve been building are more like web-apps than desktop apps, which is why we&amp;#x27;ve eschewed the classic menu bar and drop down menus. But I&amp;#x27;d expect to see both in the widget library (&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;textual.textualize.io&amp;#x2F;widget_gallery&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;textual.textualize.io&amp;#x2F;widget_gallery&amp;#x2F;&lt;/a&gt;) soon.&lt;p&gt;I don&amp;#x27;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 &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;textual.textualize.io&amp;#x2F;guide&amp;#x2F;widgets&amp;#x2F;#attributes-down&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;textual.textualize.io&amp;#x2F;guide&amp;#x2F;widgets&amp;#x2F;#attributes-down&lt;/a&gt; No async or await in sight.&lt;p&gt;Re &amp;quot;magic methods&amp;quot;. 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&amp;#x27;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.&lt;p&gt;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.&lt;p&gt;I&amp;#x27;m not aware of Textual ever leaking memory. If there was a memory leak, I&amp;#x27;d make it a priority to fix.&lt;p&gt;Ultimately though, I&amp;#x27;m glad you built your TUI.</text></comment>