[HN Gopher] Textualize - A framework for building Text User Inte...
___________________________________________________________________
Textualize - A framework for building Text User Interface
applications
Author : wey-gu
Score : 271 points
Date : 2022-04-24 12:15 UTC (10 hours ago)
(HTM) web link (www.textualize.io)
(TXT) w3m dump (www.textualize.io)
| asciimov wrote:
| 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 wrote:
| 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 wrote:
| 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.
| WesolyKubeczek wrote:
| How good is it over crappy connection over SSH?
| perlgeek wrote:
| 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).
| WesolyKubeczek wrote:
| 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.
| ahofmann wrote:
| 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 wrote:
| 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]
| Epiphany21 wrote:
| 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.
| DoctorOW wrote:
| I didn't try it with the CSS theme branch, the main version
| used 10-20mb for the example scripts.
| Epiphany21 wrote:
| Jokes and hyperbole aside, that's honestly not too bad. At
| least relative to most modern bloatware.
|
| 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.
| throwanem wrote:
| 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.)
| willm wrote:
| It will run just on just about any terminal on any OS. Only
| standard xterm escapes are used.
|
| You might find a really old terminal emulator where it
| struggles, but it would be the exception and not the rule.
| throwanem wrote:
| 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."
| tux1968 wrote:
| But this appears to work in any terminal, not just the
| developer's. Or did I miss something?
| throwanem wrote:
| 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 wrote:
| 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.
| throwanem wrote:
| 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.
|
| [1] https://github.com/Textualize/textual/tree/main/tests
| mwt wrote:
| 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.
| Epiphany21 wrote:
| 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.
| paisawalla wrote:
| "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."
| throwanem wrote:
| 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?
| leobg wrote:
| Screen recordings are not loading for me (iOS Chrome as well as
| Safari).
| demarq wrote:
| This comment section is absolutely why the HN crowd can be
| downright vile at times.
| camgunz wrote:
| 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.
| qudat wrote:
| 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.
| gnat wrote:
| 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?
| woodruffw wrote:
| > 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).
| camgunz wrote:
| 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.
| mxuribe wrote:
| 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 wrote:
| 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.
| russellendicott wrote:
| 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.
|
| Protocol: https://github.com/rendicott/uggly
|
| Client with gif demo: https://github.com/rendicott/uggly-
| client
| [deleted]
| tux1968 wrote:
| > terminals are almost all written in unsafe languages like C
|
| If you're on the hunt for one that isn't, check out wezterm,
| it's delightfully good.
|
| https://github.com/wez/wezterm
| pkulak wrote:
| Also Alacritty.
| CJefferson wrote:
| one big advantage of browsers is they are accessible to the
| visually imparted, which currently almost no TUIs are,
| including this one.
| [deleted]
| kaba0 wrote:
| 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.
| fmakunbound wrote:
| 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.
| zozbot234 wrote:
| > We had document/text oriented interfaces in the 80s that were
| also graphical
|
| We call those Jupyter notebooks these days.
| mindcrime wrote:
| _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)_
|
| 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.
| lijogdfljk wrote:
| 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 wrote:
| You mean, a GUI?
| lijogdfljk wrote:
| 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 wrote:
| 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 wrote:
| 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.
| wey-gu wrote:
| Be sure to check https://www.textualize.io/what-we-do
| joeberon wrote:
| brasic wrote:
| See also https://charm.sh/
| mfarstad wrote:
| I made https://github.com/mathaou/termdbms with charm libraries
| and I highly recommend it. Very, very slick and easy to get
| started.
| wey-gu wrote:
| Thanks brasic, don't know about charm yet.
| mftb wrote:
| 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).
| twohaibei wrote:
| 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? :)
| lioeters wrote:
| From the site footer: haters > /dev/null
| bogwog wrote:
| > This is intended to be useful feedback for the Textualize
| people, I'm long over Python
|
| That sounds like a you problem
| mftb wrote:
| 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.
| zasdffaa wrote:
| 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.
| chrsw wrote:
| 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 wrote:
| 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.
| ms4720 wrote:
| 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.
| asicsp wrote:
| Small list of projects using rich/textual:
| 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 wrote:
| > we are building technology that lets Textual apps run in a
| web browser
|
| so close, and yet so far away!
| _HMCB_ wrote:
| This is amazing stuff really. As a designer, there's a lot to
| be said for the clarity of text-only UIs.
| wey-gu wrote:
| Me, too!
| bogwog wrote:
| This is really cool, but how does a project like this attract
| VCs? Aren't dev tools a hard sell?
| [deleted]
___________________________________________________________________
(page generated 2022-04-24 23:00 UTC)