
The Hyper Plan - lhnz
https://zeit.co/blog/the-hyper-plan
======
daveloyall
Does anybody else frequently immediately close the tab when you find out that
idea involves clientside javascript?

But, this one is about a terminal.[1]

So I read on... and I found this:

    
    
        > Slowly but surely, Electron-based applications
        > have started to dominate many of our workflows. 
    

You have just announced that there is a horde of pod-people roaming the
internet. I'm going to go stock up on canned goods.

    
    
        > This is a goal worth pursuing in the interest of sane
        > window management, agility, built-in logging of launched 
        > applications, engineering exploration but most importantly
        > the preservation of our freedoms.
    

Wtf? You spawn a shell while sitting on top of a writhing swarm of
multithreaded mystery code so thick that stack overflow is a thing, in 2016,
and you call that freedom? What the actual f __*?

    
    
        > In a world increasingly encumbered by app stores, developer
        > licenses and approval processes, a hyper reboot is worth 
        > trying out. And who knows, 2017 might by the year of the 
        > Linux desktop!
    

You call starting up 400 MLOC to open a shell a reboot?

Have you tried Forth?

I am so sorry for the abuse. I truly am. I know that you are a person, doing a
thing. But from my point of view, you are trudging blindly further into the
swamp, not out of it, and you are carrying a flag and singing along the way.

We need to talk!

\----

1: Or something? Note to author: After the first skim, it wasn't clear if your
project is a terminal emulator or a shell...[2] The first screen shot looks
like a shell, the one with a webpage looks like a terminal emulator. (Spoiler:
it's a terminal emulator. It also apparently hijacks the command line to
support URLs as commands??)

2\. Oh, they have a chat room. I'll just go ask them. Uh-oh, they don't say
what protocol I should use to connect to the chat room... That's a bad sign.
Ah, it's a web app and I have to provide my email address. No, thank you.

~~~
marmaduke
Agree all around. I recently regressed to the Linux text mode ptty for
terminal work. I can't imagine running a browser to have a shell.

~~~
yladiz
To clear up the confusion about running the browser (I don't like the idea
either, but don't want to spread FUD): the terminal is an Electron
application, and when you type the URL, it runs it as an Electron process. You
don't seem to need a browser because the terminal already supports browsing.

------
chriswarbo
Wow, never come across this project before; also never used any of the
'workflow dominating' programs they mention (although I've heard of Slack,
WordPress and Atom).

Certainly seems to be following a very different approach to the terminal
emulator that I use: [http://st.suckless.org](http://st.suckless.org)

~~~
Rauchg
It's actually very similar goals and look as st, with the difference that it's
extensible through a plugins interface.

Give it a try :)

~~~
jrs95
It's also about 1000 times larger ;)

~~~
daveloyall
I don't think you're counting the dependencies.

~~~
jrs95
You are correct, I was not. Didn't actually check what was inside the download
from st.suckless.org, which was just the source w/o any dependencies.

------
deadbunny
Maybe I'm just a crotchety old admin but I really don't "get" the recent
tsunami of everything being written in JS.

I mean what is the appeal of node for system applications over something a bit
more systems oriented? Is it just an overspill of web developers getting into
systems and not knowing any other language? Does JS really offer something
different languages don't?

~~~
thaumaturgy
There has been an Eternal September in systems administration.

The sysadmin niche has recently been flooded with young people coming from
development backgrounds (which, today, the cutting edge is dominated by
languages like JS and Go and Python), and they are approaching systems
administration from a software development point of view -- attempting to
abstract away the systems themselves, set up repeatable and testable
environments, that sort of thing.

There's a lot of it that's not bad, but as always happens in these situations,
they're ignoring the advice and experience of everyone that's kept the lights
blinking for several decades now, and those older folks are finding it
impossible to keep up with the flood of new people.

If anything kills this project one day, it'll be that it's no longer
considered "okay" to connect to an individual server over ssh at all; you're
supposed to use an IDE-like interface in a web browser, that connects to a
service written in Node, that uses an API to download crowd-sourced pre-
written web server configurations from a paid service, that then spins up a
new VM using an API from another service, that then installs a daemon written
in Go, that then installs the new web server configuration, and then all of
your data gets migrated over to the new server and the old one gets
decommissioned. If you actually ever touch a server or, gods forbid, edit your
own Apache or nginx configuration files, you're a fool and an old-timer and
you should retire.

(Inspired by an actual comment I saw on HN not too long ago.)

~~~
sheer_horror
For you to have such a strong opinion on so many topics, you must know the
in's and out's of Systems Administration. Would you consider writing tutorials
or a blog about best practices, and why we should avoid complex systems built
on Node?

For what it's worth, this comment is toxic. I am probably the kind of dev that
would get lumped in to the group you're calling out, but I edit my own nginx
files, I am interested in being close to the metal, and I'm focused on having
strong fundamentals. So why not help out instead of being pessimistic? The
eternal september thing is everywhere on the web. Everyone loves to talk about
how much better it was 'back then'. It's very easy to look back and say that
the past was better. You just strap on your rose tinted glasses and sense of
superiority, and excuse yourself from any logical, productive discussion.

What I would like to see from experienced devs like yourself is some help with
merging the best of both worlds. When should I be close to the metal? When
should I work high up the stack? If you offer some real help, you could save
us days or weeks or months, but if you take the easy route and point the
finger then we all lose.

~~~
thaumaturgy
You're not wrong, but communities are toxic too and after over twenty years of
participating in them and discussions and arguments about "the right way" \--
which is often only a matter of opinion anyway -- I've mostly opted out now. I
just don't feel like putting up with the abuse that predictably comes back.

On HN specifically it's pretty challenging. I haven't made a billion dollars,
I haven't scaled anything up to 10 million users, I don't have a Github
project with thousands of stars, ergo there's no reason to listen to anything
I have to say. I have no merits to spend on the meritocracy here.

HN also tends to rush to embrace the shiny and the new, so it's not sufficient
to say something like, "build new things out of old, simple, battle-tested
tools" \-- which would be a stupidly obvious thing to say to a room full of
greybeard sysadmins -- but you have to be able to justify why you should use
older tools, and you have to be able to show that they're sufficiently better
than the new thing, and you have to have specific examples, preferably from
personal experience.

And I don't have the encyclopaedic knowledge to field that argument on much of
anything, either.

...maybe a better way to handle this would be to just ask you, what is it that
I could say that you would listen to?

~~~
sheer_horror
> what is it that I could say that you would listen to?

I am looking to build a single-page app that communicates with a server
several times per second. The idea is to have some python code created
interactively in the browser through some click-and-drag process. That python
code is sent to the server and ran alongside other similar python scripts; the
scripts are actually competing game AI's. So you build it in the browser, and
run it on the server with the game state being sent back to the browser to be
viewed.

If you have a picture of the fundamental architecture this requires, would you
kindly explain the major components and their functionality? I could use
something like Django/flask on the server, but how do I keep my front end
updated? It's hard for me to imagine the full stack, so if you could paint the
picture and explain the parts that would be useful.

Thank you

------
yladiz
Why would I want to use this over (Mac) Terminal or iTerm2? The rationale for
me using iTerm2 over Terminal is that it has genuine useful features like 256
colors that Terminal doesn't support, but for any major customization, I edit
my `.bash_profile`. However, what "killer" feature(s) does this have that
would persuade me to use it over the base terminal for my OS?

One feature might be that it's extendable. Sure, but what does that really
give me that I can't get in Bash/ZSH?

Edit: I'm not trying to be snarky, if it came off that way. I'm genuinely
curious why this terminal would be better than a really simple terminal and
Bash or ZSH.

~~~
lhnz
You can easily unit test the customisations you make to your shell (edit: I
meant to write terminal here), and can share them with other engineers in a
modular and easy-to-install way.

Since JavaScript is a more 'popular' language than Bash, you are also more
likely to receive bug fixes and extra features for your plugins from other
engineers.

JavaScript might not be the best language compared to many others, but
compared to a lot of shell scripting languages it's not too bad. I've never
thought that the way people currently customise their shell prompts is well-
designed.

~~~
deadbunny
You (as well as the developer) don't seem to know the difference between a
terminal and a shell.

~~~
lhnz
Educate me then.

Is Hyper unable to encroach onto the product feature space of the shell due to
a particularly rigid terminology?

Are the reasons for the current separation of concerns still optimal?

~~~
yladiz
I would say the separation of concerns is very optimal right now. The terminal
emulates the shell, and that's it; there's nothing going on in between or in
the terminal besides displaying what the shell outputs. I don't really need
mixing of the two, which this looks like it does. For example, if I entered a
URL into the terminal, it should be up to the shell to interpret it, not the
terminal.

This is not to say that I don't mind "magic" \-- I removed the `git` prefix
from my git commands because I like typing `add .` rather than `git add .` all
the time -- but I don't want my terminal to do it, I want my shell to.

~~~
lhnz
Is customising the shell prompt with a PS1 variable good though? The result
often lacks clarity.

I don't think the shell should be handling styling.

I also think the shell became less useful when modern application development
began to happen on the Web. More should be done to make it easier to interact
with Web applications from the command line.

~~~
deadbunny
Sorry but webapps make up a tiny portion of what I need to interact with on
the CLI as an admin. When I do need to interact with webapps I use an API
using curl or python (depending what I need to do).

When do you need to interact heavily with a webapp? Maybe I'm missing
something here.

~~~
lhnz
For example, say I ran a command to show disk space usage. Perhaps I would
like to pipe the output into a d3 visualisation and see it directly within the
terminal without context switching. Why shouldn't I be allowed to do this?

Have you read "The Visual Display of Quantitative Information" by Edward
Tufte? Text isn't the best representation of all types of data.

Imagine also that I wanted to represent a table of data within an Excel style
spreadsheet. This could be useful as it could define affordances for a user
such as the ability to select rows and columns, and to sort or filter in
realtime.

~~~
deadbunny
I can see the value in that, I don't see how looking across to a browser which
has rendered the results of a command piped into a script is the end of the
world.

One issue I have with bluring the lines is you open yourself up to a huge
attack vector. If I can craft the output of my shell command to get code
execution within your terminal I can now do anything, anything on any system
you have access to.

~~~
lhnz
Yes - it is a possible attack vector but that doesn't necessarily mean it
shouldn't be attempted.

------
brianzelip
HyperTerm has been great, I've been getting a lot of mileage out of it as my
default terminal. Love that I can hack on it so easily!

Sorry to see the name change though! Gonna be tough on plugins and lists that
made use of the original name. I really liked "HyperTerm".

~~~
jcoffland
I immediately thought of the original but I guess I'm getting long in the
tooth.

------
Mizza
Has anybody written a plugin to turn directories in to cd hyperlinks yet?
That's the main thing I'm looking forward to being able to do with this
project.

That, and replace TotalTerminal, which seems to have hit EOL. :( Goodbye, my
love..

~~~
daveloyall
Regarding the shell != terminal issue that is mentioned in several other
comments... You've named a valid reason to blur the shell/terminal
distinction. Nice.

Another would be: the ability to manipulate streams (or whatever you'd like to
call the content that flows through pipes). As in, replay a stream into some
new process without re-executing the original.

Another would be to fold terminal output.

Removing the shell/terminal distinction opens a door to a world of
possibilities. But, the door closes behind you!

~~~
sime2009
> Another would be: the ability to manipulate streams (or whatever you'd like
> to call the content that flows through pipes). As in, replay a stream into
> some new process without re-executing the original.

My terminal
([https://github.com/sedwards2009/extraterm](https://github.com/sedwards2009/extraterm))
can more or less do that now:

[https://raw.githubusercontent.com/sedwards2009/extraterm/mas...](https://raw.githubusercontent.com/sedwards2009/extraterm/master/docs/from_command.gif)

> Another would be to fold terminal output.

I did have something like that, but had to disable it. That feature will make
a reappearance sometime as I want it for things like automatically collapsing
command (e.g. compiler) output if terminals successfully. I only need to see
the output of failed builds, for example.

------
morsch
I wanted to try out the binary for Hyperterm before I read the grand plan, but
the provided download link[1] for Linux does not work:

    
    
      Version not found: latest
    

Does it work for anyone else? Also it's nice that they link to a support chat,
but I won't register with my email just to ask a simple question. Makes me
nostalgic for the days of half-assed web IRC frontends.

[1] [https://hyperterm-updates.now.sh/download/linux](https://hyperterm-
updates.now.sh/download/linux)

------
ilaksh
Seems like the only way to install it on linux is by cloning the repo? When I
click on linux download it says 'version not found: latest'.

------
bfrog
Sigh...

------
rch
I lost all interest when I saw the word 'emoji' in a feature item.

~~~
jcoffland
I'm all for Unicode support but definitely do not want emojies invading my
terminal. It's bad enough that I have to endure them on my phone.

My terminal is an emotional clean room of sorts. There's no allowance for the
emotional nuance afforded by the emojie. Only three emotional states are
allowed. State 0: Deadpan zero emotion. State 1: White hot anger. State 2:
Pure elation.

