11–20 of 127 posts
Interesting that they're hiring. I'm curious how they plan to make money from a TUI framework
I am likely just dense and uncreative, but the truth is, when I switched from DOS to Linux in the 90s, I was never again as productive as I happened to be with B800. Granted, it likely took me a long time to understand the need for double buffering and the difference between a local/direct text mode vs a terminal, let alone escape sequences. But still. Whenever I tried to do something directly in ncurses, I pretty much gave up due to a distinct feeling of being unhappy. Completely different to what I was able to do with the simple ideal of B800.
Anyone old and naiv enough to share this observation: Almost everything I looked at after TurboVision was inspired, but actually not really finished. Once you take the toolkit for a ride, you realize its kind of cute but unfinished. Maybe another way of looking at this is to call many of the TUI frameworks I say "opinionated", whatever that exactly means. I am likely just dense and uncreative, but the truth is, when…
It's funny how every TUI developer eventually stumbles over Unicode and then handling international characters and emojis correctly turns into its own project close to the same scope of (or even bigger than) the original TUI project. It happened to me on rivo/tview and through the resulting rivo/uniseg package, I learned that all other TUI library maintainers deal with the same issues. Finally, everyone invents their…
Earlier quoted context omitted.
Can you elaborate on how textual wants to be like the react framework? I don't see React (or react) mentioned anywhere in the article.
They have a virtual DoM https://textual.textualize.io/api/dom_node/ This includes a lot of what you'd expect from HTML, classes, CSS, etc. They have reactive attributes https://textual.textualize.io/guide/reactivity/ It has HTML (or at least a DoM), css, and you design widgets the same way.
It's not a virtual DOM. It's not technically even a DOM, because there is no Document. The name has stuck, which is why we went with that. Technically, its a tree. One of the most common data structures used to represent a UI, and predates React by decades.
> This includes a lot of what you'd expect from HTML, classes, CSS, etc.
It has CSS in common with HTML. classes are pretty much required for CSS. That's not "a lot". But why shouldn't a UI framework borrow concepts that work for, you know, User Interfaces?
> They have reactive attributes https://textual.textualize.io/guide/reactivity/
Reactives attributes are very useful concept to manage UI complexity. And again, not exclusive to React.
My big complaint with textual is that it wants to be react. I can see why it would want to be react, that's a very popular framework that a lot of people are already familiar with, but I don't think it's actually a good way of doing user interfaces. But the basic reactive design is a well trod road, and basing your system design on something that's known to work is a great way to derisk the project. Sure, we'll draw…
You don't have to use CSS (actually you never did). Every style can be set in code, and the docs have CSS + Python equivalent for every style.
> There are no good standard components
I guess its been a while since you checked https://textual.textualize.io/widget_gallery/
If you care about accessibility even one bit, for the love of god, please, don't use any of the features this post mentions.
Things like animation or unicode diagrams break screen readers in horrible ways.