Live data from Hacker News

Ink: React for interactive CLI apps

github.com

61–70 of 109 posts

Re: Ink: React for interactive CLI apps

#61
post #45

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…

> the most robust type-system in the world (Typescript) The rare combo of Blub Paradox + Poe's Law

What would you consider to be more robust, while still being usable? I'm referring to the type system here specifically.

Re: Ink: React for interactive CLI apps

#62

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.

How would performance be a concern for rendering the UI of a terminal app? Surely that happens in less than 0.001% of all cases. And of course no one in their right mind is implementing the core functionality of their app with react state variables. (Right..?)

Re: Ink: React for interactive CLI apps

#63
post #27

Earlier quoted context omitted.

Some people here seem to have a hard time understanding that React !== DOM React is descriptive. It creates a virtual tree and tells how that tree should be changed. What that tree renders into is a completely different problem. On the web, it renders into HTML. On your phone (ReactNative), it renders into native GUI. In ink, it uses a render engine to concat and output the text results (it's a little more complex th…

Is there a good resource that explains what React is and how it works, without limiting the focus to just the usual web applications?

It's a bit older (and focused on web), but you can try this

https://github.com/pomber/didact

At a high level though, you create a tree of nested objects. Each has a handful of special properties (children which contains an array of child objects being the most interesting to users). The rest of the properties are used to interface with the rendering engine by passing it configuration and (usually) event functions it can call when something happens.

That tree of objects gets passed to the rendering engine which turns the tree into some kind of output (DOM, Canvas, WebGL, Ink, etc)[0].

When something happens (an external event, a timer, event from the render engine, etc), your code potentially changes the object tree. React then walks that tree and uses a few shortcuts to quickly detect what has changed. Instead of re-rendering everything, it can give a list of things that have changed and what the new values are. The render engine then decides how to make those changes happen and the cycle repeats.

It's really pretty simple.

[0] https://github.com/chentsulin/awesome-react-renderer

Re: Ink: React for interactive CLI apps

#64

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…

> the most robust type-system in the world (Typescript) This is very high praise for something that only provides safety at compile time and not runtime.

Not to mention:

      type Thing = string | boolean;

      const arr: string[] = [];

      function add(item: Thing, dst: Thing[]): void {
        dst.push(item);
      }

      add(false, arr);

Is valid typescript.

Re: Ink: React for interactive CLI apps

#65

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…

> React combines the most robust type-system in the world (Typescript)

By what measure?

Your comment reads like you have something to sell me.

Re: Ink: React for interactive CLI apps

#66
post #25

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.

Half the tools I write end up being used in CI/CD so even if I do fancy in a terminal you have to do simple for non interactive shells.

Re: Ink: React for interactive CLI apps

#67
post #27

Earlier quoted context omitted.

Some people here seem to have a hard time understanding that React !== DOM React is descriptive. It creates a virtual tree and tells how that tree should be changed. What that tree renders into is a completely different problem. On the web, it renders into HTML. On your phone (ReactNative), it renders into native GUI. In ink, it uses a render engine to concat and output the text results (it's a little more complex th…

Is there a good resource that explains what React is and how it works, without limiting the focus to just the usual web applications?

In addition to the excellent "Didact" article that explains how to _build_ React and its internals, I have an extensive "Guide to React Rendering Behavior" post that explains the user-visible behavior and mental model of rendering:

- https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...

I can also recommend Dan Abramov's post "React as a UI Runtime":

- https://overreacted.io/react-as-a-ui-runtime/

and then of course the actual React docs for learning how to _use_ React:

- https://react.dev/learn

Re: Ink: React for interactive CLI apps

#68

Earlier quoted context omitted.

> the most robust type-system in the world (Typescript) This is very high praise for something that only provides safety at compile time and not runtime.

Not to mention: type Thing = string | boolean; const arr: string[] = []; function add(item: Thing, dst: Thing[]): void { dst.push(item); } add(false, arr); Is valid typescript.

If you are used to structural typed systems though this actually "feels" expected. Don't get me wrong, I know where you are coming from. But the realisation comes from nominal systems, which are different beasts. As long as it actually evaluates to the expectations in the head of the developers using it, then that's okay.

However, regularly it's not the case -- especially with people moving from nominal systems.

TS can't really be practically nominal when it has to be constrained by its compile target. So I guess it ultimately boils down to an anomaly/criticism born from the legacy of how web standards came about.

Re: Ink: React for interactive CLI apps

#69
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.

Re: Ink: React for interactive CLI apps

#70

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.

The "should we use node for the core business logic for my use case" thing is absolutely valid and depends.

But you'd be surprised about the "react for the front end of the CLI" part. I used this thing a whole six years ago in a complex interactive CLI and it came off great to use, maintainable and ergonomic. React is just one framework that proscribes to the "UI as declaritive/composable trees" pattern. And that UI doesn't have to be web based. That pattern works for all UI's I've come across.

Its the pattern that is a good reason to do this. And not react/js landscape. That part is probably a bonus for many though.

Post reply on HN