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.
> browsers have to support tons of backwards compatibility (quirks mode, TLS), terminals have less to support by being more circumspect
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).
This is pretty fair, though I do think being able to write something like st or even rxvt stands in contrast to... anyone building a different browser? But you're right, we can do better here. A lot of discussions and process in the kitty community have been super enlightening for me, the dev there knows so much.
Agreed with your comments, and in fact your comment here:
> ...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.
I'm actually working on this. Component based over the wire TUI system. It's in a decent alpha state but I want to code and host some more sample sites before I start sharing a ton.
Oh man I want this to be true so badly! My career was built on building web apps and I also love the terminal. I think ssh apps have the potential to bridge the gap between the convenience of web apps (no install required) and the terminal.
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.
I've been looking for a set of instructions about how to set up an ssh app that doesn't open my computer to pwnage. Do you know of such a set of instructions?
Possibly something along the lines of a chrooted user for $app that all users log into? Said user would run the application program instead of a shell probably, and actual auth for end users would be more like an http auth style setup instead of "logging in" to the server.
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.
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.
OH! This is a great point (where is 'mwcampbell when you need him haha). Accessibility is a requirement of any future stack, for sure. I guess I assume accessibility is workable for text, but TUIs probably not so much.
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.
For me the biggest issue is not having history. That’s the value of the terminal - I can scroll up and see previous interactions, copy paste from them, etc.
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.
I agree but to the parent's point, there is still something non-native about these terminal apps that essentially draw a full blown GUI and build a custom application in there.
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.
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.
Well, the intention of X forwarding was exactly to enable GUI apps via plain old SSH, and that works fine! There’s just no really cool, ubiquitous, useful, cross-platform, GUI apps in that realm: if there were any, we would use them, because technically, this is all easily possible since forever.
Yea, I have zero interest in Charm Cloud and their web site is eye-poison, but Go > Python so next time I need some CLI stuff, I'll be researching Charm (This is intended to be useful feedback for the Textualize people, I'm long over Python).
He/she's not alone - there are literally dozens of us!
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.
lol, it is, but people that are trying to market things to me frequently want to know about my problems so they can appeal to them and thereby sell me things.
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.
I've read the part about their website and thought to myself: How bad can it be? Now I know and agree. Who signed this off knowing the target group? :)
TUIs are much older than browsers (even older than GUIs), and while GUIs, including browsers, have taken over much of the niche, it's nice to have tools for TUIs in <preferred language>.
One objection I have perhaps in line with the GP here is that they are literally bringing in "browser" things with Textualize -- layout is done with CSS Grid and they are actively working on supporting more and more CSS.
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.
If they can run a large enough subset of CSS that it becomes a good enough replacement, that would be a major win if its footprint is still much smaller than Electron at that point.
As someone who experienced Turbo Pascal, For Pro LAN, QuickBasic and Norton Utilities, I'm the complete opposite of your opinion. Let people use the already vast arsenal of CLI utilities, let people who want to move eleven random files from one directory to another use Midnight Commander, let people who want graphics use the GUI, let insane people who want to combine all three have fun.
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.
I also like having CLI tools that only work properly in the same terminal the developer uses! Browser incompatibility was such a reliable source of joy back in the Bronze Age days of web dev - I've missed it, and I'm really glad to see lots of smart folks doing the incredibly worthwhile work of reinventing the same concept for a new generation.
(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.)
I feel like it's not been that long ago that I ran into trouble with "standard xterm escapes". As I recall, there are a lot of those, and many of the more interesting ones are at best very unevenly supported across terminals. The last such experience is in fact what led me to avoid doing anything more complicated in a terminal than basic colors and a few emoji.
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."
I have been using textual extensively inside Visual Studio Code which uses xterm.js behind the hood [1], so far everything except hyperlinks works flawlessly, and hyperlinks don't obstruct anything either, it just shows as plain text. All 256 tests pass on my machine and the coverage based on lines of code is 42%, but you have to keep in mind that this project is still in beta [2] so that number is going to change
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].
Yeah, that's fair. The perils of reading code on a busy Sunday, I suppose - I didn't get as far as noticing that Textual has basis in a much more heavily used and tested library, and that definitely changes my evaluation.
I grant the claim is that it works perfectly in any terminal. I see no evidence of that, and my experience with the complexities of terminals leads me to find the claim quite difficult to credit.
Why waste time making up a weird claim and then arguing against it? The author told you, personally and directly,
> 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 assumed my mild hyperbole would need no explanation, but perhaps that was optimistic. Conceding the author's claim as he made it and you quote it, I think there's still a discussion to be had here.
> 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.
We simply have a different perspective on this. You see a TUI and have experience in the "Bronze Age" of the Internet in which browsers were not so stable across platforms/etc. and think that this more or less just doesn't work. I suspect peoples' experiences using it for a while now won't sway you; you are more than welcome to assume everything works only on one computer and is reliably broken elsewhere. I don't care what you choose to build your company with but I personally find this attitude towards new tools toxic and paralyzing. Hence my attempt at engaging to learn more.
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.
All of that is moot unless you've tested the software yourself and found it to be broken in certain terminal emulators.
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.
You’re looking at the master branch. Most of the work is in the CSS branch.
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.
"It will run just on just about any terminal on any OS" is an extremely tall claim and requires more than stating what's easy to imagine, in order to back it up. Xterm is not some kind of universal standard, it's a constructive definition.
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."
I'd probably try to do it with some kind of dummy framebuffer I could capture to an image file, and then inspect that image for variance against a known good snapshot. It's an approach I've seen work well with mobile app e2e testing; I grant it's heavyweight and can be somewhat imprecise, but I can't think offhand what could be much lighter and still work as well.
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?
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.
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.
This reminds me of 1998. I was in college and working at a mid sized business replacing a dumb terminal system on a VAX with a nice NT based GUI. I mocked the TUI. So antiquated running off a minicomputer.
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.
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.
If you have a crappy connection, you should really use mosh (https://mosh.org/) instead of SSH.
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).
I meant “crappy” in the sense of low bandwidth, not unreliable. Those sidebar animations come with a comparative lot of data being fed into the terminal.
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.
Why would you assume that? Most websites bloated or otherwise don't need to keep a socket open 100% of the time to function at all, and I strongly suspect most sites that do use websockets also pass considerably less over the wire in absolute terms than this does when it's rendering stuff like those fancy progress bars.
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.
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?
I'm sure you're being sarcastic, but no - i mean a TUI.
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".
> Hypothetically some simple restrictions for variable font sizes could keep the simplicity of TUI while also empowering the UX.
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.
No, not at all a pixel wide. A pixel wide font character can hardly be called a character, can it? What information does that pixel character convey, exactly? Would it not look identical?
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.
At the very least double height, double width, and double size letters are specced out but are unfortunately not supported by enough terminal emulators that I'd use them for more than a toy.
I mentioned in another post, and as someone else also mentioned, that it would hypothetically work well if you kept the sizes at multiples. Ie i wouldn't want to break the grid and break alignment, so vertically a smaller font size would go in multiples, such that each downward increment of font would be half the size.
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.
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.
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.
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.
Textual will be keyboard focused with mouse support to aid discoverability. I agree it’s not a TUI if you can’t do everything with the keyboard, so I wanted to avoid things like floating windows or interactions that are impossible without the mouse.
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.