Live data from Hacker News

Ink: React for interactive CLI apps

github.com

101–109 of 109 posts

Re: Ink: React for interactive CLI apps

#101

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.

Can you name a common language with runtime type safety?

Anyway, you can get this with Zod https://zod.dev/

Re: Ink: React for interactive CLI apps

#102

Earlier quoted context omitted.

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.

To me this is expected? Thing is supposed to be one or the other. If I wanted a homogeneous array I would use a generic for the add function, which makes more sense for a function that just pushes to an array anyway.

arr was defined to be an array of strings. How are you pushing a boolean there?

Re: Ink: React for interactive CLI apps

#103

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…

Many of us only use React, because we are given no other choice on extension SDKs for SaaS products, which naturally wrongly contributes to its "popularity".

Re: Ink: React for interactive CLI apps

#104
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…

> Saving the world, one GitHub project README banner at a time.

I can feel snarkiness in this response. I don't like it.

From Ink's author [0] post:

> The time has come though to move on from Ink. Since russia’s full-scale invasion of Ukraine in 2022, everything in my life revolves around the war. And anything else has lost all meaning to me. I no longer have the mental and physical capacity to maintain Ink and give it the attention it deserves.

[0]: https://vadimdemedes.com/posts/moving-on-from-ink

Re: Ink: React for interactive CLI apps

#105

Earlier quoted context omitted.

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

Any log viewer.

Fair example, I haven’t built a log viewer but this might be the wrong choice, or maybe there are escape hatches.

Re: Ink: React for interactive CLI apps

#106
post #88

Earlier quoted context omitted.

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

Since when is the basic pager an exotic terminal app?

A pager doesn’t show 50,000 items at the same time - at least not the ones I use…

Re: Ink: React for interactive CLI apps

#107
post #106

Earlier quoted context omitted.

Since when is the basic pager an exotic terminal app?

A pager doesn’t show 50,000 items at the same time - at least not the ones I use…

I don't see anything in grandparent implying in view at the same time, and that sounds pretty unlikely.

Re: Ink: React for interactive CLI apps

#108

Earlier quoted context omitted.

To me this is expected? Thing is supposed to be one or the other. If I wanted a homogeneous array I would use a generic for the add function, which makes more sense for a function that just pushes to an array anyway.

arr was defined to be an array of strings. How are you pushing a boolean there?

Because you've given the function no information on whether those two "things" are related. You're saying when it gets passed into that function it can be treated as either with type widening.

I understand it may be unwanted at first glance, but this is a contrived example for demo purposes. You wouldn't really make an "add to array" function like this so specifically. You would use generics, which would solve the exact issue that is posed.

    function add(item: T, dst: T[]): void {
        dst.push(item);
      }
Now you can work with any array, and it will only add items with the right type.

If you really need it to be just , you can do this

    function add(item: T, dst: T[]): void {
        dst.push(item);
    }
Now it knows that Item and DST are related but need to be Thing.

There's not a lot of languages with unions that handle this differently. F# discriminated unions make you specify which type you're using every time. For example, this doesn't even compile.

    type Thing =
        | A of int
        | B of bool
    let arr: Thing list = [1]  // Not an A or B type!

Re: Ink: React for interactive CLI apps

#109
post #88

Earlier quoted context omitted.

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

Any viewer of data that has 50,000 elements in it has this many items with a scroll wheel. It doesn't matter if it's on the screen at the same time, this is the kind of thing that the UI is supposed to be abstracting away from you; you just describe the UI and the renderer makes it appear on the screen. Example apps (not built with Ink, just some that fit into this category): less, https://fx.wtf, sqlite...

And this is why React apps end up with bad performance by default. Doesn't crop up in simple tests and light usage, but the bad scaling will catch up with you when you deploy to production.

Post reply on HN