Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ink: React for interactive CLI apps

github.com

Post reply on HN
Print view View original

81–90 of 109 posts

Re: Ink: React for interactive CLI apps

#81

Post by timeon »

seveibar wrote: post #12

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…

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

Are you serious?

Re: Ink: React for interactive CLI apps

#82

Post by timeon »

mardifoufs wrote: post #61
wyager wrote: post #45

Earlier quoted context omitted.

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

Anything with proper algebraic data types.

Re: Ink: React for interactive CLI apps

#83

Post by cyberax »

itronitron wrote: post #28

I'm curious how developers that use React, but have never written an application using the MVC paradigm, would describe React.

React is nice, but it has some sharp edges.

Basically, you're logically re-rendering _everything_ on every render. The React engine then diffs it with the last state, and then applies necessary actions to reconcile them. As a consequence, your rendering code is invoked by React, and you have to follow some rules to make sure that React doesn't have to _physically_ re-render everything.

Another consequence is that physical component creation is taken out of your hands.

This works great, if you're doing something with tons of simple components.

It works less great if the actual rendering is a complicated task. E.g. you're making a map widget, or a 3D editor. You might be better off not using the reactive approach, and fall back onto the classic MVC.

Re: Ink: React for interactive CLI apps

#84

Post by CGamesPlay »

johnfn wrote: post #62
cupofjoakim wrote: post #5

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..?)

Haven’t used this library, but the answer is the same as it is for real React apps. How does this application perform if I have a scrollable view with 50,000 items in it and I press the down arrow? This kind of thing is why React can be the cause of bad performance.

Re: Ink: React for interactive CLI apps

#85

Post by yesthisiswes »

bcherny wrote: post #23

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.

This! I hit both of these issues. I tried building a solitaire game using ink. I couldn’t stack and offset the cards on top one another so they took up a lot of screen real estate. Then when I had re-renders the screen would flicker. Other than that it was a joy to use. I think I even tried flipping the solitaire board horizontal but that felt too weird.

Re: Ink: React for interactive CLI apps

#86

Post by russellendicott »

seanw444 wrote: post #3

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…

This is my side hobby, a server side TUI protocol with a light browser like client that can navigate any TUI.

http://uggly.bytester.net

The primitives are good enough to build anything you want. Right now I'm trying to figure out how to make better libs and tooling for creators (mainly myself) so I can crank out lots of examples apps that showcase the power of TUIs where you don't need a dedicated executable for each one.

Re: Ink: React for interactive CLI apps

#87

Post by gausswho »

evantbyrne wrote: post #43

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.

The creator handed over control in May due the invasion of Ukraine.

Re: Ink: React for interactive CLI apps

#88

Post by johnfn »

CGamesPlay wrote: post #84
johnfn wrote: post #62

Earlier quoted context omitted.

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..?)

Haven’t used this library, but the answer is the same as it is for real React apps. How does this application perform if I have a scrollable view with 50,000 items in it and I press the down arrow? This kind of thing is why React can be the cause of bad performance.

How many terminal apps do you know of that have 50,000 items with a scroll wheel? This is what I meant by 0.001%.

Re: Ink: React for interactive CLI apps

#89

Post by mrbombastic »

CGamesPlay wrote: post #84
johnfn wrote: post #62

Earlier quoted context omitted.

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..?)

Haven’t used this library, but the answer is the same as it is for real React apps. How does this application perform if I have a scrollable view with 50,000 items in it and I press the down arrow? This kind of thing is why React can be the cause of bad performance.

What kind of TUI are you making that requires a scrollable view of 50k items?

Re: Ink: React for interactive CLI apps

#90

Post by mardifoufs »

FridgeSeal wrote: post #74
mardifoufs wrote: post #61

Earlier quoted context omitted.

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

Rudy, Haskell, Ocaml are obvious examples.

Agreed. I just think that those are (sadly, as I like OCaml) apparently not very practical, at least not according to most people. As far as "widely used languages" (which is a totally subjective concept I realize that!), TypeScript has a pretty solid type system. One of the most robust that is widely used.
Post reply on HN