[HN Gopher] TUI Studio - visual terminal UI design tool
___________________________________________________________________
TUI Studio - visual terminal UI design tool
Author : mipselaer
Score : 522 points
Date : 2026-03-13 10:32 UTC (12 hours ago)
(HTM) web link (tui.studio)
(TXT) w3m dump (tui.studio)
| mipselaer wrote:
| Amazing cool design tool for TUI's I got it running instantly and
| it feels stable and complete as well. Only 10 stars in GitHub.
| grilo16 wrote:
| Noice figma for terminals! Dude super cool idea, great job =D
| kantord wrote:
| this looks insanely cool.
|
| One of the most original ideas I have seen on HackerNews in the
| past few years.
| kantord wrote:
| tip: your git repo's description (not readme, repo description)
| does not link the website. It should.
| mcraiha wrote:
| Also fill the Website field in About section.
| aethorn wrote:
| The website UI is unreal, I loved the idea
| tim-projects wrote:
| This is so cool I immediately wanted to convert my apps. But then
| when I thought about it, well it's trying to recreate CSS but in
| a majorly worse way.
|
| Browsers are ubiquitous and I can just tell ai to build a web
| page. I can't really see a use case other than novelty.
| purerandomness wrote:
| k9s, ncdu, htop, powertop are good showcases how a TUI reduces
| mental load and are superior to browsers and / or other GUI
| tools
| xvilka wrote:
| More importantly, it also reduces CPU and memory load.
| hrmtst93837 wrote:
| If you need a UI over SSH or inside tmux, skipping browsers and
| CSS isn't just a novelty, it's essential since HTML can't touch
| that territory. TS-based layout in terminals can be ugly but it
| also dodges a pile of accessibility, latency and bloat issues
| you get by default with anything running in Chrome.
| fidotron wrote:
| This is going to end up with TUIs that resemble old BBS ANSI art,
| such as https://16colo.rs/
|
| It completely misses the reason people like current TUIs.
| lsaferite wrote:
| FWIW, I still love to see the old BBS UIs and ANSI art. But
| that's probably just nostalgia talking.
| calgoo wrote:
| FYI LLMs are great at generating the ascii art, so you can
| create real fun games and TUIs that look like old school
| BBSs.
| fidotron wrote:
| We can remain grateful the kids haven't discovered how to use
| figlet in HN comments.
| drob518 wrote:
| I agree. The animation on the site lost me when it placed a
| button. IMO, buttons are not part of TUIs. Those are just low-
| resolution GUIs, IMO, and that's sort of the worst of all
| worlds. The first good TUIs were things like top and elm.
| genxy wrote:
| ENSHT comes for everyone. This is sexual selection over natural
| selection. Claude Code also gets this wrong, they got way to
| fancy and ruined what a good tui is by being an uncanny combo
| between a scrolling log and a completely rewritten canvas.
| gattilorenz wrote:
| Look up Visual Basic for Dos for a surprisingly good TUI editor!
| quotemstr wrote:
| Yes!
| dormento wrote:
| Old VB is still king for laying out interfaces, for the
| narrowest of use cases today, bu still... Makes me sad how much
| we regressed due to the web.
| lsaferite wrote:
| I find it slightly annoying and disappointing that the blocks
| saying what frameworks it's designed to export to aren't links to
| those frameworks.
| glhaynes wrote:
| > No install fuss -- download and start designing immediately.
|
| also
|
| > Gatekeeper blocks the app immediately. You'll see either
| "TUIStudio cannot be opened because it is from an unidentified
| developer" or "TUIStudio is damaged and can't be opened" on newer
| macOS after quarantine flags the binary. To get past it: right-
| click the .app - Open - Open anyway -- or go to System Settings -
| Privacy & Security - "Open Anyway".
| mholt wrote:
| tbf that's Apple's fault, not the choice of the free, unpaid
| open source developer.
| glhaynes wrote:
| Apple's fault that they didn't bother to edit the text that
| says "No install fuss"?
| butlike wrote:
| Probably don't know how now that the LLM helping them write
| the code has lost that context.
|
| From their github it appears all the code is llm-generated
| slopinthebag wrote:
| You mean the AI agent that was prompted to vibe code this?
| eterps wrote:
| This is nonsensical, there is nothing textual about the UIs being
| shown here. It doesn't stop being a GUI if you have a 1:1
| representation of the concept within character cells.
|
| The UX actually matters, and TUIs are generally built for
| effectiveness and power (lazygit being an excellent example). But
| once you start adding mouse clickable tabs, buttons, checkboxes
| etc. you left the UX for TUIs behind and applied the UX expected
| for GUIs, it has become a GUI larping as a TUI.
| banach wrote:
| One justification for TUIs is remote access over SSH.
| eterps wrote:
| Sure, but my point was that UX matters for TUIs. A TUI with a
| UX that fits its paradigm , again like lazygit, works great
| over SSH.
| theowaway213456 wrote:
| You can tunnel a port over SSH and get a web UI locally,
| though it's not commonly done. I feel like more people would
| actually do this if tunneling a port was just ever so
| slightly easier (like, you're already SSH'd into a box, then
| you run a command, then you somehow automatically get a
| tunnel for that command's UI port plus a local browser window
| open to the page)
| roywiggins wrote:
| Even easier is just using an X server, if you have it set
| up properly you just need to run the remote app and the
| window pops up on your machine.
|
| (I think terminal-based GUIs are neat just for fluidity of
| use- you can pop one open during a terminal session and
| close it without switching to mouse or shifting your
| attention away from the terminal. They can also be a nice
| addon to a primarily CLI utility without introducing big
| dependencies)
| wolvoleo wrote:
| Yeah I love that about X. I remember in the 90s when I
| first figured that out. I was logged in from a university
| workstation into my home computer with SSH and I launched
| my mail client or something and I thought doh, stupid
| that will only popup locally.
|
| Then colour my suprise when it popped up on my screen
| right there. Slow as molasses but still. Wow. Magic.
|
| It's a shame Wayland dropped this. Yes I know there's
| waypipe but it's not the same.
| coldpie wrote:
| > It's a shame Wayland dropped this.
|
| It... really isn't. Like you said, remote X was barely
| usable even over an entirely local network. Most
| applications these days are also not designed for it,
| using loads of bitmap graphics instead of efficient, low-
| level primitives. So you end up being just one tiny step
| away from simply streaming a video of your windows. We
| have better tools for doing things remotely these days,
| there's a reason approximately no one has used remote X
| after the mid-90s. It's a neat party trick, but I don't
| blame the Wayland authors for not wanting to support it.
| duskdozer wrote:
| Like what? X forwarding has pretty much always been the
| thing most likely to work for me and I haven't been able
| to find any equivalent.
| coldpie wrote:
| The big obvious one is web-based tooling. Your
| information & settings are stored on a server and you use
| a web browser to view it via whatever device you're on.
| For more locally based workflows, we have networked
| filesystem protocols, automatic syncing between systems,
| that kind of thing. It's not a 1-1 equivalent of running
| a remote program and viewing it locally obviously, but it
| gets the same job done, in a much more useful & flexible
| manner than X forwarding did.
|
| For example, the remote mail client usecase I was
| replying to is simply done with a webmail client today.
| duskdozer wrote:
| I don't really feel like web interfaces or syncing are
| really a substitute tbh, and I'm not sure how they're
| more flexible. ssh -> run -> gui opens, and the program
| itself doesn't need to be designed differently to work
| coldpie wrote:
| > and I'm not sure how they're more flexible. ssh -> run
| -> gui opens
|
| But this doesn't work on your phone, or on a Windows or
| macOS device, right? That's what I meant by flexible, X
| forwarding fits a pretty narrow set of usecases, while on
| the other hand keeping programs on the clients and data
| centrally located on a server allows for a whole lot more
| options for how to interface with that data.
|
| (To be clear, nothing wrong with X forwarding! It's a
| cool tech and I'm glad you have a use for it! I'm just
| arguing that it's fine for Wayland to not try to support
| that kind of thing, because we've got other ways of
| working remotely now.)
| pseudalopex wrote:
| X servers are available for phones, Windows, and macOS. X
| interfaces not designed for phones can be difficult to
| use on phones. But web interfaces not designed for phones
| can be difficult to use on phones.
|
| There is not a web tool for every use. And web tools are
| not better for every use.
| tracker1 wrote:
| IIRC, it's not that secure though.. I'm really surprised
| people didn't do more things like send animated skulls to
| people's desktops.
| wolvoleo wrote:
| Xauth fixed that way back in '93. All you have to do is
| use -Y not -X with SSH.
| wolvoleo wrote:
| Ps: oh yes and before '93 I've had so much fun practical
| joking around :)
| cbm-vic-20 wrote:
| > one tiny step away from simply streaming a video of
| your windows
|
| In the 80s/90s this wasn't feasible due to network
| latency and bandwidth, but it's pretty common now to do
| exactly this, with VNC and other remote desktop
| protocols.
| wolvoleo wrote:
| It is, there were tools like NX that made it entirely
| usable even latencywise. And these days we're really
| going more and more to remote computing.
|
| In the time when wayland was invented it made sense
| because we did everything purely local. But now it's as
| outdated as X11 was in 2010.
|
| And yes I still use it a lot. It works well. Networks
| have become a lot better and even most cloud compute I
| use is geographically nearby.
|
| What made it slow back then was that I only had a 128kbit
| uplink at home. And the uni had 2 mbit for the whole
| computer science building :)
| pseudalopex wrote:
| > In the time when wayland was invented it made sense
| because we did everything purely local.
|
| People complained of no forwarding in Wayland when it was
| invented.
| throwawaymobule wrote:
| Waypipe looks interesting.
|
| The main advantage of x forwarding for me was when I'd
| randomly need it and had nothing set up ahead of time.
| Hopefully it starts getting installed in distros by
| default eventually.
| jasongill wrote:
| While in an SSH session, press enter, then type tilde and
| capital C (enter ~C) and you can add command line options
| to the current session. To add a port forward from your
| local 8080 to the remote port 80 without closing the
| connection, do: enter ~C -L
| 8080:localhost:80
| zimpenfish wrote:
| That is a neat trick. Added to the list.
|
| (Ultimately unhelpful though because I use mosh
| everywhere these days and that doesn't appear to have
| anything fancy like this.)
| dylan604 wrote:
| Maybe it's just still too early in the morning yet, but
| what is the significance of hitting enter first?
| jasongill wrote:
| SSH expects the escape sequence (tilde) to be the first
| character on a new line; since backspace is sent as a
| character, you can't just backspace over something you've
| started typing and then press tilde to have it
| recognized.
|
| Technically, you don't have to press enter if you've not
| typed anything (try it in a new SSH session - as soon as
| you are logged in, type ~? to get the SSH help output),
| but since the comment was about doing this during an
| active session without ending it, I figured noting that
| pressing enter first to be sure you're on a new line
| wouldn't hurt
| Tepix wrote:
| Thanks. This could really benefit from a TUI!
| wolvoleo wrote:
| I do this a lot but I'd still prefer TUI where possible.
| With too much visual content it isn't of course, but for
| many cases a TUI is much more responsive and much lower
| resource.
| surajrmal wrote:
| I largely agree with you, but there are limits to what a
| tui can do well. If analyzing a flame graph or
| performance trace, web UI is a better fit. However, most
| things are not that.
| yoz-y wrote:
| I like TUIs because I run everything in tmux and I can just
| pick up work from wherever I was on any computer, phone or
| tablet.
| DesiLurker wrote:
| share some good (easy on remembering keyboard & mouse)
| tmux configs. I usually struggle with copy pasting many
| scrollback lines from/to tmux. would love for my claude
| to be natively tmux aware.
| marxisttemp wrote:
| I'd rather use a TUI than a web UI.
| papageek wrote:
| Another justification could be simply some people like using
| them better.
| clickety_clack wrote:
| Drawing a "nonsense" line between TUIs and GUIs is pretty
| arbitrary, it's all pixels on a screen at the end of the day.
| People like the TUI vibe, and that's a good enough reason to
| make and use them.
| eterps wrote:
| I actually agree with that. And I enjoy the fact that TUIs
| are becoming popular. But there is more to it than just the
| 'vibe'.
| clickety_clack wrote:
| The vibe might not be a necessary reason, but it is a
| sufficient one.
| tartoran wrote:
| I love TUIs but one main reason for that is that they're
| keyboard centric. If I have to use the mouse it kills it for
| me, if both work then it's fine. I hope that modern TUI
| makers keep this in mind. What's great about the keyboard
| centric is that with a few keystrokes/shortcuts it's very
| easy to do repeatable work and takes less energy than hunting
| boxes to click on with the mouse.
| mikkupikku wrote:
| TUIs aren't more inherently keyboard driven than well
| constructed GUIs. You can easily make a keyboard driven GUI
| that has all the shortcuts you'd add to a TUI. (Just don't
| let the "UX design experts" near it.)
| sumnole wrote:
| The UIs are text only, so they are textual. Modern TUIs may
| support mouse events. That this tool can export to several TUI
| frameworks is evidence that these UIs are indeed TUIs, even if
| not the most traditional.
| jmmv wrote:
| "Modern TUIs may support mouse events" hah! They already did
| in the 80s...
| rob74 wrote:
| Yeah, remember good old Norton Commander
| (https://en.wikipedia.org/wiki/Norton_Commander) - not that
| newfangled clone Midnight Commander, the original? Or the
| Borland text mode IDEs
| (https://ilyabirman.net/meanwhile/all/ui-museum-turbo-
| pascal-...), complete with windows, menus, buttons, scroll
| bars, file dialogs etc. etc.?
| jgilias wrote:
| Oh boy, that sent me down the memory lane hard. I also
| had to Google "Volkov Commander", as that name sprung to
| mind immediately too.
| jvanderbot wrote:
| No, a text-based UI is not sufficient. It must also work in a
| text-only session e.g., on the CLI over SSH.
| 627467 wrote:
| Do UIs exported from this tool not worknon CLI over SSH?
| elxr wrote:
| > That this tool can export to several TUI frameworks
|
| It clearly cannot. Have you even tested it?
| papageek wrote:
| This? Alpha notice: Code export is not functional yet.
| We're actively working on it -- check back soon.
| elxr wrote:
| Exactly, don't know why people are acting like actually
| makes TUIs, it's just a rough mockup of a TUI for now,
| with a convoluted figma-like UI.
|
| I guess the headline and website was enough to get all
| these upvotes. Quite disappointing as someone in the
| early stages of making a TUI tutorial myself.
| tracker1 wrote:
| I've been juggling some BBS related projects myself that
| involve some TUI work over raw and web sockets that I've
| been working on... It's definitely a fascinating space
| and there's been a lot of relatively recent activity in
| the space.
| elxr wrote:
| > and there's been a lot of relatively recent activity in
| the space.
|
| 100 percent agree. I personally love what the openTUI
| folks have been up to. As weird as this might be to say,
| we're still in the early, early stage of TUI adoption.
| dec0dedab0de wrote:
| It's a TUI if it uses text to build those elements.
|
| You can be effective and powerful in any kind of interface,
| Just like you can be ineffective and weak in any kind of
| interface. People like TUIs because they're cool, and work over
| SSH.
| reaperducer wrote:
| _It 's a TUI if it uses text to build those elements._
|
| No. All you've done is make a low-resolution GUI.
| gambiter wrote:
| Yeah, that's the point. Why did you think you needed to say
| it?
|
| It's a GUI that works over SSH. There is a very valid use
| case for that.
| ralferoo wrote:
| I assume his point is that making stuff that assumes a
| mouse makes for a bad text-based UI. Absolutely fine if
| everything is controllable via the keyboard, e.g. if the
| tabs were labelled F1-Fn and they function keys switched
| them, or they had an underlined letter and Ctrl+letter
| switched focus to it, or whatever.
|
| But if this thing requires you to just tab a lot through
| lots of pointless and rarely used fields to get to a
| "button" so you can activate it, because it's really all
| designed to be used with a mouse, then it's a bad text-
| based UI.
|
| There are some incredibly good text-based UIs around,
| some going back to mainframe stuff from the 70s. Most of
| them are optimised for speed of control via keyboard
| rather than for looking pretty. Almost none of them would
| be quicker to use with a mouse.
| dec0dedab0de wrote:
| absolutely, but it's still a TUI. Just like if you made a
| GUI that didn't have any mouse support and needed all
| keyboard shortcuts, it wouldn't stop being a GUI.
| ralferoo wrote:
| TBH I've always hated the backronym TUI anyway, so if TUI
| includes things that require mouse input, then maybe we
| can go back to using "text-based UI" for things that only
| require a keyboard like we used to 30 years ago.
| drakythe wrote:
| TUI means "Terminal User Interface" or "Text User
| Interface"
|
| A GUI that is built with Text, and intended to be used in a
| Terminal, is what a TUI is, colloquially AND
| definitionally.
|
| What do you think qualifies as a TUI?
| reaperducer wrote:
| I've been using TUIs since PR1MEOS mini-mainframes in the
| early 1980's, I know what I'm talking about.
|
| The issue is not the text. It's the WIMP interface.
| mikkupikku wrote:
| Define TUI. I'm genuinely curious what it means in your
| context.
| zahlman wrote:
| This is a pointless semantic argument.
|
| Of course you can use the primitives of TUI, especially
| with mouse support, to reproduce a large amount (if not
| all) of the standard GUI interaction paradigms.
|
| But it's bizarre, and missing the point from a UX
| perspective.
|
| As an extreme example, we can imagine a program that
| displays the borders of a 40x15 "window" in the middle of
| a console, with box-drawing characters, putting a "close
| box" in an upper corner, with text like "File Edit Help"
| in the top left. We can imagine it responding to a click
| on the "File" text by popping out a "menu"; we can
| imagine a drag starting from the "title bar" causing the
| window position to be update (and the entire terminal
| window redrawn).
|
| A lot of those kinds of functions, ironically enough,
| might make sense for a TUI editor implemented as a TUI
| (except the "windows" might just be understood as panels
| where the ultimate program displays parts of its output).
| But as an emulation of GUI windows, it'd be a strange,
| impractical novelty.
| StableAlkyne wrote:
| What's with the purism? It's just a term used to
| differentiate one way of making a UI from another. Who
| cares about what is practical when you're just trying to
| give a thing a name.
|
| Even in your example, it's pretty clear cut. If the
| window is built with text and served in a terminal
| emulator, it's a TUI. If you build it with a graphical
| framework that now needs X11 or whatever, it's a GUI.
|
| This is just needlessly pedantic.
| jandrese wrote:
| Would you say old DOS applications like Borland's Turbo
| series of compilers were not TUIs? They ran in the console
| but had menus, mouse support, dialog boxes, etc...
|
| How about those text games that used ASCII art and you
| typed in commands like "look" and "go north"?
|
| I would say using text mode is the primary requirement for
| a TUI. The other requirement being some kind of human-
| machine connection, IE a User Interface.
| jvanderbot wrote:
| Yes. A TUI runs in a text session. A GUI runs in a graphics
| session. A terminal emulator emulates a text session in a
| graphics session - and allows you to run TUI/CLI tools. This
| is apparently controversial?
| zabzonk wrote:
| > TUI runs in a text session. A GUI runs in a graphics
| session
|
| What do you mean by this? I have never heard these terms
| before. I can launch and interact with a GUI from a text
| application, or a text application from a GUI.
| riquito wrote:
| Perhaps he's thinking about "console" / "display server"
| but the lines blur fast (e.g. you can run GUI in linux
| console with framebuffer with some limitations)
|
| - https://en.wikipedia.org/wiki/Linux_console - https://e
| n.wikipedia.org/wiki/Windowing_system#Display_serve...
| chrisshroba wrote:
| Sometimes your system doesn't have a graphical session,
| like a raspberry pi with no x server running, or a cloud
| compute instance I'm ssh'ed into, or a docker image
| running on my laptop. Sometimes your system doesn't have
| a (particularly usable) text system, like a work computer
| that disables the terminal or a family member's MacBook
| who doesn't have the time or space to install XCode
| terminal utilities to be able to use things like brew
| install.
|
| My point is that it's not a given that having one means
| you have the other.
|
| TUIs are wonderful for the first case.
| tracker1 wrote:
| It makes far more sense in the context of effectively a
| remote session or dumb terminal serial connection. Your
| "terminal" application is only emulating a text mode
| environment inside a gui, typically... you can
| ctrl+alt+F2 - F5 in a lot of Liknux's to switch to a
| terminal session if you want, but that's not what people
| tend to actually use.
|
| Beyond this, without remote X properly configured, again,
| most don't and probably shouldn't.. you aren't running
| remote gui applications over an SSH session. Richer TUIs
| were pretty common in ye old days of DOS and other OSes
| before rich GUIs become the norm. DOSShell, Edit.com,
| etc. The IDEs of days past and Word Perfect even. These
| all interacted with Mice and were considered the norm.
| The features that allow this over a remote terminal today
| are pretty great IMO, the harder part is properly
| handling window sizes/resizes, etc.
|
| With graphical extensions, there are even nice app
| explorers with image previews via TUI. It pushes the
| boundaries. For that matter, I often wonder what could
| have come with RIPscrip/RIPTerm if the leap to web didn't
| happen the way it did...
|
| I think the single hardest part of TUI is dealing with
| wide characters and secondary fonts for color emojii that
| don't quite render in 2 spaces completely in a lot of
| termianls... it makes the line drawing harder too.
| nine_k wrote:
| A remote GUI application now runs in a special client
| called a _web browser_ ; it's a recent development,
| barely 35 years old.
| dwedge wrote:
| These sarcastic reddit style comments grate me. And it's
| also inaccurate, you're not runnning _remote_ graphical
| applications from a remote headless webserver. You 're
| rendering it locally.
| nine_k wrote:
| An X server also normally renders things locally, as does
| a VT-compatible terminal. If you want no local rendering
| at all, there's VNC.
|
| With a web app, you can slice and dice processing between
| local and remote by running JS locally. Most processing
| usually happens remotely though, and only the display and
| command logic is run in the browser.
| mikkupikku wrote:
| He's functionally right though, a remotely served
| interface can be implemented as a TUI behind ssh, or it
| could be implemented as a website. Which is the better
| option depends on the context, but they're both serving
| the same function, and the terminal emulator you're using
| to view the TUI is most certainly rendering it on your
| computer.
| jvanderbot wrote:
| This is true only up to "you can send and receive data".
|
| A terminal is an OS construct mostly. It will, with
| permissions, allow you to do anything the OS can do,
| including shutdown, or serve more data. It's the default
| mode of operating the system.
|
| The opposite is not true. The default mode of operating a
| web browser will not let you create a terminal access or
| do anything new with the machine.
|
| Insofar as the previous is false - because it website has
| flaws that allow code execution, shell escapes, or remote
| package installations, it's worth pointing out that these
| are usually possible because your web server is running
| as a user on a system, effectively with system access via
| similar interfaces as the shell.
|
| This is like saying you can operate a car from the truck
| - yeah maybe through some weird gymnastics, but the trunk
| is for transfer, and the drivers seat is for operating.
| mikkupikku wrote:
| You can easily reboot a machine from a web interface, if
| rebooting the machine is intended to be part of that
| interface. I do it all the time with my shitty wifi
| router (which incidentally, also has a TUI interface.)
|
| You're off base with your talk of terminals being "OS
| constructs" or whatever, I think it's because you're not
| being precise with what exactly you're talking about.
| "The terminal" is a combination of a terminal emulator,
| which is a userspace program which interprets control
| sequences that tell it which characters to render where.
| The terminal emulator is connected to a psuedoterminal,
| which is a pair of files for IPC with some special
| semantics, notably canonical mode. Importantly, in none
| of this is anything for controlling the system.
|
| For controlling the system, you need some other program
| besides a terminal. A shell. A shell isn't part of the
| terminal, nor part of the operating system except in a
| broader sense of the term. And it doesn't have special
| abilities to control the system, anything the shell can
| do, a TUI or web interface, or any other kind of
| interface can be made to do.
|
| Anyway, you ssh into a computer and start a TUI. The TUI
| doesn't render anything, it just sends you text and
| escape codes. The terminal emulator _on your computer_
| interprets this stream of escape codes and text, as a web
| browser interprets html, and renders it locally.
| dec0dedab0de wrote:
| It feels like a reference to DOS graphics mode.
| robotresearcher wrote:
| Is it character mapped, designed to run in a tty
| terminal? TUI.
|
| Is it pixel or vector mapped, designed to run in a
| graphics terminal? GUI.
|
| Of course strictly speaking TUI is a subset of possible
| graphical user interfaces, but the term GUI was coined to
| denote interfaces other than the already-ubiquitous text
| terminal interfaces.
|
| TUIs have since absorbed GUI interface elements like
| buttons, checkboxes, and even pointer input, which I
| think is causing the terminology complaint here.
| Classical TUIs like Norton Commander are more about
| keyboard input and navigation. But being text-mapped is
| the identifying feature of a TUI, I think most people
| accept.
| zahlman wrote:
| In the Linux world, your GUI is built on a stack of
| separate programs. At the bottom is the "display server",
| such as X11 or Wayland. One of these needs to run to have
| GUI windows (or a full-screen background) at all;
| otherwise the screen is just covered by 80x24 terminal,
| and even if there were mouse support there would be
| nowhere to click or drag to change that. Without the
| display server, you are in a "text session". It's
| relatively rare to do this locally nowadays, but Linux
| still adheres to the highly modular UNIX philosophy.
|
| Your terminal windows (whether that's "Terminal" or
| "cmd.exe" or anything else) are still fundamentally
| graphical programs that _emulate_ such a text session.
| PurpleRamen wrote:
| > there is nothing textual about the UIs being shown here.
|
| Well, except:
|
| > a 1:1 representation of the concept within character cells.
|
| TUI is build from text, and living within its constraints and
| what it's engine (usually the terminal) allows. GUI is build
| from graphics, and has basically a pixel perfect control of its
| own. This is a very notable difference, especially at the time
| when these terms were coined.
|
| > TUIs are generally built for effectiveness and power
|
| No, this is a result of different architectures and their
| constraints.
|
| > But once you start adding mouse clickable tabs, buttons,
| checkboxes etc. you
|
| TUI and mouse are predating the GUI (more or less). We had them
| already 40-50 years ago at the dawn of interfaces. We are now
| just moving back to them for practical reasons.
| criddell wrote:
| Would you make the same argument for classic UIs created with
| things like Borland's Turbo Vision framework? It's generally
| known as a TUI framework (including by Wikipedia).
| jvanderbot wrote:
| The distinction is - if it runs over ssh (no x / graphics
| login) or on a headless machine - TUI
|
| If it requires graphics login, even if it uses character
| layouts - GUI
|
| IMHO the T/G is not for the display elements, it's for the type
| of _session_.
| tgv wrote:
| Not to put too fine a point on it, but X11 runs over ssh just
| fine. No "graphics login" required.
| injidup wrote:
| lazygit supports vim style keybindings and mouse click and
| scroll. I mostly use the key shortcuts but sometimes the mouse
| is useful. But i agree that a well thought out state machine
| that can be navigated through via keyboard is a dream to work
| with. Lazygit is superb. But this is not a distinction between
| TUI and GUI.
| Trufa wrote:
| I think your comment is nonsensical.
|
| Zellij among is a great example, I can do everything with my
| keyboard, but every now and them I'm already with the mouse and
| just click a tab or pane, no functionality lost, just added,
| why the need to make a cutoff philosophical/semantic hard
| argument?
| whiteboardr wrote:
| As a german, I say:
|
| UIUIUI
| JodieBenitez wrote:
| I like TUIs keyboard-centric. Mouse can be a plus, but it
| should never be necessary.
| tracker1 wrote:
| That's fair... I feel that way about GUIs too in general
| though. Everything should be keyboard navigable and
| reasonable control flows. Tab and arrows, etc. Should be able
| to control focus and selection (enter).
|
| I admit I don't always pay the most attention to it, as the
| UI components I tend to use do a good enough job of this. But
| I'm usually pretty consistent with it.
| JodieBenitez wrote:
| Yes, even GUIs benefit from having good keyboard
| navigation.
| cmrdporcupine wrote:
| Man, I've had so much frustrating just trying to copy & paste
| from inside a terminal running e.g. opencode or crush.
|
| I think TUIs are neat, I guess. But I think these things have
| abused the concept extensively. They don't actually interact
| well with the rest of a Unix environment.
| throwawaymobule wrote:
| Hold down a key (alt, I think) to prevent clicks.
| ganelonhb wrote:
| Reddit moment!
| moregrist wrote:
| > But once you start adding mouse clickable tabs, buttons,
| checkboxes etc. you left the UX for TUIs behind and applied the
| UX expected for GUIs, it has become a GUI larping as a TUI.
|
| Hard disagree. Borland TurboVision [0] was one of the greatest
| TUI toolkits of the DOS era, had all of these:
|
| > Turbo Vision applications replicate the look and feel of
| these IDEs, including edit controls, list boxes, check boxes,
| radio buttons and menus, all of which have built-in mouse
| support.
|
| Well, I can't remember if it had tabs.
|
| [0] https://en.wikipedia.org/wiki/Turbo_Vision
| jksmith wrote:
| Vasellating. TurboVision was awesome, but it was pushing the
| boundary of TUI, which in my mind was great for moving hard
| copy to computer entered use case. To wit, hard copy on your
| right side, you transfer data to app without looking at
| screen, but just looking at hard copy, remembering when/where
| to hit return key, maybe tab for prior field, stuff like
| that.
|
| But hey, if the screen is drawn 24 x 80 with extended ascii,
| it's TUI. And man, loved the "absolute" keyword in turbo
| pascal. Instant screen writes when writing to a 2 dimensional
| array.
| weinzierl wrote:
| I don't remember _" absolute"_ but I sure do remember _"
| gotoxy"_ and it rhymes with boxy, yeah, you won't convince
| me otherwise.
| jksmith wrote:
| It was something like screen: array[1..80,1..25] of byte
| absolute $B800:0000; So, just use all the extended ascii
| to assign chars to cells to draw boxes for screens,
| buttons, tables, whatever. Instant update.
| dathanb82 wrote:
| Oh man, Turbo Pascal was my first "real" programming language
| -- it was all various flavors of BASIC before, and mostly toy
| projects. The developer experience with Turbo Pascal (by
| which I guess I mostly mean Turbo Vision) was honestly pretty
| great
| musebox35 wrote:
| My ancient boxed copy of Visual Basic for DOS 1.0 that
| supported mouse clicks on TUI buttons would have found your
| viewpoint quite offensive if it had any AI in it ;-) Oh boy,
| good old days.
| jhbadger wrote:
| You might not like this type of interface, but it is hardly
| "nonsensical". In the 1990s this sort of text-based GUI was
| common in DOS programs, such as Borland's "Turbo" languages and
| the original pre-Windows FoxPro.
| BoredomIsFun wrote:
| > But once you start adding mouse clickable tabs, buttons,
| checkboxes etc. you left the UX for TUIs behind and applied the
| UX expected for GUIs, it has become a GUI larping as a TUI.
|
| TIL that VIM is not cease being TUI the moment I type :set
| mouse=a.
|
| Hot taking, LARPing and teenage angst (caused by generational
| gap with those has been using TUI since 1980s) is on your side.
| jandrese wrote:
| I've been working with notcurses recently and it is a full TUI
| that handles mouse events just fine. Runs over slow SSH
| connections and everything. The nice part is that you can fully
| operate applications built on top of it with the keyboard if
| you so choose, the mouse is just a shortcut.
|
| Sadly the project is not really in a usable state at the
| moment. The documentation is incomplete riddled with errors,
| the code has some pretty glaring bugs, and it's close to
| abandoned. It's a shame because you can do some really amazing
| stuff with it.
| ram90 wrote:
| This is exactly the kind of passive aggressive attitude that is
| tolerated on HN that makes this place unbearable.
|
| "This is dumb" - gets downvoted to oblivion. "This is
| nonsensical + a bunch of absolutely bs reasoning" - second most
| upvoted comment atm.
|
| HN tolerates the appearance of quality discourse over the
| actual thing, and dealing with this dissonance in most comment
| sections is exhausting.
| h3lp wrote:
| Good insight, but if you discount the visual elements (tabs,
| buttons, etc), you're limiting TUI to CLI, and I think that's
| unwarranted. The value proposition of both TUI and GUI is two-
| fold: you see the available action options, and you see the
| effect of your actions. So, yes, TUI and GUI _are_ closely
| related: who cares whether we're displaying pixels or character
| blocks.
|
| Unfortunately, they are often artificially differentiated by
| the style of the UX interaction: TUIs promote the keyboard
| actions, and GUIs prefer mouse without corresponding keyboard
| shortcuts. Unfortunately for GUIs, their designers are often so
| enamored with WIMP that they omit the keyboard shortcuts or
| make them awkward. I hate it when, even if the ACTION button is
| available by keyboard traversal at all, it requires some
| unknown number of widget traversals instead of being one tab
| away.
|
| Since the keyboard is almost always used for the textual data,
| it makes sense to me to always enable it for command execution.
| Well designed GUIs and TUIs provide both WIMP and keyboard UX,
| which sadly is not the norm today, so here's my vote to make
| them larp for each other more.
| temporallobe wrote:
| Yes and no. Early DOS UIs had elements of TUIs and GUIs, and
| supported mice. Many old school greenscreen applications were
| like this too.
| apitman wrote:
| People don't build TUIs because they want to run apps in the
| terminal, they build them because the terminal happens to be
| the most portable app platform available.
| pcmoore wrote:
| Watched the video. Why isn't the editor a TUI itself?
| baranguneysel wrote:
| Great question.
| jappgar wrote:
| Because a website is easier to use and more accessible.....
| elxr wrote:
| This one is not very accessible, try using tab + arrow keys
| to focus anything on the sidebar.
| vidarh wrote:
| I really don't want my TUI's to look like GUI's rendered in low
| res. The appeal to me of a TUI is that it is built specifically
| to be a TUI, and that means _eschewing complexity and detail_ ,
| and favouring compact text.
| zozbot234 wrote:
| > GUI's rendered in low res
|
| That's literally what TUI's looked like starting from the late
| 1980s and throughout the 1990s... You have a pointing device,
| might as well make use of it to enhance discoverability.
| m3kw9 wrote:
| Didn't they evolve from that because better graphics was
| better? Otherwise why not stay text if there is a huge
| advantage in all Text made graphics?
| zahlman wrote:
| This seems really reductive. Some UI paradigms work better at
| 80x24 vs at 640x480 (never mind whatever resolutions we have
| access to today). Or rather, the 80x24 text grid is using
| more pixels than that, but everything is _aligned_ to that
| lower resolution, and that fundamentally changes what makes
| sense to do. Floating windows that can be dragged around to
| arbitrary positions? Terrible for low-res; classic for higher
| res. Dividing lines that split the screen into panels, and
| can be moved around a row or column at a time with a keyboard
| shortcut? Pretty much the opposite (enthusiasts of "tiling
| WMs" might disagree).
| vidarh wrote:
| None of the TUI's I use look like that.
|
| They all have very different structure to what a typical GUI
| look like. E.g. a focus on condensing more information in few
| text cells, and usually not displaying anything extraneous,
| typically rarely using dialogs etc.
|
| There are notable exceptions to that, sure, but as I noted
| that is exactly what I have no interest in.
| duped wrote:
| This is why I don't like TUIs at all, they're really bad at
| displaying complex information, handling complex interactions,
| and discovering how to compose those together.
| vidarh wrote:
| Most of my complex information is text, for which TUI's work
| just fine.
|
| For the rest, I typically use a browser.
| worthless-trash wrote:
| The corners of the boxes appear in the wrong place in the cell.
|
| I don't think there is utf8 characters that allow for drawing on
| the outside of the cell, (happy to be wrong)
|
| + (U+250C), + (U+2510), + (U+2514), + (U+2518) <-- these 4 draw
| in the middle of the cell.
|
| [ (U+FF62), [?], (U+231F), <-- these are two that cover part of
| the outside, but not the other corners.
|
| [++]
|
| Can anyone tells me how to get those 'corner of cell' characters,
| including uprights and horizontals ?
| trollbridge wrote:
| I don't want to be a curmudgeon, but why not just use CSS, HTML,
| React, etc. at this point? You could choose a style that looks
| like a TUI.
| nine_k wrote:
| But will it render in a terminal over ssh?
|
| (I know, I know, port forwarding should work for a web app.)
| trollbridge wrote:
| It actually will given the excellent quality of text based
| browsers now.
| nine_k wrote:
| Agreed.
|
| Another thing that gives the TUI concept an edge is the
| _lack_ of formatting options: no way to make a font too
| tiny or too huge, very little leeway in implementing common
| controls, any excessive whitespace looks jarring, etc.
| Icons are limited to the common emoji.
|
| All this makes you concentrate on providing functionality
| first.
| lagrange77 wrote:
| The background ASCII animation is so cool! Is it an actual
| simulation?
| ksherlock wrote:
| Use the source Luke! It's an "ASCII plasma background" rendered
| into a canvas element.
| jbstack wrote:
| Interesting idea, but:
|
| > Design once, generate production-ready code for your framework
| of choice. Switch targets without touching your design. Alpha
| notice: Code export is not functional yet. We're actively working
| on it -- check back soon.
|
| In other words, it isn't at all usable right now. You can't
| produce a TUI with it, not even a limited one.
| cestith wrote:
| You can still design the layout. That's useful, but not nearly
| as useful as they are planning.
| dymk wrote:
| Why do you believe anything the site claims? It might all be
| hallucinations anyways, and others report not even being able
| to open the app.
| cestith wrote:
| The app certainly opened for me. I don't know that I'd use
| it. Design and layout of an interface is useful apart from
| the implementation though.
| varjag wrote:
| Turbo Vision strikes back
| JSR_FDED wrote:
| One can only dream
| raincole wrote:
| When your TUI is so complex that you need a GUI to design it,
| perhaps you shouldn't use TUI in the first place.
| jbstack wrote:
| I'm not sure that's a fair criticism. Many things require or
| benefit from something even more complex to make them (car ->
| factory, code -> IDE, text -> editor, food -> kitchen). I think
| the real debate here is that which is found in the other
| comments: do we want TUIs to look like GUIs?
| jappgar wrote:
| Why did they make a website?
| MPSimmons wrote:
| This is like QTdesigner but for the terminal. Huh.
| webprofusion wrote:
| Ha, well proof that AI let's you build anything you can imagine.
| Wait till I show you Remote Desktop, one day macOS and Linux will
| catch up.
| sabas123 wrote:
| What is the point of having this if code generation is not
| functional yet? That is the entire point of this app.
| moron4hire wrote:
| To show off an AI generated website
| rvz wrote:
| Exactly.
| nick_ wrote:
| TUIs are very in right now. Nostalgia/vintage-computin-
| aesthetics & guru-gatekeeping around command line savviness are
| front and centre in the HN-and-adjacent mindshare.
| GalaxyNova wrote:
| It's strange. For decades we've been trying to move towards
| GUIs, now we're moving backwards.
| keithnz wrote:
| I think it's AI tools, they are often done as tuis, they work
| well with text, the cli is a text processing god that is easy
| to extend with cli utilities, and since you find yourself in
| the terminal much nicer having TUIs quickly available,
| editor, git client, etc. I love the shift to the terminal as
| I use it a lot anyways (I'm old), but the missing piece for
| me is having a good sql tui client that does at least some of
| what data grip does. So I'm building my own as an experiment
| into agentic coding something from scratch (which I think
| what this TUI Studio is also). Surprised how good it is but
| also surprised how much time it takes to get things polished.
| SvenL wrote:
| So we're going full circle here right? Can't wait for the first
| TUI MVC/MVVM/MVP/M-whatever framework to show up.
| __alexs wrote:
| The TUI hype seems like nostalgia for COBOL mainframe apps that
| most people have never even used. A sort of secondhand cyberpunk
| role play with zero focus on actual UX.
|
| Also if TUIs are so great, why isn't this a TUI app?
| PunchyHamster wrote:
| TUIs are great coz they work seamlessly over shell, but there
| is no reason for that for editor.
| nobleach wrote:
| Have you ever watched someone USE those COBOL TUIs? Everyone
| from airline ticket agents, to local governments, to folks at
| Home Depot while looking up inventory. They could fly through
| menus and accomplish things. I remember when Best Buy switched
| to a Windows-based experience. It was terrible. Simply adding a
| mouse+windowing experience slowed everything way down. I saw it
| first hand at Target too. They went from an OS/2-based TUI to
| Windows NT. I know there'll always be those folks that think
| we're all just trying to play "leet Haxorz", but there's just
| something about those systems that people deeply connected
| with.
| elxr wrote:
| I personally think the opencode and kilo CLI have great UX,
| certainly better (and easier to use) than the web versions of
| both.
|
| A lot of the recent TUI apps are really not old-school in any
| way. Not all apps need the feature-set of a browser engine. And
| compared to native mac/linux desktop apps, TUIs get cross-
| platform support by default.
|
| > Also if TUIs are so great, why isn't this a TUI app?
|
| We all know the answer to this
| elxr wrote:
| The fact that this isn't a TUI itself is a bit disappointing.
|
| The fact that even the preview isn't a TUI is just lame. Keyboard
| controls are also non-functional right now.
| _pdp_ wrote:
| Am I the only one who thinks the recent TUI explosion is
| absolutely not necessary?
|
| I mean yes, code editor are great for this but a lot of the TUIs
| I see are so slow it begs the question why they exist to begin.
| CLIs are supposed to be remixable and scriptable.
|
| I think a better architecture would be to generally keep CLIs
| work like CLIs and have separate processes that add terminal
| rendering functionalities for those that need / want it but in
| general it is an anti-pattern to start from this as default.
| mikkupikku wrote:
| Of course it's not necessary, it's a fashion. Choosing to make
| a TUI instead of a GUI is a fashion statement, it signals
| aesthetic alignment with nerdy shit and says the program isn't
| meant for common proles. There's pretty much nothing a TUI can
| do that a GUI can't do, while the opposite is very much not the
| case.
| frou_dh wrote:
| See also all the programmer blogs that feel the need to use a
| monospaced font for prose, to signal that they're a
| programmer.
| javier123454321 wrote:
| That's roughly aligned with my thinking. Make it a CLI. And if
| there's a lot of configuration that you can pass to it, have an
| option for rendering those options as a TUI.
| drob518 wrote:
| Depends highly on the specific application. Take a simple
| example of looking at process usage. You can use ps from the
| command line to get all sorts of info about a process. But
| there's no substitute for top to show you an updating list of
| top cpu consumers, which ps just can't do.
| vendiddy wrote:
| I feel like they are a workaround to GUIs being slow and
| bloated Electron apps.
|
| But I wish we'd just make fast GUIs instead of giving up and
| building TUIs instead.
| moron4hire wrote:
| Anyone notice the computer image at the top of the page doesn't
| have the right number of keys?
| NSPG911 wrote:
| Nope, check out something like wiretext, look at this example I
| put together very quickly
|
| https://wiretext.app/w/WUtjS1bk
| igtztorrero wrote:
| I want something like that, but for Bootstrap,Tailwind or Quasar
| pjmlp wrote:
| Turbo Vision and Clipper want their glory MS-DOS days back.
| reaperducer wrote:
| And Ashton-Tate's Framework IV on an 8088 with a MDA display.
| xvilka wrote:
| Nowadays we have Unicode characters and better colors though.
| pjmlp wrote:
| MS-DOS always had better colors than UNIX, a framebuffer
| isn't the same a vt100.
|
| I do agree Unicode is better than code pages, or doing alt +
| num pad codes.
| jiehong wrote:
| The lack of accessibility of TUIs is not great in general.
|
| I'd much rather terminals emulator provide a webview directly,
| and maybe use https://webtui.ironclad.sh/ if you really want the
| look.
|
| I think it makes more sense for a cli to offer a mini webserver
| instead.
|
| Think `fish_config`, but opened in the terminal directly [0].
|
| [0]: like https://iterm2.com/browser-plugin.html
| xwiz wrote:
| > The lack of accessibility of TUIs is not great in general.
|
| Interesting. In what ways? I haven't heard anyone express this
| concern before.
| jiehong wrote:
| Depending on how the TUI is made, it can be very visual, but
| lacks structure for a screen reader (unless you stay in the
| very simple "input field: value" kind of prompt, but even
| then auto completion is tricky).
|
| Web browsers offer the DOM to tools such as screen readers
| (OSs offer their own accessibility sdks). Someday perhaps the
| TUI application could talk to the terminal emulator that
| would itself talk to the accessibility sdk of the OS and that
| info would somehow then be accessible.
|
| There was a beginning of discussion at bubble tea[0] about
| this for example.
|
| [0]: https://github.com/charmbracelet/bubbletea/issues/780
| duskdozer wrote:
| TUIs seem like they should be well-suited to screen
| readers, but yeah accessibility is often unfortunately far
| down the list on average project priorities.
| BoredomIsFun wrote:
| TUIs sadly have become niche tech, and accessibility is
| rarely a concern for niche things.
| seertaak wrote:
| A UI design tool for TUIs -- made with Electron?... fun times!
| elxr wrote:
| You can run it as a web app, no need for electron.
|
| Just `bun run dev`
| rvz wrote:
| That is concerning.
| corysama wrote:
| I give it a month before someone launches a TUI-TUI.
| giancarlostoro wrote:
| We got a RAD IDE for terminals before GTA6 and before anyone
| sensibly makes a replacement for Electron. Wild.
|
| This is really cool though.
| drob518 wrote:
| I seem to remember having a RAD IDE for terminals with Turbo
| Pascal back in the 1990s. But yea, still before GTA6.
| delduca wrote:
| For {root} sake I'm a designer. Mostly all the code has been
| written by Claude and ad latere.
| butlike wrote:
| Probably why the actual product, the code export, isn't
| working. I doubt it ever will. Neat toy, though.
| rvz wrote:
| No idea why this is hyped up these days.
|
| The only reason I can think of is what I said before [0] given
| that the web was destroyed by the same web developers, then so
| was the desktop (with Electron) and now of all places terminals
| are now getting destroyed with infinite slop like this.
|
| This nonsense will continue and accelerate until it reaches
| hardware.
|
| [0] https://news.ycombinator.com/item?id=47210187
| sunaookami wrote:
| Vibe-coded trash, even says so in the Readme. Not sure why this
| gets voted to the frontpage.
| bonoboTP wrote:
| Better get ready for almost all software to use AI assistance
| in its creation.
|
| You can build great things using AI agents, and you can build
| trash.
|
| Your ideological opposition to that is not shared by as wide a
| percentage of developers as you may think based on some highly
| self selected online corners.
| slopinthebag wrote:
| Of course you can build great things with AI, but trash
| written by AI is worse than trash written by a human, and
| some things are just trash.
| sunaookami wrote:
| Way to read something into what I have never even wrote and
| try to spin it as something ideological. This is not "AI-
| assisted", it's _completely_ vibe-coded by AI and the
| software doesn 't even make sense since you can't export
| anything. It's just low-quality trash dumped on Hacker News
| and I'd argue this is not the place for it.
| mghackerlady wrote:
| theres a difference between AI-assistance and vibe coding.
| One of them requires you to know what you're doing and make
| good design choices
| butlike wrote:
| It's not anything though. It's a website and electron app
| that promises functionality that completely isn't there. It's
| useless, but instead of being art, it promises functionality,
| so it's functionally trash.
|
| I too remember running `rails new MyGreatApp` and having hoop
| dreams of being the next billionaire entrepreneur, but a
| boilerplate app is a boilerplate app.
| mpalmer wrote:
| Your ideological opposition to that is not shared by as wide
| a percentage of developers as you may think based on some
| highly self selected online corners.
|
| Opinions do not win by "high score". Asserting the validity
| of opinions based on how widely they are held is dumb.
|
| If 30% of devs love openclaw, I'm not re-examining my
| informed opinion, I am forming a new one about that 30%
| cohort.
| bonoboTP wrote:
| That was a reaction to "Not sure why this gets voted to the
| frontpage.", not to any correctness claims.
| dlopes7 wrote:
| Not gonna like, I am having to actively fight the aversion I
| feel when reading something was "all written by claude", it
| is so hard to check if it was properly done or pure garbage,
| I don't even take the time to check.
|
| I know this position is wrong, but it feels hard to spend my
| time on something that someone else might not have spent the
| time to create
| xvilka wrote:
| Missing Ratatui[1] support.
|
| [1] https://ratatui.rs/
| WhereIsTheTruth wrote:
| This website eats a whole CPU core
|
| Another W from the web developers mafia
| uaghazade wrote:
| +1 on this
| injidup wrote:
| I'm not sure the utility of this kind of stuff anymore. It's
| relatively easy to sketch a layout on a napkin + prompt and then
| prompt claude code to use python textual as as TUI layer. I've
| had pretty good success with Textual+Claude so have a few
| colleagues. You could probably use Figma + claude etc as well.
| mihir_kanzariya wrote:
| The biggest pain point with TUIs has always been the design
| iteration loop. You're basically writing code blind, running it,
| tweaking numbers, running again. It's like writing CSS without a
| browser preview.
|
| Something like this could genuinely help for the
| layout/positioning phase, even if you still hand-write the
| interaction logic. The debate about whether these are "real TUIs"
| kind of misses the point imo. Textual and Ratatui already blur
| that line with mouse support and rich widgets. The ship sailed on
| pure keyboard-only text interfaces a while ago.
|
| What I'd actually want from a tool like this is to export to
| multiple TUI frameworks. Right now you're locked into one
| ecosystem and the code export isn't even working yet, which makes
| the whole thing feel premature.
| apitman wrote:
| A TUI library with hot reload would be pretty cool
| chuckadams wrote:
| Gotta say I did sort of expect this to be a TUI app itself.
| voidUpdate wrote:
| If you're going to put a video demo on your main webpage, can it
| have play/pause and a control bar? So I can actually skip to a
| part I want to look at. Here's the actual video:
| https://tui.studio/screenshots/video.mp4.
|
| Also, how does this handle terminal resizing? Are there options
| to anchor elements to the left/right etc, or will narrowing the
| terminal window just make everything fall off the side, or worse,
| all the text wraps?
| sorenjan wrote:
| You can right click on it and choose "Show controls", at least
| in Firefox.
| voidUpdate wrote:
| Oh, that's odd, it didn't show up on chrome when I first
| tried it, but it does now. I was wondering how they'd managed
| to hide the video context menu
| stanac wrote:
| It's probably just <video> element without "controls"
| attribute.
|
| https://developer.mozilla.org/en-
| US/docs/Web/HTML/Reference/...
|
| > controls
|
| > If this attribute is present, the browser will offer
| controls to allow the user to control video playback,
| including volume, seeking, and pause/resume playback.
|
| Edit: I misunderstood, you are asking
|
| > how they'd managed to hide the video context menu
|
| Not sure, but it works in FF for me
| voidUpdate wrote:
| Its entirely possible I did something to it accidentally
| that made the context menu not work properly. I had the
| dev tools open to pull the actual video address when I
| right clicked, so I might have messed something up. Or
| maybe the devs are secretly looking at the comments and
| fixed it between me and you trying :P
| sam1r wrote:
| It won't let me reply to parent's child comment, but i
| wanted to say:
|
| That is what HN is for!
| sandos wrote:
| I would be REALLY REALLY impressed if it manages to do this
| without bugs. Just using pythons textual can be very complex,
| belive it or not. Maaging not only to that but other frameworks
| too sounds insanely complex. I have a strong feeling this is
| vibecoded from the commit history?`
|
| Ah yes, it says clearly that on the github page. Still, if its
| works, I am then impressed by the LLM.
|
| Edit: It does, in fact, NOT work for code export. Level of
| impressiveness massively dropped.
| shimman wrote:
| Yeah, the website has many bugs too. Literally can't click on
| 50% of the "clickable" stuff. Not impressed by vibe coded
| nonsense. The comments here are weird, people are discussing
| the "idea" rather than the broken implementation.
|
| Probably a bad omen of things to come for the internet.
| deevelton wrote:
| Have been spending so much time in the terminal lately for the
| first time in my life (non-developer here) that made this for fun
| to spruce it up: https://github.com/dvelton/terminal-profile-
| studio
| spiffyk wrote:
| Funny how you can tell a project is vibe-coded just from a first
| glance at its website. All these websites seem to somehow have
| the same visual style. Anyone noticed this?
| duskdozer wrote:
| Yep, my fans started revving as soon as I loaded it. Animations
| are out of control on the normal web as it is, but genAI sites
| take it to another level.
| spiffyk wrote:
| That, too, though I'm sure that particular problem is mainly
| because of the textual animation in the background.
| duskdozer wrote:
| Yeah it was. I've been hoping to get the time to write a
| userscript to identify and stop animations like that, but I
| haven't been able to understand the whole
| requestAnimationFrame thing enough yet.
| choward wrote:
| Same, and it lags simply trying to scroll down the page.
| Unacceptable.
| zahlman wrote:
| This is why I recommend NoScript.
| stldev wrote:
| Ignore the haters. This is an excellent idea, I'm getting some
| old Borland vibes. Keep it up, can't wait to see where it goes!
| boca_honey wrote:
| Ignore the haters, sure. But don't ignore the well argumented
| criticism that you're getting from an overwhelming majority of
| your peers, as it's happening right now.
|
| >can't wait to see where it goes!
|
| Fall into this toxic positivity nonsense at your own peril.
| majkinetor wrote:
| Toxic positivity? At your own peril? OMFG.
|
| Let's imagine one do. What do you think can actually happen
| that is so negative? Toxic TUI will hunt you in dreams?
| dymk wrote:
| It doesn't even exist, you're getting excited for a
| hallucination.
| mpalmer wrote:
| Gatekeeper blocks the app immediately. You'll see either
| "TUIStudio cannot be opened because it is from an
| unidentified developer" or "TUIStudio is damaged and can't
| be opened" on newer macOS after quarantine flags the
| binary. To get past it: right-click the .app - Open
| - Open anyway -- or go to System Settings - Privacy &
| Security - "Open Anyway".
|
| A trusting, highly positive person could really be taken
| advantage of here.
| BoredomIsFun wrote:
| "Majority of peers" has never experienced proper TUI in their
| life, and their opinion is hardly relevant.
| pelcg wrote:
| If you want inspiration on all kinds of TUIs on show and display
| Terminal Trove [1] is useful to get an idea for what other tools
| look like.
|
| I find the search [2] also helpful.
|
| [1] https://terminaltrove.com/
|
| [2] https://terminaltrove.com/explore/
| Archit3ch wrote:
| Somewhat related: Tachikoma.jl can do _windows_ inside a terminal
| UI. https://discourse.julialang.org/t/ann-tachikoma-jl-a-
| termina...
| sorenjan wrote:
| I wonder if one of the LLMs could generate code from a screenshot
| of a layout designed by this.
| anonu wrote:
| Claude Code built a TUI for me last night, in this case to step
| through nanosecond timestamped ITCH market data messages and
| rebuild an order book visual in the terminal. This type of
| stuff would have taken a day - but done in 5 minutes now.
| TrevorFSmith wrote:
| This is a vibe coded app and isn't what I'd want but still, it's
| interesting to consider what a good implementation of "Figma for
| TUIs" could be, especially if it avoids the trap of simply
| treating the console as a crude raster instead of taking
| advantage of text and keyboards. IMO we don't need WIMP GUI
| shoved into terminal emulators.
| __mharrison__ wrote:
| The irony that a TUI studio is not written as a TUI...
| ganelonhb wrote:
| The one thing these always miss is image protocols. Do you plan
| to support terminal image protocols like sixel, kitty image
| protocol, etc.?
| dangoodmanUT wrote:
| There's something incredibly ironic about a visual tool for
| designing TUIs...
| ramon156 wrote:
| No ratatui?!
| aavci wrote:
| This looks really cool. Is the use case of getting an LLM to
| respond with custom TUIs something you have thoughts about?
| ifh-hn wrote:
| Why are these things being built on web technologies? There's
| loads of "modern" terminals that use typescript etc. to me
| terminal means lower level.
|
| Also wheres the Linux version? You've Mac, windows, and docker.
| When someone says terminal to me I default to Linux.
| auvi wrote:
| For exports, it is missing the ultimate: Borland Turbo Vision,
| the Rolls-Royce of TUI frameworks.
| tracker1 wrote:
| Half surprised there's no raratui export with the other options.
| That said, probably lends itself more to Ink and @opentui/react.
| Also slightly disappointed at the lack of a direct Linux build
| for AppImage and/or Flathub. Also not using Github's releases
| which is a little curious.
| nout wrote:
| That's cool. I literally vibed something similar a month ago for
| myself!
| Myrmornis wrote:
| TUIs built today should be usable by AI agents. I'm not sure
| exactly what it looks like but I'm imagining that every UI view
| has an associated CLI command that can yield precisely that view.
| Maybe like formally structured breadcrumbs, or maybe like Emacs
| "keyboard macros".
| kees99 wrote:
| Agents excel at using CLI tools with well-written "--help". So
| maybe consider that instead of TUI.
| Myrmornis wrote:
| Yes, they do, but the premise in my comment (and this
| discussion) is that a TUI is being written today.
| apitman wrote:
| I've found agents effective using GUI apps with nothing but the
| ability to take screenshots and send mouse and keyboard
| commands. I imagine they'd work even better with a TUI, even if
| it's not designed with agents in mind at all.
| Venkymatam wrote:
| this is a cool idea lol but is a pretty nonsensical explanation
| of what you can even do with it
| monkaiju wrote:
| I wish HN had flairs (tags) like Reddit and mandated a few for
| AI-related work (AI-Assisted, AI-meta, AI-vibecoding) or
| something so these could be filtered out
| aaronblohowiak wrote:
| So this is a TUI WYSIWYG GUI ?
| oefrha wrote:
| I really hate these pointlessly dynamic website backgrounds that
| make mobile devices hot to touch. Unfortunately vibe-coded
| websites love these.
| NoGravitas wrote:
| Missing ncurses support.
| visarga wrote:
| I built something like this in 1993, it was used to design
| layouts for DOS apps and headers for printed listings. Imitating
| the BorlandPascal and Novel TUIs of the day
| gaigalas wrote:
| Seems nice.
|
| I launched https://github.com/alganet/tuish yesterday (pure shell
| backend).
|
| Exporting to pure shell could be a killer feature, especially for
| smaller and ad-hoc apps (no dependencies, no compilation, etc).
| ctmnt wrote:
| On one hand this is a neat idea. I've thought about how nice it
| would be to have a visual layout tool for text-based designs. The
| current offerings are slim. Of course, you could easily argue
| that if you need a visual tool for it, you've gone too far; even
| the most sophisticated TUIs are still extremely simple.
|
| On the other hand, for this work as they describe, it needs to be
| a complete UI framework across a bunch of languages and built on
| top of a bunch of existing frameworks. That seems... ambitious.
| Building one UI framework for one language is plenty hard enough.
| jbverschoor wrote:
| Guess who's back, back again?
|
| VB's back, tell a friend.
| pillsburycat wrote:
| This looks really cool. However, the current AI models are pretty
| good at designing UIs from prompts and even turning screenshots
| of mocks into full UIs. I'm not sure this visual design approach
| would save time vs simply prompting an AI agent.
|
| That being said, I could see a niche market for a designer
| persona who is used to building in tools like figma.
| ajspig1 wrote:
| also, this assumes humans are still the primary CLI consumers.
| With agents increasingly being the first-class users of
| command-line tools, building visual design tooling for terminal
| UIs feels like optimizing for a shrinking audience.
| pillsburycat wrote:
| Well you still need some human prompting the AI and looking
| at results, no? :)
|
| Agents aren't picky with UI, so most effort will always be
| spent designing for humans, even if they are not the primary
| consumers.
| zahlman wrote:
| Apparently we now write desktop applications intended for
| designing the UI of other desktop applications, in TypeScript
| that runs in a Docker container, using a bunch of web frameworks
| (including for CSS) and self-hosting an nginx server?
|
| I would have expected a TUI editor to be itself a TUI.
| evrenesat wrote:
| In this age, rich TUI's feels wrong to me. Tools that expose a
| minimal web server with a lightweight UI is much more welcome
| than a complex TUI. But for most interactive terminal apps, it
| feels more natural when there is a single input at a time, like a
| wizard interface.
| IAmGraydon wrote:
| This is so cool.
| GrinningFool wrote:
| A number of years ago I hacked together something conceptually
| similar [1]. It was for design and demonstration of CLI tooling
| (not TUI). It used its own DSL which included command definitions
| and demo output for invocations.
|
| It created a replica CLI that behaved the way the real thing
| would, for quick prototyping and design feedback. The next step
| [2] would have been generating backend for different
| languages/libraries to create the actual CLI.
|
| I lost the original sample "buddy" files but we did use it for
| prototyping a new Chef Workstation cli. Copies still haunt the
| Internet [3]
|
| [1] defunct, https://github.com/marcparadise/clibuddy
|
| [2] had I continued to need it
|
| [3] https://github.com/gridgentoo/chef-
| workstation/blob/master/d...
| binary132 wrote:
| The fact that this app isn't itself a TUI is kinda telling, tbh.
| swyx wrote:
| OP if you care to indulge - why did you decide to work on this?
| vs just work on a TUI directly.
| docmars wrote:
| This is amazing! Just think how incredible this would have been
| to have in the 80's and 90's in some similar format.
| montag wrote:
| Gonna see if I can implement https://chiptune.app in an actual
| TUI with this.
___________________________________________________________________
(page generated 2026-03-13 23:00 UTC)