Terminal Charts with Victory CLI | Hacker News Reader

Terminal Charts with Victory CLI

formidable.com

77 pointsthekenwheeler18 comments

Looks really interesting! Thank you and congratulations on the release.

I have to make one observation that I was wondering if anyone else also makes and please don't take offence at this, every time I see a new piece of software on HN, if I find it looks interesting I click (tap) on the Git(Hub|Lab) link and find myself (almost crossing my fingers) saying 'please don't be node!, please don't be node!, please don't see npm in the install instructions!'.

There's clearly a lot of highly creative people out there that can see problems / needs but that have probably come more from a design background rather than a programming / engineering background that may not see the same issues with the node / JavaScript ecosystem that programmers or operational engineers may.

I think that it's clear that designers and creative types value things that the JavaScript ecosystem has to offer but as an engineer of bother engineers and software delivery - after significant experience node, JavaScript and npm are each things I avoid at all costs. The amount of performance, security, package management, standardisation, general hosting and deployment problems I've had, seen or worked with people on for this ecosystem is down right scary when given its current prevalence.

Again, authors of this project, no offence intended towards you at all and I'm certain I'll get down voted for saying it but I just found this another case where I found myself saying out loud 'oh... javascript and npm, bugger, write that one off then.'

out of pure curiosity , what would you prefer it be written in?

Personally? Ruby, Go or Python.

Node/JS is everywhere, it's easy, it works. It's not perfect by any means, it's probably flawed and fails a "perfect language/platform/package manager" pretty badly but for better or for worse people are very productive and ship tons of stuff with it.

While you, and many others, have found cases where node is not a good choice, encountered bugs, etc (like literally anything else), clearly a large number of people have found node sufficient for their needs.

I’m perplexed by the suggestion that the only people who use node come from a design background. You know it’s used in the enterprise, by companies like Netflix, right? I don't read anything in this post that implies the author comes from a design background. Hell, I don't even know a lot of designers that write JS in the first place.

Must every JavaScript or PHP project posted to HN be plagued by this discussion? It's tedious.

> 'oh... javascript and npm, bugger, write that one off then.'

People who write JavaScript and post it to HN know that lots of people who see it will feel this way. I have no idea what makes this feedback helpful.

Also, I didn't downvote you. But I didn't upvote either.

> There's clearly a lot of highly creative people out there that can see problems / needs but that have probably come more from a design background rather than a programming / engineering background that may not see the same issues with the node / JavaScript ecosystem that programmers or operational engineers may.

> after significant experience node, JavaScript and npm

Sorry, but I'm having a really hard time reconciling these two points in your post. You have significant experience with node and yet think that node users "probably come more from a design background"? As someone who actually does have significant experience, it's pretty obvious to me that some of the most solid engineers (many from engineering backgrounds) and most prolific OSS heroes today are working on node and contributing packages to npm.

Do you really think all the big companies that adopted node just accidentally hired a bunch of designer-types for their engineering positions instead of vetting that they were solid engineers that, yes, liked and vetted node?

For quite a while I worked in an environment where something like npm wouldn't even get out of the proxy, let alone be installable (thanks, AppLocker).

Basically, if it's not a single exe with a valid code signing certificate, it ain't working in a lot of enterprise environments.

More specifically: charts that display in iTerm, which is an OS X terminal which can display images.

Unfortunately, it's not a tool for generating ANSI charts that work in any modern terminal emulator.

I guess we could try running the resulting images through sixel...

https://github.com/saitoha/libsixel

The documentation on how to render images in iTerm 2 (version 3) that this example relies on can be found here:

https://www.iterm2.com/documentation-images.html

Hopefully they can expand this to include drop down boxes, buttons, text inputs, etc. Imagine... a fully programmable user interface that works on graphics.

So, Visual Basic?

Anything but.

Check out https://github.com/sindresorhus/term-img if you want to render images in iTerm2 from Node.js

This lib uses term-img internally to print generated png imagery.

Very nice. I love tools that let me stay in the shell (not even just "in the terminal"). Down with captive user interfaces! :D

Fade effect is annoying

That is really neat!

Reply on news.ycombinator.com