[cupofjoakim]

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.

[johnfn]

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

[CGamesPlay]

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.

[johnfn]

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

[CGamesPlay]

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.

[yencabulator]

Since when is the basic pager an exotic terminal app?

[johnfn]

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

[yencabulator]

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

[mrbombastic]

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

[mike_hearn]

Any log viewer.

[mrbombastic]

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

[coffeemug]

Node/V8 is insanely fast. I never quite realized exactly how fast until I worked on this: https://www.spakhm.com/ts-wolfram-bench. It's mindblowing how fast it is.

[wyager]

I don't find "performance parity with Mathematica" to be very compelling. Mathematica is a CAS system, not something I would use to write fast code.

[coffeemug]

It's not that V8 has performance parity with Mathematica. The Mathematica interpreter is written in highly optimized C by experts over many years. My barely optimized js/V8 code has performance parity to _that C code_. That's what should blow your mind.

[Etheryte]

For most apps, CLI or not, performance is not really a concern so long as it's good enough. Obsessing over performance before your program does The Thing is a great way to never actually get around to doing the useful bits. Now don't get me wrong, I'm not saying performance doesn't matter at all, but premature optimization and all its friends apply.

[nicce]

However, before you build the Thing, you should note that the architecture itself does not make impossible to improve the performance later on, if there is a possibility that it can make The Thing much better in the end.

[adamscybot]

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.

[slashdave]

Node.js is not necessarily bad, but React? What makes React great is the ability to embed the DOM in your app. For CLI? Square peg, round hole.

[MrJohz]

I'm not sure that's true. There's lots of ways to use and manipulate the DOM. But React is particularly special because it turns out to be a simpler way to think about UI components. A TUI has nothing to do with the DOM, but it's got a lot to do with rendering UI components. So taking the ideas from React and applying them to drawing elements in a terminal makes a lot of sense.

Arguably it makes even more sense than with React. One of the problems with React is that the underlying DOM is a stateful, imperative system, whereas React wants to behaves much more like an immediate-mode system, where the whole UI can be dropped and re-rendered at any time. But the terminal is not stateful like the DOM, and a more immediate-mode paradigm arguably works better in this context than in the browser.

[hombre_fatal]

What makes React great is that you write a UI tree that updates when state changes instead of imperative code like a clearRect() + drawLine() cycle.

This project and others like React Native show that it works outside of the DOM: you just render something else instead.

Thinking that React is only helpful for DOM UI seems like a misunderstanding of what React is and what makes it great.

[lowboy]

React enables declarative UI code instead of imperative. That's one of its biggest values. Even in the terminal, especially as the complexity of a tool increases.