Textualize – A framework for building Text User Interface applications
textualize.io
textualize.io
I think this solves some of the web's browser problems by breaking things out into components:
- browsers are way too complicated to build, terminals are way easier
- browsers have a huge attack surface, terminals are smaller
- browsers lock you into JavaScript (more or less), terminals don't
- browsers have to support tons of backwards compatibility (quirks mode, TLS), terminals have less to support by being more circumspect
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.
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.
> ...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...
Is something that i also have been thinking about myself. I'm seeing the popularity - maybe resurgence - of text based web browsers as well as the Gemini protocol and associated Gopher sites (Capsules i think they're called?) really rise a bunch lately. I'll add that the prevalence of many devs/techies to implement ad blockers, maybe tweak their browsers to avoid running javascript, etc...to represent some shift towards more minimal interfaces for accomplishing their needs. And, simply blanket re-using of old interfaces (some decades old) without some adjustment might not scale to current-day needs in some cases. I myself look forward to these types of TUI experiments (including taking old text-based interfaces and evolving them for nowadays), as i'm optimistic some will stick around.
I think one of the bigger barriers is that terminals don't really have a component reuse boundary.
What I mean by that is: in the browser, you can always put more HTML inside a div tag, and generally speaking, it's gonna stay within the boundaries of that div tag, and things will compose and it won't be a fuss. In the terminal: what's the equivalent of that?
It's possible, and yet not actually remotely pleasant, to make a new PTY/TTY for each component (or each small application that you want to embed within another), and then grab the state of that PTY and replicate it into a rectangular region in another PTY that's bigger. There's so, so, SO much friction in this, though. It also only solves the view bounding: it doesn't solve, for example, the ability to have a copy/paste operation that works on the interior content in a standard way (instead each terminal application solves that itself, usually with some unique bespoke shortcut sequence, because you need _application logic_ to find text ranges since what's rendered to a terminal vs what the logical text state is are usually different).
I think if someone created some very basic component-oriented UI system to solve the composition problem -- then kept most of the components as roughly PTY/TTY and TUI concepts! -- it could lead to interesting places that PTY stuff will have difficulty getting to alone.
Protocol: https://github.com/rendicott/uggly
Client with gif demo: https://github.com/rendicott/uggly-client
If you're on the hunt for one that isn't, check out wezterm, it's delightfully good.
I think most terminal emulator developers would dispute this -- there's a lot of complex legacy behavior in TTY/PTY handling, in supporting various escape sequences, being behavior-compatible with dominant emulators like XTerm, etc. Most of it is also "esoteric" in a way that backwards compatibility on the web isn't, since very little is actually standardized (the only pieces I can think of are POSIX for some parts of the PTY layer and X3.64 for some terminal control sequences).
I don't mean to insult what you've done, but accessiblity is (in my experience) one of those things which is really hard to add retroactively to systems.
I just built a new app (https://lists.sh — launching tomorrow) which leverages the charm toolset. It was a ton of fun to build and I think the workflow for publishing blog posts is more convenient than virtually every other blog platform I’ve tried.
At that point I think you're about as safe as "Generic PHP Web App" - I'm sure I've missed something, but that's where I'd start looking.
That said I don’t think the point of this is to replace sed, or other unix-y tools where you’re having pipeline-oriented programs. It’s full blown apps inside of the terminal that might otherwise be in the browser or in a GUI. Something where you’re seeing things update or otherwise interacting such that you could never grab it’s out for a shell script nor would want to.. like running a REPL or top.
What I want is terminal apps that seamlessly integrate with all the standard conventions of the terminal. Your example of history is a great one. Another is, wherever possible enabling things like vi-style navigation, minimal need to move your hands off the home row, seamless integration with command line tools (implementing a search function - don't! let me pipe it through my own one, eg: grep).
As soon as I have to hit function keys, manually navigate to control UI elements etc. it's just a really bad recreation of what we already have in the browser.
That sounds like a you problem
I don't see a products section on their site yet, but they refer in several places to what they are making as products, so I'm assuming they may want to market them to me in the future.
But seriously, I'm the same, Python is a problem because it is such a great local optimum for this kind of thing - and yet a terrible global optimum. Ten years ago it made sense but now it is actively in the way of better alternatives, of which there are now plenty, gaining traction.
haters > /dev/null>we are building technology that lets Textual apps run in a web browser (no code changes required)
Excited to see how that turns out.
so close, and yet so far away!
One view of things is that means the Textualize developers were probably web developers and they wished Text UI programming was similar.
The most mainstream Graphical UI on desktop that allows using CSS for layout is Electron which is basically an entire Chromium browser running a single web application with HTML, CSS, and Javascript heavily involved.
Therefore, one potential "end-game" for Textualize is to add enough features that it becomes a browser itself or to be supplanted by Electron adding Text UI support.
There's enough UI real state for everyone.
(It's an impressive achievement on a technical level, sure. But that's orthogonal to whether it's useful, and for practical purposes it's not. "Any tty will do" is a good thing.)
> It will run just on just about any terminal on any OS.
It's not hard to imagine it being rigorously tested on several platforms with modern CI tools. It's borderline disrespectful for you to immediately assume that the author has only ever tested it the specific terminal(s) he happens to develop in.
I have a difficult time imagining what a test suite looks like that can exercise all the relevant test cases in, and correctly evaluate the output of, terminal emulators across all OSes. So to me, this statement probably means "we tried a few sample scripts in VMware at some point."
To be clear, I realize I'm asking a good deal here, but I'm being asked a good deal here too. If I'm to consider building a production application on this or any platform, I need considerable confidence that that platform isn't flawed in ways that may prove to mean I'll have wasted what might be a great deal of work. And if I'm going to have to design against the assumption I may need to have the application still work even when the platform doesn't, why use that platform at all?
> It's not hard to imagine it being rigorously tested on several platforms with modern CI tools.
It's not hard to imagine a lot of things! But when I looked at the repository earlier [1], I saw a very thin unit test suite that hasn't been touched in eight months, and very little evidence of CI in use at all - and, of course, what checks there are can only exercise the apparently small subset of logic that the unit tests cover. Certainly, if there's anything examining actual behavior in any terminal environment, I saw no sign of it.
Perhaps you'll be able to point me to what I missed. Assuming I didn't, though - for a UI framework that seems designed to have me build my entire application on top of it, this doesn't really inspire a great deal of confidence. As I mentioned above, the risk is that if it turns out to support many fewer terminals than claimed, I'm forced to choose between at minimum significant and potentially near-total rework, or telling those of my users who have terminal-related trouble that I can't spare the time to support them.
If this were a pure open source project, I wouldn't raise this issue in this way. (I'd more likely spend some time looking at how I might build the basis of a CI setup like the one I describe - that might be a fun project, assuming I could find the focus time to spend!) But Textualize appears to be a company which is currently hiring, and which I assume intends at some point to sell some product or service. I think that makes it fair to apply a similar standard here to the sort I use when vetting any vendor. What would you have me do instead? Use kid gloves, and implicitly insult the team behind this project with the assumption that they can't fairly be expected to live up to a standard like that?
I grant they're an early-stage startup, maybe still a one-man band at this point, and likely haven't had time to get to the kind of detailed testing I'm asking about. That's fair, but that also leads one to suggest that the claims being made at this stage are somewhat ahead of what can reasonably be supported. I'd be a little hesitant about that personally, but then again it's not my company, my product, or my project.
I agree with your point that it's easy to write CLI software that relies on features not all terminals have, but it's almost equally easy to write simple and portable software and test it in the most used terminals.
From my perspective, I've used Rich in one of the very few contexts that practically matter (a terminal on macOS) and had a good experience. Will M. has been developing it in the open for a couple of years now and it's nearing critical mass in some parts of the Python ecosystem. If it was a diaper turned into a Molotov cocktail, it simply wouldn't the adoption it has so far. It probably runs fine on the three major operating systems of today, which is pretty much what a TUI needs to do. I have no idea if it runs smoothly on a Commodore 64 and to be honest I don't really care.
> Perhaps you'll be able to point me to what I missed.
You could have a look at Rich itself, which is what Textualize uses: https://github.com/Textualize/rich. I don't build UIs but the number of files/LOC gives me a bit more confidence that my personal experience wasn't a fluke.
> If this were a pure open source project,
What's a "pure" open source project in your view? You can review the licenses of the projects yourself and determine if MIT is "pure" open source, or see what the company says about their plans with the project: https://www.textualize.io/what-we-do
> Rich, Textual, and many of our future projects will continue to be built in public, with an Open-source license.
The xterm control sequences are well documented (https://www.x.org/docs/xterm/ctlseqs.pdf) and we’re using a very minimal subset. The only codes we’re using beyond setting colour and style are those that move the cursor. Compatibility is likely to be the same as any TUI built in the last couple of decades. I haven’t found a single terminal emulator were it doesn’t work, and I’ve tried as many as I can download for the Mac, Linux, and Windows.
Perhaps you’ve assumed we’re doing something particularly exotic with terminals, but it’s honestly not doing anything that any curses app doesn’t do.
You might find a really old terminal emulator where it struggles, but it would be the exception and not the rule.
That said, if your terminal support is as good as advertised, it probably shouldn't be hard to surface that on your site. (If you really want to sell me on it, let me try it out in a web-based terminal emulator like xterm.js! Then let me package up that test script for download, so I can easily run it locally in my terminal, as many of them as I like, and see for myself how well it works there.) Maybe also include feature coverage in your test suite and even CI, although that's definitely a trickier engineering problem.
As it is, I'd be very hesitant to use the library since doing so would risk incurring a dependency (on the user using a supported terminal) that wouldn't be easy to characterize more closely than "I tried this in xterm, y, and z and it worked, but if it breaks for you I'll have no immediate idea of why, and I'll have to choose between #wontfix and losing velocity on feature work."
Also since the project is based on rich from the same author, some of the terminal features are from rich and the test coverage on that is 99% [3].
[1]: https://xtermjs.org/#real-world-uses
[2]: https://github.com/Textualize/textual#textual:~:text=Current....
Thanks for the steer!
However, 10MB is still enough to run Windows 3.1 with room to spare for a program or two.
For comparison, XTerm uses around 2.5MB, and that's a relatively bloated and crufty piece of software.
But I really think that textual interfaces were a mistake. This thing was inherited from Unix which was made in the 70s or so.
All screens now are graphical so why are we programming as if the "standard output" is a text file?
We should be writing code that writes to a pixel buffer instead of to a file handle.
It's 2022 and there's still no good GUI debugger for C on linux.
Someone tweeted this a few days ago which I thought really captures why text is a poor UI:
> 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.
We rolled out the PCs and updated software and salespeople’s and CSRs’ productivity was killed. They could fill in the screens on the old system before it finished painting.
The new one had the same “screens”, but flipping to the mouse and back was awful. A year later the vendor finally got everything straight with the keyboard (tab order, hot keys, etc). But it still took longer to render and blocked input and was generally awkward.
I set them up with telnet on their PCs back to the VAX. New folks found the GUI easier, but experienced users still hated it.
Eventually the vendor required moving the DB off the VAX and the TUI was dead.
I had started building web UIs by then. Thick clients were already becoming passé. But that experience really has stuck with me.
The tech you use doesn’t actually matter at all. Enabling people to work faster, better, easier is what matters.
Sometimes a short-term but steeper learning curve is better in the long run. Sometimes ease of adoption is more important. And sometimes the tech doesn’t change the fact that a tool just sucks.
Good tech becomes an extension of human ability. I love vim and awk. I’d rather write documents in troff or LaTeX w/ git. But I also love Pixelmator and actually even outlook these days. I feel awkward without them.
Interestingly, as I type this, I can’t think of a single web UI that I have that unconscious relationship with.
I fail to see how this is an argument in favor of TUIs in principle.
The tech isn’t the principle. The experience is. Use the right thing for for the audience. Use a GUI, use a TUI, use a basic CLI tool for day-to-day. And sometimes that can even be additive where more than one is the right answer.
The clicks stuff in this does feel silly to me. But I think that sometimes there’s value in not reaching for a mouse.
If you care about the tech in principle, then I think the answer is to work on a library/framework you love, like they did, vs a user app.
I’m not reinventing those wheels, and will borrow stuff like this when it seems right. And anything is better than curses :).
When your program is a TUI, it means stdout is useless. The tweet I quoted illustrates this problem. If you do both printf debugging and use a TUI debugger, you will not be able to see the output from the printf statements.
You want to draw a GUI but you're using a text stream to issue commands to the terminal to draw text and color regions of the screen - while at the same time hiding the std output buffer (and losing the ability to select and copy/paste the text being drawn).
As if drawing text and colored boxes is so fundamentally difficult it can't be done any other way.
As if handling shortcuts in a GUI program is so fundamentally difficult that it's easier to do it in a TUI.
My own experience is that text user interfaces over mosh work far better than web applications when on a crappy connection.
My experience isn't specifically with textualized-based applications though (one is irssi, the terminal IRC client, and some with proprietary applications from $work).
Look at how sparing vim is with screen updates. I don’t know if it was intentional, but works out nicely, and makes it a godsend if what you have is 3G which is somehow worse than EDGE has been 15 years ago.
I have a hunch this TUI would struggle in these circumstances.
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.
Is there a good way to have bigger primary font with smaller TUI borders/widgets/etc? What would a good way look like?
Hypothetically some simple restrictions for variable font sizes could keep the simplicity of TUI while also empowering the UX. Similar to how variable colors didn't suddenly make this a "GUI".
Like, a variable font size such that a letter can be just one pixel high and wide? Yeah, that's a GUI. But I rather prefer GPU accelerated GUIs ;-)
Instead, this is the largest failing in my mind to TUIs. As eyesight goes, font sizes increase, and if you use a TUI so do your borders, pads, etc. You have no way to keep a reasonably consistent border size in a TUI if you also want larger fonts.
As it stands i'd prefer my "UI" elements in my TUI to be half the size they are currently. Gutters for things like line numbers or error indicators are obscenely wide due to this notion that they must be a full block size.
If instead you put restrictions on the division, such that font blocks would have to evenly divide then, hypothetically, misalignment would be less of a concern.
So many cool new TUIs are being born today but without very small font sizes they are made nearly useless imo. Popups in https://zellij.dev/ are another great example of something severely inhibited by old fashioned limitations.
The only way variable font sizes work without being isomorphic to a GUI is if the sizes are a series of power-of-N multiples of some base size for some integer N. (Realistically, N=2 is the most likely, though N=3 might sometimes make sense.)
The reason for power of N is that it assures that any set of available sizes used still fit on a grid of the smallest size actually used.
It does seem to add reasonable complexity to the implementations, but i imagine it's opt-in.
Makes it a bit more complex though if the block sizes make subdivision like this difficult, though. This isn't an idea for an implementation necessarily, rather just an idea to illustrate my request. I want to have larger font size than my gutters/etc in my term editors.
Seems basically python https://github.com/Textualize/textual .
We had document/text oriented interfaces in the 80s that were also graphical like in Genera, a lisp machine OS https://en.wikipedia.org/wiki/Genera_(operating_system) 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.
I hope the current approach of fancy terminal apps is just a local minimum we can kick ourselves out of in he long term.
We call those Jupyter notebooks these days.
Note that Genera itself is, AFAIK, proprietary software. But its predecessor (or at least one of them) has been released as Open Source.
http://www.unlambda.com/index.php?n=Main.Mit
HN'ers interested in experimenting with this direction in computing might find the old Lisp Machine code of interest.