
CLI chat for developers - aichholzer
http://whir.io/
======
aichholzer
As a developer, I use my command line a lot so why not integrate chat directly
into it?

For this reason, I wrote whir, which aims to close this gap by providing a
simple, flexible, extend-able and blazing fast chat environment, without
having to install additional applications.

Full source code (client and server):
[https://github.com/whirio](https://github.com/whirio)

------
flukus
Three issues with it:

1\. Installation instructions are to use npm. I already have a package manager
and don't intend to learn a new one for every language.

2\. Javascript/npm based. I refuse to install that monstrosity on my system
ever again. I don't know how much memory it uses, but I'm willing to bet it's
a lot more than existing IRC programs.

3\. What's with the server? Why not standard IRC?

~~~
aichholzer
I had to laugh at your second point; "monstrosity", that was really creative.

Actually, it does not use too much memory, given what it is, a JS application,
that runs virtually within something else, there are no two ways about it. JS
was the language of choice simply because of the easiness of getting the
product out there. If I was to write this in plain C++, even Go or Rust,
memory usage would be less, but that's not in my near future plans.

As for the server; I wanted fully to use websockets and I wanted to keep it
simple. IRC would mean another layer which I is not part of my scope here.

------
dllthomas
From the landing page, it's not clear what actual usage looks like. How do I
send a message? How are messages received? Is this just another CUI chat
client, or does it actually decompose chat actions such that they're
accessible from the shell?

I took a swing at the latter a while back (as a libpurple client); it was
interesting.

~~~
aichholzer
This is for an earlier version, the basic implementation/renderer has not
changed.

[https://asciinema.org/a/4ff69bzz484gopw5hno3ietmm](https://asciinema.org/a/4ff69bzz484gopw5hno3ietmm)

I have not thought of decomposing the actions so they generally available in
the CLI, but it sounds like a good idea, I will look into that. Thank you for
the pointer.

