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

41–50 of 109 posts

Re: Ink: React for interactive CLI apps

#41

Post by seveibar »

cupofjoakim wrote: post #17
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…

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

Runtime safety is slower than compile type safety. Runtime safety SHOULD be opt-in if there's a performance penalty!

For runtime safety, there are lots of frameworks that follow TS's standard, one of the best is called "zod" which allows runtime safety and complex types are inferred.

Re: Ink: React for interactive CLI apps

#42

Post by seveibar »

hajile wrote: post #27
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…

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…

I love Yoga (flexbox++ engine built by Meta), and yes most people don't understand that React is simply not coupled to the DOM!

Re: Ink: React for interactive CLI apps

#43

Post by evantbyrne »

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.

Re: Ink: React for interactive CLI apps

#44

Post by rkagerer »

hajile wrote: post #27
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…

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?

Re: Ink: React for interactive CLI apps

#45

Post by wyager »

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…

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

The rare combo of Blub Paradox + Poe's Law

Re: Ink: React for interactive CLI apps

#46

Post by kristopolous »

seveibar wrote: post #40
dragonwriter wrote: post #35

Earlier quoted context omitted.

> 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. Talk about a late-night-infomercial-level “let’s compare the thing we are talking up with the absolute worst alternative imaginable as if that was the next best choice” argument.

Sorry, my point was to illustrate that XML is verbose so data-representation isn't a good fit. Most languages implement some kind of language-specific builder-pattern for CLIs, which in some sense is "re-inventing" a declarative programming paradigm for the domain-specific task. Could have done better w/ the example!

XML is a much maligned and poorly understood technology. It lacks glossy pitch pages and hypemen like react.

Things like XSLT are really quite good if you can get past "ew xml icky"

You can inline different schemas in modular, bazaar like ways from a variety of sources and pull in different parsers that do different tasks.

For instance you could have, say an object subtype and pretend you, a spreadsheet developer made something compatible with it.

As the tool parsers the XML, it sees the spreadsheet, which it has never encountered however, the schema tells it where to get the parser so it dynamically loads it, passes off the subtree it doesn't recognize and lets your spreadsheet parser do its things.

It's remarkably clean and elegant clockwork for distributed modular applications.

Things like a mobile phones share feature would be a perfect use case: a wide variety of objects from different applications passing through the same schema with a share directive invoked that allows you to share in a variety of ways. XML can handle this quite magically.

I've built systems like this with XML, it just works. I was like "damn. XML... Who would have thought"

People just never learned XMLs killer features because it got a bad reputation as being the thing that out of touch enterprise Java bozos make messes with - which is true.

But that's also why JavaScript was shat on for 15 years. You gotta be adult enough to look past that. Try to separate the merits of a technology from your perceptive competency of its users.

Re: Ink: React for interactive CLI apps

#47

Post by wyager »

coffeemug wrote: post #31
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.

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.

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.

Re: Ink: React for interactive CLI apps

#48

Post by mbreese »

kristopolous wrote: post #46
seveibar wrote: post #40

Earlier quoted context omitted.

Sorry, my point was to illustrate that XML is verbose so data-representation isn't a good fit. Most languages implement some kind of language-specific builder-pattern for CLIs, which in some sense is "re-inventing" a declarative programming paradigm for the domain-specific task. Could have done better w/ the example!

XML is a much maligned and poorly understood technology. It lacks glossy pitch pages and hypemen like react. Things like XSLT are really quite good if you can get past "ew xml icky" You can inline different schemas in modular, bazaar like ways from a variety of sources and pull in different parsers that do different tasks. For instance you could have, say an object subtype and pretend you, a spreadsheet developer mad…

In general, I liked XML. But the entire system seemed fragile. Parsing and validation were great. It was a great system for ensuring your data matched the schema. But if it didn’t, it seems like it never failed gracefully. As in, you’d be unable to even open your spreadsheet document if some random web server was down. Or if you were on a plane.

Just a few of the things I didn’t like about it. But when the system worked, it was quite capable.

Re: Ink: React for interactive CLI apps

#49

Post by dragonwriter »

kristopolous wrote: post #46
seveibar wrote: post #40

Earlier quoted context omitted.

Sorry, my point was to illustrate that XML is verbose so data-representation isn't a good fit. Most languages implement some kind of language-specific builder-pattern for CLIs, which in some sense is "re-inventing" a declarative programming paradigm for the domain-specific task. Could have done better w/ the example!

XML is a much maligned and poorly understood technology. It lacks glossy pitch pages and hypemen like react. Things like XSLT are really quite good if you can get past "ew xml icky" You can inline different schemas in modular, bazaar like ways from a variety of sources and pull in different parsers that do different tasks. For instance you could have, say an object subtype and pretend you, a spreadsheet developer mad…

> XML is a much maligned and poorly understood technology. It lacks glossy pitch pages and hypemen like react.

The negative feelings about XML are not due to the lack of glossy pitch pages and hypemen pushing XML and XML-based technologies; they developed whole XML had those far more than React ever has.

Some people may be too young to remember that, but...

Post reply on HN