12 ms·

Textualize – A framework for building Text User Interface applications

377 points by wey-gu 4y ago

WesolyKubeczek 4y ago
How good is it over crappy connection over SSH?
- ahofmann 4y ago
  I have no idea, but I think it could be better than a bloated website over a crappy connection. Maybe you should try and tell us how it went?
  - throwanem 4y ago
    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.
    - deleted 4y ago
      [deleted]
- perlgeek 4y ago
  If you have a crappy connection, you should really use mosh (https://mosh.org/ 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).
  - WesolyKubeczek 4y ago
    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.
asicsp 4y ago
Small list of projects using rich/textual: https://www.textualize.io/textual/gallery https://www.textualize.io/textual/gallery >we are building technology that lets Textual apps run in a web browser (no code changes required) Excited to see how that turns out.
- enriquto 4y ago
  > we are building technology that lets Textual apps run in a web browser so close, and yet so far away!
- wey-gu 4y ago
  Me, too!
- _HMCB_ 4y ago
  This is amazing stuff really. As a designer, there’s a lot to be said for the clarity of text-only UIs.
deleted 4y ago
[deleted]
joeberon 4y ago
brasic 4y ago
See also https://charm.sh/ https://charm.sh/
- wey-gu 4y ago
  Thanks brasic, don’t know about charm yet.
- mftb 4y ago
  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).
  - bogwog 4y ago
    > This is intended to be useful feedback for the Textualize people, I'm long over Python That sounds like a you problem
    - mftb 4y ago
      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.
    - zmmmmm 4y ago
      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.
  - twohaibei 4y ago
    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? :)
Epiphany21 4y ago
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.
- throwanem 4y ago
  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.)
  - tux1968 4y ago
    But this appears to work in any terminal, not just the developer's. Or did I miss something?
    - throwanem 4y ago
      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.
      - mwt 4y ago
        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.
        4y ago
camgunz 4y ago
I love textualize/rich (and charm)! 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.
- mxuribe 4y ago
  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.
  - heavenlyhash 4y ago
    I want to see more things like this emerge too. 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.
zasdffaa 4y ago
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.
deleted 4y ago
[deleted]
wey-gu 4y ago
Be sure to check https://www.textualize.io/what-we-do https://www.textualize.io/what-we-do
asciimov 4y ago
Please stop trying to GUI-ify my terminal. I don't want all those questionable design decisions from browsers making their way into the terminal.
- dragonwriter 4y ago
  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>.
  - merlincorey 4y ago
    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.
    - BeFlatXIII 4y ago
      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.
- animal_spirits 4y ago
  No one is forcing you to use any of these tools so why should you care if others want to use them?
- ASalazarMX 4y ago
  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. There's enough UI real state for everyone.
chrsw 4y ago
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.
- azinman2 4y ago
  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.
  - zmmmmm 4y ago
    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.
    - usrn 4y ago
      What you're looking for is "GNU Readline."
    - 4y ago
leobg 4y ago
Screen recordings are not loading for me (iOS Chrome as well as Safari).
bogwog 4y ago
This is really cool, but how does a project like this attract VCs? Aren’t dev tools a hard sell?
fmakunbound 4y ago
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) 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.
- zozbot234 4y ago
  > We had document/text oriented interfaces in the 80s that were also graphical We call those Jupyter notebooks these days.
- mindcrime 4y ago
  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) https://en.wikipedia.org/wiki/Genera_(operating_system) 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 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.
lijogdfljk 4y ago
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?
- auggierose 4y ago
  You mean, a GUI?
  - lijogdfljk 4y ago
    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".
    - auggierose 4y ago
      Yup, being sarcastic, you got me there. 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 ;-)
      - lijogdfljk 4y ago
        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/ https://zellij.dev/ are another great example of something severely inhibited by old fashioned limitations.
demarq 4y ago
This comment section is absolutely why the HN crowd can be downright vile at times.
kaba0 4y ago
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.
- pmarreck 4y ago
  I can agree, but I also enjoy using remote-monitoring tools like gtop/htop/gotop over the network via plain old SSH and a terminal
  - 9dev 4y ago
    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.
ms4720 4y ago
Tk/TCL did this for GUI apps. You could even do it remotely shipping tk commands over a socket. It was very sweet to work with.
einpoklum 4y ago
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.
- willm 4y ago
  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.
ngcc_hk 4y ago
Can it be used by lisp under Ubuntu, macOS and windows 10? Quite interest in the jupyter. Or similar tool available for lisp. Seems basically python https://github.com/Textualize/textual https://github.com/Textualize/textual .
hsn915 4y ago
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.
- salmo 4y ago
  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.
  - hsn915 4y ago
    I do acknowledge that GUI programming in 2022 still sucks. I fail to see how this is an argument in favor of TUIs in principle.

377 points by wey-gu 4y ago

WesolyKubeczek 4y ago

How good is it over crappy connection over SSH?

ahofmann 4y ago
I have no idea, but I think it could be better than a bloated website over a crappy connection. Maybe you should try and tell us how it went?
- throwanem 4y ago
  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.
  - deleted 4y ago
    [deleted]
perlgeek 4y ago
If you have a crappy connection, you should really use mosh (https://mosh.org/ 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).
- WesolyKubeczek 4y ago
  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.

asicsp 4y ago

Small list of projects using rich/textual: https://www.textualize.io/textual/gallery https://www.textualize.io/textual/gallery >we are building technology that lets Textual apps run in a web browser (no code changes required) Excited to see how that turns out.

enriquto 4y ago
> we are building technology that lets Textual apps run in a web browser so close, and yet so far away!
wey-gu 4y ago
Me, too!
_HMCB_ 4y ago
This is amazing stuff really. As a designer, there’s a lot to be said for the clarity of text-only UIs.

deleted 4y ago

[deleted]

joeberon 4y ago

brasic 4y ago

See also https://charm.sh/ https://charm.sh/

wey-gu 4y ago
Thanks brasic, don’t know about charm yet.
mftb 4y ago
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).
- bogwog 4y ago
  > This is intended to be useful feedback for the Textualize people, I'm long over Python That sounds like a you problem
  - mftb 4y ago
    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.
  - zmmmmm 4y ago
    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.
- twohaibei 4y ago
  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? :)

Epiphany21 4y ago

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.

throwanem 4y ago
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.)
- tux1968 4y ago
  But this appears to work in any terminal, not just the developer's. Or did I miss something?
  - throwanem 4y ago
    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.
    - mwt 4y ago
      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.
      - 4y ago

camgunz 4y ago

I love textualize/rich (and charm)! 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.

mxuribe 4y ago
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.
- heavenlyhash 4y ago
  I want to see more things like this emerge too. 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.

zasdffaa 4y ago

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.

deleted 4y ago

[deleted]

wey-gu 4y ago

Be sure to check https://www.textualize.io/what-we-do https://www.textualize.io/what-we-do

asciimov 4y ago

Please stop trying to GUI-ify my terminal. I don't want all those questionable design decisions from browsers making their way into the terminal.

dragonwriter 4y ago
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>.
- merlincorey 4y ago
  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.
  - BeFlatXIII 4y ago
    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.
animal_spirits 4y ago
No one is forcing you to use any of these tools so why should you care if others want to use them?
ASalazarMX 4y ago
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. There's enough UI real state for everyone.

chrsw 4y ago

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.

azinman2 4y ago
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.
- zmmmmm 4y ago
  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.
  - usrn 4y ago
    What you're looking for is "GNU Readline."
  - 4y ago

leobg 4y ago

Screen recordings are not loading for me (iOS Chrome as well as Safari).

bogwog 4y ago

This is really cool, but how does a project like this attract VCs? Aren’t dev tools a hard sell?

fmakunbound 4y ago

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) 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.

zozbot234 4y ago
> We had document/text oriented interfaces in the 80s that were also graphical We call those Jupyter notebooks these days.
mindcrime 4y ago
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) https://en.wikipedia.org/wiki/Genera_(operating_system) 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 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.

lijogdfljk 4y ago

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?

auggierose 4y ago
You mean, a GUI?
- lijogdfljk 4y ago
  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".
  - auggierose 4y ago
    Yup, being sarcastic, you got me there. 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 ;-)
    - lijogdfljk 4y ago
      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/ https://zellij.dev/ are another great example of something severely inhibited by old fashioned limitations.

demarq 4y ago

This comment section is absolutely why the HN crowd can be downright vile at times.

kaba0 4y ago

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.

pmarreck 4y ago
I can agree, but I also enjoy using remote-monitoring tools like gtop/htop/gotop over the network via plain old SSH and a terminal
- 9dev 4y ago
  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.

ms4720 4y ago

Tk/TCL did this for GUI apps. You could even do it remotely shipping tk commands over a socket. It was very sweet to work with.

einpoklum 4y ago

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.

willm 4y ago
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.

ngcc_hk 4y ago

Can it be used by lisp under Ubuntu, macOS and windows 10? Quite interest in the jupyter. Or similar tool available for lisp. Seems basically python https://github.com/Textualize/textual https://github.com/Textualize/textual .

hsn915 4y ago

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.

salmo 4y ago
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.
- hsn915 4y ago
  I do acknowledge that GUI programming in 2022 still sucks. I fail to see how this is an argument in favor of TUIs in principle.