Get the top HN stories in your inbox every day.
toppy
midoBB
I highly recommend Bubbletea. I used it for an internal tool, and it combined with Viper makes an easy-to-use TUI application development easy. Though it uses an approach more similar to Elm than to React.
rochak
Which is an advantage in my book
igravious
I just searched for a Ruby TUI to add to your list of TUIs for different popular languages and was very surprised at what I stumbled across:
loo
[it's Ruby Tui, the New Zealand Rugby Union player, grid of photos heading]
fbdab103
Is tui-rs actively maintained? Currently 52 outstanding pull requests and last commit was ~9 months ago.
azemetre
It has been forked and actively maintained on [1] ratatui crate.
You can see this discussion post about it [2].
xixixao
Just FYI that neither use React or anything close to it, they follow the “immediate” rendering approach.
igravious
A list of Terminal UI libraries for Ruby sorted by number of rubygem downloads.
https://www.ruby-toolbox.com/categories/terminal_ui?display=...
EddieRingle
There's also Mosaic, which is an experiment of sorts to build console UI using Kotlin and Jetpack Compose: https://github.com/JakeWharton/mosaic
glenngillen
There’s also r3bl for Rust: https://crates.io/crates/r3bl_rs_utils
aloer
I recently used Ink to build a small debugging CLI for a websocket-heavy project of mine. All it does is subscribe to a specific channel and print out the message or send dummy data when I press a specific button. The frontend websocket code could be reused easily so it was very fast to do.
Very convenient to run multiple terminals as multiple clients in parallel. Much nicer at least than something like Postman for Websocket tests.
Full screen took some time to get right and still flickers when using iterm 2. But it does work on the apple terminal and for now I am happy with that.
My only issue is that Ink does not support nested rendering / overlays, i.e. modals.
nonethewiser
What role did Ink serve? I mean couldn’t you have just logged to console?
I’m trying to figure out if Ink enabled you to do something at all, made it easier, or you just liked using it. All of which are fair. It seems like you just liked using it.
alexeldeib
I think it’s rerendering the “UI” on data updates. Basically exactly the readme for ink. It’s a single log line of output, but it’s repainted in place, not appended to stdout.
Sure you can do that other ways. Personally I’d love to build terminal tuis with react component!
gkfasdfasdf
Thanks I have never used react and this comment was very helpful, even after reading the project readme.
twobitshifter
If it’s just a single line using carriage return must be easier, right? I could see it being useful for something like a more complex tui dashboard.
nonethewiser
thank you for clarifying. that makes sense and does sound nice to re-render the same line instead of logging a new line each time. I do think it would be simpler/faster (albeit maybe not nicer) to log a message w/ timestamp to accomplish the same thing, putting this in the "nice to have" category.
aloer
what the other comment said, it replaces output and looks like a proper terminal UI. But it also adds features for hotkeys, progress bars, text input etc.
I have it integrated into a bigger CLI project where only a few commands enter the UI. Most of them just render to stdout and are meant to be pipeable
farhanhubble
I'd be cool to use your approach to build a "frontend" for monitoring Python's TQDM output. Especially useful for multiprocess applications with scores of independent, long running processes like data ingestion pipelines. TQDM does support monitoring multiple processes but is not flexible enough for all use cases.
booi
Would this be suitable for building a terminal-themed react webpage where I’m essentially trying to simulate a terminal?
latchkey
> I recently used Ink to build a small debugging CLI for a websocket-heavy project of mine.
why not just write tests?
i'm getting super down voted on this, but come on... why? this person built some buggy utility and those bugs can end up causing more problems than just writing tests in the first place.
no wonder we end up with such buggy junk software... people... write tests!
throwaway675309
Building a simple debugging tool to monitor your program for possible inconsistently reproducible bugs and having unit tests are not mutually exclusive concept. You're getting downvoted because you're making condescending assumptions about the developer.
latchkey
I'm not being intentionally condescending. it is a valid question to ask that. i come from a strongly tdd background. i can't tell you how many times i've seen people write simple debugging tools only to have the tool be the source of the bug. ever written a println and output the wrong variable, then scratch your head why the results are wrong?
websockets themselves are well debugged, similar to http. years ago, i stopped spinning up a http server just to test my endpoints. now i just call the functions directly. thus, it would be an issue with the OPs code that is sending/receiving. take websockets out of the equation and everything would work fine with tests.
aobdev
Automated testing and debugging are not the same
latchkey
I didn't say anything about automated.
99% of the time, I debug using tests. You write the expected output and then fill in the implementation. If you don't get what you expect, something is wrong with your code and it is easy to run it in the debugger to figure out what is wrong.
At the end of that, you end up with a test and some code that works.
Other people call this TDD.
amne
I would argue that, based on my experience, most of the code I'm debugging is not my code so it really doesn't matter how many tests I write because the problem is I misunderstood how a library or someone else's code I'm using works or there's a bug I can't find just with tests.
verdverm
You're writing code against other's code, the UI seems like overhead over when you can just have a script that can effectively do the same thing.
There is a term called "blackbox testing", which is more or less what we do for 3rd party code | services anyway.
aloer
Not everything can or should be a codified test. There’s a reason postman is a billion dollar product.
Just not as good for websockets
Ink allowed me to quickly add a simple admin and debug UI
vanviegen
> There’s a reason postman is a billion dollar product
I guess so, but is it a good reason? It's a fancy ui for curl...!?
ajkjk
that's not what they wanted to do?
enricozb
I tried (and sort of failed) to build something like this for rust [0] (warning it's broken at the moment).
It's a lot harder than I expected. Especially since the terminal has no notion of focus, and with Rust it's really hard to not just clone everything you get your hands on when writing a UI library. The borrow checker really feels like it gets in the way of features like signals [1], and partial re-renders.
[0]: https://docs.rs/intuitive/latest/intuitive/ [1]: https://preactjs.com/guide/v10/signals/
brundolf
Very neat idea. I love how decoupled React is from the different renderers, and how well its paradigm of "render a tree of things that updates as state changes" translates to different kinds of UIs
blackbear_
React is indeed really neat. At the same time, however, I miss the visual drag & drop GUI designers that were in vogue a few decades ago. HTML and CSS are the tragedy of modern UI design.
_2z1p
The drag and drop GUI designers used to work because most people were using screens that were approximately the same size and resolution for the most part back then. That is no longer the case today when there is pressure to support everything from a smart watch all the way up to a UHD 4K monitor or TV. Fixed layouts are also much more difficult to localize and translate to other languages than modern layout systems.
Cthulhu_
And yet, I found Apple's Interface Builder to work pretty well, for apps that should work on phones and tablets in both portrait and landscape mode.
Mind you, this was a long time ago now.
FpUser
Modern drag and drop designers / components do support flexible layouts
WorldMaker
It's one of those "grass is greener on the other side" situations.
I'm currently bouncing back and forth between VB6 and HTML/CSS and yeah sometimes it is nice to just quickly drag something into place, but other times I really wish I could just use a layout system like CSS Grid (or Flexbox) and give it all the items I need and let it figure out how to lay it out.
For instance, recently I had to edit some "tables" in VB6 that turned out to have been hand-drawn with pixel-perfect lines and changes were incredibly slow and I would have murdered for that to be in HTML/CSS.
Sometimes I like (and miss) the best of both worlds in XAML where it has drag-and-drop design tools, but also the copy-and-paste and handwrite support of XML, and it has modern layout tools like Grids for auto-layouts/responsive layouts.
jalk
And you can search/diff the pure text representation which is a major plus as well. I absolutely hate the workflow of constantly moving the mouse back and forth between the visual components and some gigantic property panel sitting at the edge of the window (index-finger programming). Floating windows are even worse, as they always seem to get in the way, so now also spend time on window ceremony (moving / resizing the "floaters"). In graphics tools(InkScape for instance) I almost always move objects around using the cursor keys as my mouse based positioning skills are just not accurate enough (and I know that I'm not the only one)
Anybody have good examples of tools (graphics editors for instance) that has a good alternative to that clunky property pane?
Shorel
The grid system of wxWidgets also works like that.
It has drag-and-drop design tools, and copy-paste, and it can be written programmatically.
So the best of both worlds exists, and it is just not used enough.
wxWidgets has Python bindings.
seanp2k2
I view the rise of React and especially Electron as the failure of things like GTK, Qt, and e.g. Swing to make a useable cross-platform GUI toolkit that isn't a total nightmare to work with / compile / debug / install / package...it's literally easier to ship [most of] an entire web browser instead. That's insane to me.
selfmodruntime
I said this before, but here it goes. People always wished for the *one stack that would work the same 99% of the time for all available platforms. Now that it's here, they hate it.
Yes, Electron is bad, but there are alternatives in progress. Layouting with HTML and CSS is here to stay. It's like git, the best of all the worst tools to get the job done.
FpUser
>"/ compile / debug / install / package"
Replace "compile" with transpile, "install" with deploy that are the same things anyways and it sounds like most projects done by web developers.
>"That's insane to me"
Congrats
kamikaz1k
you can use drag and drop GUI builders on top of react. there's been a lot of attempts at that. a significant recent effort from Wix: https://www.codux.com/
holoduke
I worked with many different UI kits. From native windows to Ubuntu to automotive to embedded to Android to Apple. I find HTML and css by far the most convenient UI toolkit there is. Never have creating UIs been so easy as with css. A relief it is.
manojlds
That's what a lot of low code platforms are trying to achieve.
rcme
Have you tried WebFlow?
mhink
One of my favorite side projects (from several years ago now) was a custom renderer implementation that let one use React to manage the parts of an Electron app outside the page being rendered. [1] I never found the time to actually go through and make it robust enough to use in a production setting, but I remember being very pleased with how much easier it was to use than the native Electron APIs.
Maybe I'll revisit this sometime. :)
brundolf
Hah, that's pretty cool!
paxys
This looks amazing. Can anyone talk about the added overhead of this? I'm assuming having to bundle all of Node.js/V8 in your executable is one of them. Plus extra processing to re-render the tree for changes.
I'm wondering if this is worth it to use for very simple CLI scenarios that can be addressed by more lightweight libraries like Cobra. Maybe so your client-side business logic can stay more unified?
It's also really funny to me that what is considered the absolute simplest use case in programming – write a program that outputs a line of text to the console – is still not free from the Node/npm/React experience.
lmm
> I'm wondering if this is worth it to use for very simple CLI scenarios that can be addressed by more lightweight libraries like Cobra. Maybe so your client-side business logic can stay more unified?
I'd say yes. Performance will be "good enough". Disk space use or whatever other nonsense HN people love to fret about will be "good enough". And the gains from reusing the same stack everywhere are worth it. I used to think writing little helper scripts in a JVM language (Scala) was an unacceptable overhead, then I realised how low the practical cost was.
pzmarzly
> I'm assuming having to bundle all of Node.js/V8 in your executable is one of them
I guess you could expect Linux distros to come with Node (though it's probably a quite dated release). Looking at standalone binaries, both bun.sh and Node.js are about 30MB. In comparison, Python 3.10 is 9MB and starts slower than bun but faster than Node. Bundling is easy too, you can take a loot at vercel/pkg https://github.com/vercel/pkg
kokanee
React kind of reminds me of English. It is ubiquitous for reasons that essentially boil down to imperialism. It imposes at least as many problems as it solves. There is ample evidence that we were getting along fine (if not better) without it. At some point it became the only language many young people know.
And if React is like English, then using it to write a CLI is like using Webster's dictionary to translate hieroglyphs.
kristiandupont
That may be but at least for my own case, web development became an order of magnitude more pleasant when React came out. I keep an eye on new frameworks but so far, nothing has caught my attention enough for me to switch.
itronitron
Yeah, React has always struck me as a bit of a Frankenstein approach to application development. I don't get the appeal, but then I already know how to develop complex applications. If someone can explain if it has any advantage over any native windowing frameworks I'd be interested in reading that.
PragmaticPulp
> Can anyone talk about the added overhead of this? I'm assuming having to bundle all of Node.js/V8 in your executable is one of them.
The primary use case for this would be CLI apps that are already written in JS or TypeScript.
Trying to use this as a front-end for a CLI app written in a different language isn't impossible, but it's a lot of extra work. You'd be better off looking for a similar CLI library in the language you're already using.
paulddraper
> write a program that outputs a line of text to the console
Stating the obvious, but if you are outputting a line of text to the console, don't use this.
paxys
Why is that obvious? That was exactly my question.
For example using React to generate a simple "hello, world" style website is overkill but not totally unthinkable. Is it worse for the CLI case?
paulddraper
Not unthinkable, but equally dumb.
<!doctype HTML><html><body>Hello World</body></html>
console.log("Hello World")
gofreddygo
"Ink" and "interactive" in the same sentence has a strong association in my mind for Inkle's Ink [1]
pimlottc
This was my immediate first thought as well, I thought it was perhaps a React-based implementation of this existing product.
nicoburns
There is also Rink, a Rust port of Ink that uses Dioxus instead of React for the high-level API https://github.com/DioxusLabs/dioxus/tree/master/packages/ri...
koito17
Ink is amazing for quickly hacking together TUIs. I recently did so with Nbb (Node Babashka) and and enjoyed the experience overall.
My only real complaint is how everything in your VDOM seems to re-render on a state change. IIRC this is being addressed [1], but is something to be mindful of, especially if your users may be using slow machines.
kelseyfrog
Yoga is a great choice for layout here. In my own terminal-based projects, I was initially worried that there would be a mismatch between its intended use (pixel-based layout) and the chunkiness of character-based layout in terminal apps, but I was happily proven wrong. Yoga is a great choice for laying out terminal apps.
I wish there was as nice a library for cascading style sheets in terminal apps, but we can't have it all.
blooalien
> I wish there was as nice a library for cascading style sheets in terminal apps, but we can't have it all.
In Python we have Will McGugan's "Textual" framework which supports a form of CSS designed specifically for terminal apps.
lrobinovitch
Similarly there is Lipgloss for the Go ecosystem
blooalien
Ah, yes … from the `charm.sh` people. They have some nice tools, those folks…
dang
Related:
Ink: React for interactive command-line apps - https://news.ycombinator.com/item?id=14831961 - July 2017 (42 comments)
bilalq
Has anyone ever gotten ink to work with OCLIF and TypeScript? I never could figure out how to get those to play nice together. It's ESM only, and that makes things so much harder.
The ESM transition has by far been the biggest pain point of working with JS/TS these last few years.
EDIT: Got it working. Was still a lot more painful than I wish it was. Definitely not converting anything else to use ESM until the landscape here improves.
Get the top HN stories in your inbox every day.
For Golang there is Bubbletea [1], Textual [2] for Python and tui-rs for Rust [3].
[1] https://github.com/charmbracelet/bubbletea
[2] https://github.com/textualize/textual
[3] https://github.com/fdehau/tui-rs