I love textualize/rich (and charm)!<p>I think this solves some of the web's browser problems by breaking things out into components:<p>- browsers are way too complicated to build, terminals are way easier<p>- browsers have a huge attack surface, terminals are smaller<p>- browsers lock you into JavaScript (more or less), terminals don't<p>- browsers have to support tons of backwards compatibility (quirks mode, TLS), terminals have less to support by being more circumspect<p>It feels like we're on the beginning of the next cycle a little. First we scattered a bunch of apps to see how we should use the internet, then we focused on the browser, now we're scattering some more apps to see which solves our new problems better.<p>To that end, presuming we stick with terminals, I wonder if they're at risk of falling prey to the same problems, or if they have different potholes in their future. One thing in particular I saw someone else mention in a comment in a different thread is that terminals are almost all written in unsafe languages like C, which feels super bad. Something else is auth and identity--something the current web is pretty bad at.
Looks like a lot of great work went into this.
But I'm not sure I want to see CLI applications continue going down this path. Maybe I'm missing the point of this, but I like my terminal applications simple, small and easy to drop into the rest of the shell ecosystem. This means applictions willing to accept input from either the keyboard interactively or from a stdin input stream of bytes and lines. Output should be a simple, structured, human readable and machine consumable format for easy drop into pipelines and shells scripts.
While these are unarguably cool, I really don’t understand why would we want to force an ungodly hack onto a text-based, letter-displaying protocol to display arbitrary graphics. Especially when the people liking it - I assume - has quite a big intersection with those who prefer simplicity over anything else. Reusing Braille fonts and font styles and whatnot is exceedingly harder than.. putting a pixel onto a framebuffer. Especially when we pair it with event handling and the actually hard part of GUIs, they simply loose out on everything.
Small list of projects using rich/textual: <a href="https://www.textualize.io/textual/gallery" rel="nofollow">https://www.textualize.io/textual/gallery</a><p>><i>we are building technology that lets Textual apps run in a web browser (no code changes required)</i><p>Excited to see how that turns out.
Neat. Now I can run an interpreter in an interpreter to use text based programs like it's 1985, while also paying 2022 prices for the extra 32GB of RAM it needs.
Be nice if the website worked without JS. It doesn't even show images. I appreciate low-tech solutions like TUIs, that should extend to websites. IMO anyway.
OK this is cool and all, and I'm sure it took a lot of effort to build.<p>But I really think that textual interfaces were a mistake. This thing was inherited from Unix which was made in the 70s or so.<p>All screens now are graphical so why are we programming as if the "standard output" is a text file?<p>We should be writing code that writes to a pixel buffer instead of to a file handle.<p>It's 2022 and there's still no good GUI debugger for C on linux.<p>Someone tweeted this a few days ago which I thought really captures why text is a poor UI:<p>> It's 2022 and the two common debugging methods on Linux—"just printf" and "gdb -tui if that's not enough"—still can't be used at the same time without it screwing up.
I love these ideas because i love term... BUT... i really feel like we need variable font sizes in terminals. .. or something, i'm not an expert.<p>I love so many term features but they're at odds with me when i have a larger font size. Suddenly by having my coding text slightly larger i lose screen real estate because all of my borders and widgets are big font characters too.<p>Is there a good way to have bigger primary font with smaller TUI borders/widgets/etc? What would a good way look like?
Can it be used by lisp under Ubuntu, macOS and windows 10? Quite interest in the jupyter. Or similar tool available for lisp.<p>Seems basically python <a href="https://github.com/Textualize/textual" rel="nofollow">https://github.com/Textualize/textual</a> .
Grumpy old-ish fart, here. These fancy, ricer terminal things, whether it be emojis in your $PS1, clueless reinventions of TurboVision, or OpenGL crunch effects when I press a key, but all ultimately emulating a teletypewriter machine from the 1940s are just extremely cringy to me. Emulating one on top of a browser stack probably takes the cake though.<p>We had document/text oriented interfaces in the 80s that were also graphical like in Genera, a lisp machine OS <a href="https://en.wikipedia.org/wiki/Genera_(operating_system)" rel="nofollow">https://en.wikipedia.org/wiki/Genera_(operating_system)</a> This should have been the direction we should have followed. Instead, Unix and X Window systems - the most expensive way to run a teletypewriter - some how won out in the economics of things.<p>I hope the current approach of fancy terminal apps is just a local minimum we can kick ourselves out of in he long term.
Looking at their demo, it seems as though they are focused on mouse interaction in their TUIs. Is this true? If it is, I would not be much of a fan. In a TUI, keyboard must be king, and the mouse only a second-class citizen.