Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building Rich Terminal Dashboards

willmcgugan.com

Post reply on HN
Print view View original

31–40 of 123 posts

Re: Building Rich Terminal Dashboards

#31

Post by yjftsjthsd-h »

solosoyokaze wrote: post #15
nhumrich wrote: post #13

Earlier quoted context omitted.

pip is installed by default on mac and linux. For non posix experienced users, pip installing packages is actually easier than figuring out how to put a binary on the path. Not to mention, updates are just a command, you dont have to go find the url, redownload, and replace the binary.

Realistically speaking people will most likely install cli tools with brew on mac. People shouldn’t be pip installing things without virtualenv anyway.

In that case it's irrelevant whether the thing is shipped as a normal python package, a static binary, or anything else, since it just comes from brew anyways.

Re: Building Rich Terminal Dashboards

#33

Post by aduitsis »

Very nice! There is a certain appeal to having simple, versatile and robust systems such as a terminal emulator to build upon instead of complex APIs that require many many hours just to understand their asynchronous operation and complexities. Combined with Unicode, there seems to be a small renaissance in the area of what can be done in a terminal, which is both nostalgic and refreshing!

And, terminal emulators such as iTerm can nowadays display images. And vector or bitmapped graphics were actually a thing once. E.g. I believe xterm can still understand and display https://en.wikipedia.org/wiki/ReGIS graphics. Surely there must be better and simpler alternatives that I may be missing. Having an empty canvas and drawing to it without too much hassle is reminiscent of the era when this was done with a few lines of BASIC.

Re: Building Rich Terminal Dashboards

#34

Post by CoffeeDregs »

rexreed wrote: post #17

The future repeats the past. This looks much like the back-end systems I used to design on TurboPascal in the late 1980s / early 1990s. https://ilyabirman.net/meanwhile/pictures/tp-80.png

I think I agree but with the point "Isn't this a solved problem?" I'm not sure if the first library should be written in C, Rust, C++, etc but it seems as though very similar libraries-but-in-different-languages are being repeatedly written.

I certainly get that a good library yesterday might not be good today or that an existing library's style might not meet this language's style but I doubt the need to rewrite existing libraries so often. Even with the much-maligned PHP, libraries were frequently bindings to other libraries.

Re: Building Rich Terminal Dashboards

#35

Post by aduitsis »

CGamesPlay wrote: post #27
rexreed wrote: post #17

The future repeats the past. This looks much like the back-end systems I used to design on TurboPascal in the late 1980s / early 1990s. https://ilyabirman.net/meanwhile/pictures/tp-80.png

I wouldn't say it repeats it. These new programs are similar to the old ones in much the same way that new books are similar to old books. The medium is the same but what's being expressed and accomplished is vastly different. Two specific categories that come to mind: these new programs are vastly easier to use with modern UI principles than "RTFM" you'd find in the old ones; and validation/error handling is similar…

Your point is very well taken, but using Turbo Pascal to create an application with a TUI was surprisingly easy back in the day. You could just add some small boilerplate and you basically had something with a TUI running. So the entry barrier was extremely low, which had the effect of giving you a quick reward to motivate you to understand and build more advanced features.

Re: Building Rich Terminal Dashboards

#36

Post by lumpa »

Just realized that the post author submitted[0] it hours before I did, but it didn't come up in search because it was dead at the time.

This is sad because Will writes great posts[1] and great software[2], but somehow his submissions mentioning Rich tend to end up dead. Would it be a case of bad project name for HN titles?

[0] https://news.ycombinator.com/item?id=26147831

[1] https://www.willmcgugan.com/blog/tech/

[2] https://github.com/willmcgugan

Re: Building Rich Terminal Dashboards

#37

Post by dfee »

acemarke wrote: post #8
pugio wrote: post #5

Does anyone know of a similar library for node which does this? I've decided to make my next app TUI first, and then only add in a GUI much later, but I haven't seen anything that looks nearly as good as rich.

There's `blessed` [0], a plain JS lib similar to `ncurses`. There's also `react-blessed` [1], which is a React renderer that targets `blessed` as the display layer, and `ink` [2], which is also a text-based React renderer but using its own display layer. [0] https://github.com/chjj/blessed [1] https://github.com/Yomguithereal/react-blessed [2] https://github.com/vadimdemedes/ink

This is so cool! I knew about Ink, but not Blessed. Curious as to people’s experience using Blessed-React vs Ink.

Re: Building Rich Terminal Dashboards

#38

Post by SiVal »

naikrovek wrote: post #20
rexreed wrote: post #17

The future repeats the past. This looks much like the back-end systems I used to design on TurboPascal in the late 1980s / early 1990s. https://ilyabirman.net/meanwhile/pictures/tp-80.png

I miss the simplicity and utility of textual UIs. Nothing unneeded, and everything you need. No filler. No giant gaps between elements or wasted pixels. No fads which do silly things like hide scrollbars or other interactive elements. Except for CAD applications and some games, almost everything we do online today could be accomplished via textual UI. Almost the entire internet could be replaced with TUIs and a lot o…

I agree with your claims about the potential advantages of a TUI, but in this case, almost all of these TUIs using Rich will be running as GUI graphics inside a GUI window on top of a GUI OS subsystem, driven by an interpreted Python subsystem, all on an OS juggling many other simultaneous deep-stack processes. In other words, it's a keyboard-driven GUI app making use of the GUI advantages to provide you with your choice of high-quality fonts and designer colors to emulate a TUI. That doesn't make it bad. I still like it.

But like you, I wish we had more options to fully exercise the power of a TUI much closer to the metal, like the old days. Apps where almost every keystroke completes an operation faster than the fastest typist can move from key to key....

Of course, beyond a certain speed, more speed wouldn't matter, so maybe I could get it by installing a (local, not remote) desktop Linux without any GUI and using only CLI dev tools. Is anyone doing this?

Re: Building Rich Terminal Dashboards

#40

Post by wyqydsyq »

sokoloff wrote: post #26
wyqydsyq wrote: post #18

Earlier quoted context omitted.

Except you can bake apps into a single stand-alone binary executable for both Node.JS[1] and Python[2] [1] https://www.npmjs.com/package/pkg [2] https://github.com/marcelotduarte/cx_Freeze

Can’t you just shebang a python script to make it feel like a normal executable?

You can do it with Node as well, this works: #!/usr/bin/env node

But similarly to with Python, it still requires you have the runtime installed along with any packages your thing depends on

Post reply on HN