Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things I've learned building a modern TUI Framework (2022)

textualize.io

Post reply on HN
Print view View original

41–50 of 127 posts

Re: Things I've learned building a modern TUI Framework (2022)

#41

Post by kragen »

willm wrote: post #37
kragen wrote: post #34

Earlier quoted context omitted.

this sounds like you're elaborating on why textual wants to be react rather than rebutting the assertion that textual wants to be react. but nobody was saying that wanting to be react was unreasonable hmm, well, i guess traverseda was sort of saying that react was bad. i doubt that's a widely shared opinion tho

I only meant to rebut the factual claims made in the previous comment. Textual is inspired by web development (and I've always described it as such), but "want to be react" is way overblown. It has things in common with React, but equally many other web and UI frameworks. Heck you could say that Textual wants to be JQuery, and that would be just as apt...

maybe it depends on what the implicit reference class is. if you're comparing it to react, angular, ncurses, s-lang, jquery, vue.js, and php, then sure, things like html and css are hardly react-specific. if you're comparing it to ncurses, s-lang, win32, mfc, the vic in the commodore 64, winforms, whiptail, dear imgui, the tms9918 used in the msx, emacs lisp markers and text properties, gtk, the nintendo ppu, opengl and glut, xlib, xt, tcl/tk, ansi.sys, naplps, ripscrip, turbovision, direct access menu.exe, and react, it's basically exactly the same thing as react

jesus, i sure have built shitty user interfaces on a lot of platforms

Re: Things I've learned building a modern TUI Framework (2022)

#42

Post by rojroy »

kragen wrote: post #34
willm wrote: post #16

Earlier quoted context omitted.

> They have a virtual DoM https://textual.textualize.io/api/dom_node/ 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 commo…

this sounds like you're elaborating on why textual wants to be react rather than rebutting the assertion that textual wants to be react. but nobody was saying that wanting to be react was unreasonable hmm, well, i guess traverseda was sort of saying that react was bad. i doubt that's a widely shared opinion tho

[flagged]

Re: Things I've learned building a modern TUI Framework (2022)

#43

Post by rojroy »

rojroy wrote: post #42
kragen wrote: post #34

Earlier quoted context omitted.

this sounds like you're elaborating on why textual wants to be react rather than rebutting the assertion that textual wants to be react. but nobody was saying that wanting to be react was unreasonable hmm, well, i guess traverseda was sort of saying that react was bad. i doubt that's a widely shared opinion tho

[flagged]

[flagged]

Re: Things I've learned building a modern TUI Framework (2022)

#44

Post by itronitron »

traverseda wrote: post #10
itronitron wrote: post #7

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.

Thanks, it seems like people tend to say react, or reactive attributes, when they are describing model-view-controller (MVC) patterns.

Re: Things I've learned building a modern TUI Framework (2022)

#46

Post by yunohn »

willm wrote: post #37
kragen wrote: post #34

Earlier quoted context omitted.

this sounds like you're elaborating on why textual wants to be react rather than rebutting the assertion that textual wants to be react. but nobody was saying that wanting to be react was unreasonable hmm, well, i guess traverseda was sort of saying that react was bad. i doubt that's a widely shared opinion tho

I only meant to rebut the factual claims made in the previous comment. Textual is inspired by web development (and I've always described it as such), but "want to be react" is way overblown. It has things in common with React, but equally many other web and UI frameworks. Heck you could say that Textual wants to be JQuery, and that would be just as apt...

How is it more like jQuery than React?

Re: Things I've learned building a modern TUI Framework (2022)

#47

Post by fastasucan »

mikkelam wrote: post #23

Why do software engineers care so much about TUI? I really don't get it. I love a good command line program. But TUI just doesn't appeal to me.

Its great for running things in a terminal where you want more of a user interface than a CLI. Sometimes a TUI is faster and gives better oversight than a CLI.

Re: Things I've learned building a modern TUI Framework (2022)

#48

Post by actionfromafar »

traverseda wrote: post #4

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…

I want a way to embed a terminal (it doesn't have to support a myriad terminal emulations, only one) inside a graphical program. MacOS first, but other platforms would be nice.

So, imagine a normal GUI window, but one of the components in it is a terminal window. Is there something like that?

Or should I just use mono font text view?

Re: Things I've learned building a modern TUI Framework (2022)

#49

Post by sweeter »

rockorager wrote: post #40
rivo wrote: post #9

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…

The state of the art here is to detect mode 2027, and enable it when supported. This lets you know the terminal will handle graphemes properly. I maintain two TUI libraries which use this technique and emoji support has been (nearly) great. (One of which uses your uniseg library!) https://mitchellh.com/writing/grapheme-clusters-in-terminals

really great read, thanks. Im a little disappointed that no terminal emulator both implements the Kitty image protocol, and mode 2027. I wish there would be a terminal project that would just pick the best standards we have at the moment. Im not a fan of sixel for a lot of reasons. Im looking forward to trying Ghostty, though.

Re: Things I've learned building a modern TUI Framework (2022)

#50

Post by yoavm »

I've used Textual to build a quick Swedish-English dictionary that runs in terminal but also works using touch, when using the laptop as a tablet and on my Android phone. It was a pretty smooth experience and was very fast to get something working. The TCSS layout system thing is a little strange, but only because I automatically expected it to be CSS and obviously that doesn't really work in the terminal.

https://yoavmoshe.com/blog/learning-swedish-with-sway-and-an...

Post reply on HN