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

71–80 of 109 posts

Re: Ink: React for interactive CLI apps

#71

Post by seanw444 »

captnasia wrote: post #8
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…

there's a few attempts, templ[0], gomponents[1]. Not for cli apps per se but for web dev. 0: https://github.com/a-h/templ 1: https://github.com/maragudk/gomponents

I've seen gomponents, but it seems very verbose. Although I guess that's what you're stuck with if you're doing it within Go.

Re: Ink: React for interactive CLI apps

#72

Post by com2kid »

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…

> To give a sense of why this is important: Imagine a CLI built with XML.

If I'm not mistaken, JSX is a type of XML blended with JS code.

Re: Ink: React for interactive CLI apps

#74

Post by FridgeSeal »

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.

Rudy, Haskell, Ocaml are obvious examples.

Re: Ink: React for interactive CLI apps

#75

Post by consteval »

adamscybot wrote: post #68
angra_mainyu wrote: post #64

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.

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 c…

Nominal type systems are pretty much better across the board IMO. Much safer and much less to keep in your head. Modern langs like Rust or F# have very complete and nice to use type systems.

But yeah unfortunately not sure if JS is an appropriate target for these type systems. Nim does it, but I'm not sure how safe it is.

Re: Ink: React for interactive CLI apps

#76

Post by sureIy »

com2kid wrote: post #72
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…

> To give a sense of why this is important: Imagine a CLI built with XML. If I'm not mistaken, JSX is a type of XML blended with JS code.

It's definitely XML/HTML inspired, but not a type of XML since it uses prop={value}

Re: Ink: React for interactive CLI apps

#77

Post by consteval »

ryukoposting wrote: post #65
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…

> React combines the most robust type-system in the world (Typescript) By what measure? Your comment reads like you have something to sell me.

Right. It's a structural type system that automagically puns things at runtime. The "most robust type system", I would think, would be something like Haskell.

Re: Ink: React for interactive CLI apps

#78

Post by adamscybot »

consteval wrote: post #75
adamscybot wrote: post #68

Earlier quoted context omitted.

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 c…

Nominal type systems are pretty much better across the board IMO. Much safer and much less to keep in your head. Modern langs like Rust or F# have very complete and nice to use type systems. But yeah unfortunately not sure if JS is an appropriate target for these type systems. Nim does it, but I'm not sure how safe it is.

One language that comes to mind is ReasonML. It doesn't have runtime checking. It's structural and compile time, but the guarantees are supposedly cast iron. https://reasonml-old.github.io/guide/language/type#design-de...

    type thing = 
      | String(string)
      | Bool(bool);

    let arr: list(thing) = [];

    let add = (item: thing, dst: list(thing)): list(thing) => {
      switch (item) {
      | String(s) => dst @ [String(s)] 
      | Bool(b) => dst @ [Bool(b)]    
      };
    };

    let newList = add(String("asd"), arr);
This doesn't work, since the dst array has to be one that can contain both string and bool in the first place.

Re: Ink: React for interactive CLI apps

#79

Post by ipsum2 »

kaba0 wrote: post #14
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…

I don't know, go has lackluster expressivity, and these pre-compile tools always feel like a hack in its case.

I don't think its a Go-specific issue, its useful syntactic sugar. I would love an updated JSX for Python.

Re: Ink: React for interactive CLI apps

#80

Post by coffeemug »

wyager wrote: post #47
coffeemug wrote: post #31

Earlier quoted context omitted.

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.

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.
Post reply on HN