by seveibar on 11/1/24, 4:36 PM
Ink is great for CLI tools and enables really great tools. People who are saying React only belongs on DOM are missing out- React is the world's most popular and powerful declarative programming paradigm. It's being used for native apps, VR, 3d, CAD and electronics.
React allows you to mix declarative and imperative programming concepts together in an effective way. To give a sense of why this is important: Imagine a CLI built with XML. It'd probably be pretty verbose and have a lot of domain-specific configuration. There also wouldn't be a great typechecker. React combines the most robust type-system in the world (Typescript) with declarative style. It has issues, but being "built for DOM/web" is not one of them.
RE: Ink. A simple example of where it is better than most tools is you can simply import a re-usable "ranger-style" file browsing component, and adapt it for things like exploring a database, a spreadsheet, or an API spec. The potential is very high. Hats off to the author and contributors!!
by oscb on 11/1/24, 5:04 PM
I like Ink as an idea for how to use React creatively. It’s very well done.
At the same I think most CLIs do not need this kind of interaction. It is better to keep them simple and verbose rather than fancy and obscured.
I spent a long time removing Ink from an enterprise tool where it didn’t fit as it was meant more for CI/CD. Not this tools fault of course.
by d4mi3n on 11/1/24, 4:48 PM
I don’t get all the hate. Sure, JS isn’t the most popular language for TUI apps, but there’s always room for more TUI tools and I’d you’re automating things for your JS project this is a pretty natural fit to make your project scripts friendlier to their users.
I think I’d much rather have more nice TUIs than not, regardless of the language they’re written in.
by itronitron on 11/1/24, 5:08 PM
I'm curious how developers that use React, but have never written an application using the MVC paradigm, would describe React.
by bcherny on 11/1/24, 5:03 PM
Ink is awesome, but it does have some rough edges. For example, want to absolutely position something on screen? Not possible. The UI also tends to flicker when you’re doing anything complicated, in a way that can be hard to debug.
by adamscybot on 11/1/24, 7:57 PM
Odd to see this come up. I used it about 6 years ago to produce a CLI for devs. It worked very well and React concepts map cleanly to pretty much any "UI" target as said targets can also be well represented by declarative & composable trees.
Probably, other Ui frameworks could also map, seeing as the declarative/composable tree pattern is ubiquitous now. So it's important to note it's that pattern which enables this, and not a specific framework.
But React is one of the ones that is also more removed from the web target than others.
by seanw444 on 11/1/24, 3:59 PM
Saving the world, one GitHub project README banner at a time.
I don't know how I feel about writing CLIs in JS. Just seems a little bit janky to me, and I don't know why. I wonder if there's any push to have something JSXish in Go, even if it requires a pre-compiler to achieve the syntax, just for CLI apps like this. Then again, maybe I'd just rather stick with something like Nim where you can just have a first-class DSL through the macro system.
by ProfessorZoom on 11/1/24, 4:12 PM
a cli that has a useEffect is so cursed
by insane_dreamer on 11/1/24, 5:02 PM
Nice accomplishment! However, React seems overly complex for a TUI, unless you already work with React in the browser and love JS?
by cupofjoakim on 11/1/24, 4:16 PM
I get that there's a lot of people only comfortable in the js-landscape, but I still think this is a weird tool for the job. If performance is a concern there's no way node is the right thing to start, and react just seems silly to me here. Should be noted that I do a big portion of my day to day work in react - no hate on the framework.
by evantbyrne on 11/1/24, 5:51 PM
Looks like someone reported a dependency vulnerability back in June and never got a response. Seems like one of those projects that is a pretty neat experiment, but users should probably expect to maintain their own fork if they plan to use it.
by akie on 11/1/24, 3:50 PM
I'm unsurprised, disappointed, excited, and surprised at the same time. It's clear that the React paradigm works really well to model user interfaces, and as such it's no surprise that it can be used to build anything from desktop software to apps to websites to command line apps.
Amazing work!
by taskylizard on 11/1/24, 4:39 PM
by magicmicah85 on 11/1/24, 4:47 PM
If your use case is mainly consuming web APIs or providing helper tools around your web framework, I can see why using this would be useful as you could reuse the same libraries you use in your application.
by EddieRingle on 11/1/24, 4:34 PM
See also, Mosaic, experimental terminal UI using Jetpack Compose:
https://github.com/JakeWharton/mosaicSince it's Kotlin, it has backends for the JVM, LLVM, and JS/Wasm, though curiously Jake recently removed the JS target because it wasn't seeing much usage.
by throwaway106382 on 11/1/24, 4:20 PM
just because you can doesn't mean you should
by revskill on 11/1/24, 6:21 PM
React is a kind of declarative programming, not just for the UI !!!!
I could take React as a kind of FP design pattern.
by jacobp100 on 11/2/24, 11:29 AM
I used this at a company that was going all in on micro frontends. You’d clone whatever MFE repos you want, and it would manage package installs, building, and restarting the server after a rebuild. Worked great!
by synergy20 on 11/1/24, 5:10 PM
very nice, write some js/ts with React and use node to run them to get a CLI.
by sirtimbly on 11/1/24, 4:18 PM
JS will eat the software world. So having better tools on par with charm in the go world would be great.