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

51–60 of 109 posts

Re: Ink: React for interactive CLI apps

#51

Post by seveibar »

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 insanely powerful, there are 1,000 page books on XML alone. But React is a much smaller standard that extends XML to an insanely effective point (assuming basic JS as base knowledge) It's because I like XML that I think JSX is a logical/effective extension and we should support it as the sort of "champion" of declarative design

Just to emphasize this: Why has XML been losing as the standard config format? Why did JSON win on web APIs? It's not because JSON is better, but because it's simpler and very-javascript-compatible.

If you like XML, there is a strong argument to support JSX because it's a way to keep XML around!

Re: Ink: React for interactive CLI apps

#54

Post by kristopolous »

dragonwriter wrote: post #49
kristopolous wrote: post #46

Earlier quoted context omitted.

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

I'm too old to forget it. It was the wrong kind.

They were the kinds with a bunch of worthless certifications who go everywhere in suits. I expected nothing but expensive clunky broken complicated bullshit from them. And that's exactly what they gave you when they pitched XML so I ignored it for over a decade as some tedious wasteful time-consuming thing that dumb people use to rake in hourly contract dollars.

But then, maybe 15 years ago or so, I started hitting use-cases that it was designed for and everything changed.

Re: Ink: React for interactive CLI apps

#55

Post by klysm »

insane_dreamer wrote: post #22

Nice accomplishment! However, React seems overly complex for a TUI, unless you already work with React in the browser and love JS?

Obviously that depends on the complexity of the TUI. React is the best tool I’ve used to build UIs out of all the tools I’ve ever tried. I don’t love JS at all.

Re: Ink: React for interactive CLI apps

#56

Post by kristopolous »

seveibar wrote: post #51
kristopolous wrote: post #46

Earlier quoted context omitted.

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 insanely powerful, there are 1,000 page books on XML alone. But React is a much smaller standard that extends XML to an insanely effective point (assuming basic JS as base knowledge) It's because I like XML that I think JSX is a logical/effective extension and we should support it as the sort of "champion" of declarative design Just to emphasize this: Why has XML been losing as the standard config format? Why…

XML continues to be a poor and inappropriate choice for simple stand-alone things.

In APIs you're talking to 1 server, calling 1 function, that returns 1 kind of thing at 1ce.

XML starts becoming useful when you increment those numbers - any of them.

People (including me) have been trained not to think in those ways. The web still isn't a web - it's merely a collection of computers with individual relationships.

The 90s internet had fleeting attempts at other paradigms. We should probably put serious effort into a second bite at that apple since by every measure our technology is at least 1000x better in the same way we've revisited neural networks

Re: Ink: React for interactive CLI apps

#57

Post by nicce »

Etheryte wrote: post #39
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.

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.

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.

Re: Ink: React for interactive CLI apps

#58

Post by bryanrasmussen »

oorza wrote: post #21
cupofjoakim wrote: post #17

Earlier quoted context omitted.

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

Sure, but ten years ago, if I told you the concept of a "bottom type" would be common knowledge with web developers or they'd consider type algebra second nature, you'd have laughed at me. If I were to tell you they pushed a Turing complete type system into the mainstream and then abused its computational power to do things like create value types, you'd ask me where I was buying my LSD. TS might not be the most robu…

OK, that's all well and good but I notice you still haven't told me where you're buying your LSD?

Re: Ink: React for interactive CLI apps

#59

Post by daotoad »

emoII wrote: post #33
cupofjoakim wrote: post #17

Earlier quoted context omitted.

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

Is there a type-system that provides runtime safety? I thought type-erasure was common practice

Raku has a really weird but cool type system[1] that does both compile time and runtime checks.

Because some checks are expected to be runtime only, it lets you specify types like "Odd integers" by writing a `where` clause.

``` subset OddInteger of Int where !(* %% 2) ```

You can use multiple dispatch to separate dispatch from processing: ``` subset Fizz where * %% 3 subset Buzz where * %% 5 subset FizzBuzz where * %% 15

  multi sub fizzbuzz(FizzBuzz $) { 'FizzBuzz' }
  multi sub fizzbuzz(Buzz $) { 'Buzz' }
  multi sub fizzbuzz(Fizz $) { 'Fizz' }
  multi sub fizzbuzz(Int $number) { $number }
  (1 .. 100)».&fizzbuzz.say;
```

Or even use inline anonymous subsets when you declare your functions: ``` multi sub fizzbuzz(Int $ where * %% 15) { 'FizzBuzz' } multi sub fizzbuzz(Int $ where * %% 5) { 'Buzz' } multi sub fizzbuzz(Int $ where * %% 3) { 'Fizz' } multi sub fizzbuzz(Int $number ) { $number } (1 .. 100)».&fizzbuzz.say; ```

Raku's type system is one of its features that will show you new ways of thinking about code. I advocate playing with Raku specifically for mind expansion because it has so many interesting ideas built in.

[1] https://docs.raku.org/language/typesystem

Re: Ink: React for interactive CLI apps

#60

Post by treflop »

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…

We’re not talking about XML as a data transport format.

As a way to ultimately render a view, it has never been elegant.

I’ve done it every possible way:

- Templating libraries

- XHTML with embedded XML data

- XML and XLST

- XML embedded in JavaScript (EMCAScript), aka React before React existed

- React, which is similar EMCAScript

I used the first public releases of React. I was immediately sold. No one had to sell anything to me. I knew it was going to win.

I can’t imagine anyone with strong experience in all these ways possibly think that these other ways are more enjoyable.

p.s. I’m not talking about Redux. I was never sold on Redux/Flux.

Post reply on HN