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
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.
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.
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.
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?
I think with Electron, making desktop web apps become as easy as knowing HTML, CSS, and JS. So perhaps it's easier to style? I'm not sure, that would be my guess though.
It might not be if you were working with the native toolkit on Mac or Windows, but for a cross platform application it's probably easier than something like Qt (and is already known by many developers).
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.)
To be fair I agree with most of that (except the web IDE), abstraction can do a lot for productivity, stability, and scalability but you certainly need the hard won experience when it all goes wrong.
My point was more towards the JS side of things. JS just seems like a terrible choice of language for the tasks being performed where there are so many better alternatives, sure it makes writing a desktop app as easy as a web app but it just doesn't seem suited for the purpose. To me it's like writing complex systems in bash, sure it works but it's a pretty terrible choice.
KDE (plasma), Windows, Gnome to a lesser extent, all web browsers, and now the server side all support application development in Javascript. If you're trying to write something once that, with a lot (a lot!) of effort, can run mostly anywhere, Javascript does make sense.
But I agree, I wish it had been a different language.
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.
First, there are plenty of people who can help, and at reasonable rates too. I learned a ton from working with experienced people back in the late 90's.
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?
> 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.
1. JavaScript's ecosystem is really huge. There are lots of libraries to help you quickly get a useful product out. (The problems you will have will arrive later and will be problems caused by building a large application in JavaScript.)
2. Electron and React allow you to create desktop applications similar to how you create web applications. This make it easier to recruit engineers to work on your project. This also means you can follow modern best practices.
3. There are perceived benefits to tools that are created with web technologies in how easily they interconnect to the web. For example:
- This terminal supports displaying a website within itself.
- You get things like cascading style sheets for cheap, rather than needing
to build your own theme system.
I think it also gives a lease of life to the terminal environment. There has not been very much UX innovation there for a long while. Hyper in many ways is already much more interesting.
You can't do what I'm suggesting already. You're thinking of sending data to backend APIs which is completely different from sending data into a visualisation function.
The point in these examples is that it is often very useful to be able to reuse the previous output to craft another command, or to work in a more iterative way by massaging the text and getting feedback along the way.
True, the classic shell tools like the pipe can do a lot of this. But there are important differences. Firstly, to use the pipe you need to know in advance which output you want to keep/capture when you run the command. (e.g. by redirecting into a tmp file or using a pipe directly.) In this terminal you can decide afterwards if you want to do something else with previous output.
Another difference is that this works across tabs, sessions and machines, but the classic pipe doesn't.
It makes your interactive shell a lot more interactive. Classic pipes etc still work as expected too, so you are feel to mix and match.
A side effect of Programming Language orientation. Old systems requires programmers to map higher levels to the machin themselves and accept legacy the hard way.
With javascript level, you can play the abstraction game which "can" make learning and prototyping way easier and unleash ideas.
It's just a different (and popular) platform for developing applications. Seems comparable to developing a terminal app with Java swing, or QT, or whatever native Mac apps are written in.
When I first read about Hyperterm, I was pretty sure I wouldn't use a terminal emulator that uses a browser. Heavy-handed and a security nightmare.
But eventually I head a podcast[^1] about it, and it started to make sense. It's nearly all about hackability. If you simply compare the number of people that are comfortable with adding UI elements to a native application in GTK or QT or whatnot, to those that are comfortable with enhancing a web application, it suddenly makes sense.
Also the design of Hyper is one where everything goes through events, which you can intercept (and possibly re-emit) in extensions, so you don't even need nasty DOM hacking or text parsing to write extensions/plugins.
So now I'm still skeptical, but I also see the upsides. I guess my next step should be to actually try it :-)
At least when a Linux version becomes available...
You may have noticed this phenomenon of 'browser bloat'.
Well, its gone way beyond bloat. Basically the idea of adding features to web browsers started snowballing years ago and then turned into a new animal.
That new animal is the web platform. The leading browsers now basically contain features that cover just about every single API a programmer could want. That even includes recently added experimental support for accessing USB devices.
So its an operating system that lives inside other operating systems.
The appeal of Hyper for me, as a JavaScript programmer who has been working with Linux for at least 15 years and likes the terminal -- (I do everything in zsh or fish shell, use vim to program, was playing TradeWars 2002 on telnet last night) is that now I can keep all of my cool ANSI and linux command-line workflow etc. PLUS I can add just about any fricking thing I can think of into my terminal. From sound to SVG to 3d graphics. Or just testing my JavaScript application or component.
But really it comes down to whether your belief system allows for the possibility of a terminal to have any feature that isn't in a classic terminal -- i.e. anything that isn't monospaced colorful text.
Also, if you don't like JavaScript, and ever consider expanding the capabilities of your terminal or integrating some other application somehow, there are tons of languages that can compile to JavaScript and therefore plug in to Hyper.app, including C or many languages that compile to C via emscripten, LiveScript, Haxe, TypeScript, Dart, Elm, RubyJS, Pyjs (Python), Nim, Shen (Erlang), Perlito (Perl), GWT (Java), Scala.js (Scala), Script# (C#), ClojureScript, Moby Scheme, OCamljs (OCaml), ghcjs (Haskell), Go2js (Go), jsForth (Forth), etc.
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.
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.
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.
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.
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.
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.
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.
A shell is a program that interprets input and such -- the interactive Bash shell is the same program that interprets scripts written for it. You can remotely call shells and interact with them without showing anything to one's terminal.
A terminal emulator connects your keyboard, mouse, and eyeballs to inputs/outputs of the shell.
Rather than just repeat the first Google result I'll link it[1] as it gives a far more thorough answer than I would.
While I welcome innovation I would not want my terminal to be in charge of much more than rendering text and inserting keypresses.
Yes there are some helpful things your terminal emulator can do like multiplexing, repeating input across instances, scrolling, text resizing/flowing but these are strictly UI features at no point is the terminal in charge of interacting with the underlying system, that's what the shell is for.
The example of typing a URL and having it be rendered by the terminal blurs this line, it is intercepting a command you've typed into your shell (what is essentially a system command) and being executed in the terminal, not the shell.
If they want to blur that boundary then they can crack on, it will lead to pain and anguish down the line for the users especially when they find themselves out of their comfort zone without their toys.
I use ZSH within Hyper. For me Hyper is just a more extensible terminal, nothing more. It provides a better way of customization that other terminals can't give me and I can write plugins and themes.
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.
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..
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!
> 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.
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.
So you'd use your mouse to cd into directories after you `ls`?
Moving you hand to the mouse, moving the mouse, clicking and clicking is quicker than `cd foo<TAB>`? Or just using a file manager and right click open terminal here?
69 comments
[ 3.1 ms ] story [ 172 ms ] threadCertainly seems to be following a very different approach to the terminal emulator that I use: http://st.suckless.org
Give it a try :)
1. have a working graphical terminal for terminal application
2. do no reimplement tmux and his comrades
Does hyper align with other suckless goals like being a small, statically-linked compiled executable?
Does hyper approach 20K LOC? Does st aspire to have a 'wow mode'??
But, this one is about a terminal.[1]
So I read on... and I found this:
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. 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*? 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.
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.
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".
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?
- Recent generation of developers who entered programming through JavaScript.
- Node.js being fashionable and hip.
- "Not invented here" syndrome.
- Open-source as a signaling mechanism for hiring and social pecking-order, which feeds the last three points.
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.)
My point was more towards the JS side of things. JS just seems like a terrible choice of language for the tasks being performed where there are so many better alternatives, sure it makes writing a desktop app as easy as a web app but it just doesn't seem suited for the purpose. To me it's like writing complex systems in bash, sure it works but it's a pretty terrible choice.
But I agree, I wish it had been a different language.
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.
> could save us days or weeks or months
I think you mean years or decades...
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?
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
2. Electron and React allow you to create desktop applications similar to how you create web applications. This make it easier to recruit engineers to work on your project. This also means you can follow modern best practices.
3. There are perceived benefits to tools that are created with web technologies in how easily they interconnect to the web. For example:
I think it also gives a lease of life to the terminal environment. There has not been very much UX innovation there for a long while. Hyper in many ways is already much more interesting.I certainly can't think of a time I've ever said "you know what my terminal needs? CSS!" and I have a browser to render webpages.
They also seem to be unclear the difference between a terminal and a shell.
It however does make it easier which increases the chances of useful innovation occurring naturally.
When software moved first from the shell to the desktop and then from the shell to the browser it became less accessible and less interoperable.Why shouldn't we be able to one day pipe Unix tools directly into our Web apps?
You can't do what I'm suggesting already. You're thinking of sending data to backend APIs which is completely different from sending data into a visualisation function.
It could, for example let you operate and reuse the text it just displayed:
https://raw.githubusercontent.com/sedwards2009/extraterm/mas...
or even provide a command to let you reuse previous output, such as here:
https://raw.githubusercontent.com/sedwards2009/extraterm/mas...
More information and an implementation can be found here:
https://github.com/sedwards2009/extraterm/blob/master/docs/t...
Another difference is that this works across tabs, sessions and machines, but the classic pipe doesn't.
It makes your interactive shell a lot more interactive. Classic pipes etc still work as expected too, so you are feel to mix and match.
Actually, editing colors in my term... I could use some CSS there.
With javascript level, you can play the abstraction game which "can" make learning and prototyping way easier and unleash ideas.
But eventually I head a podcast[^1] about it, and it started to make sense. It's nearly all about hackability. If you simply compare the number of people that are comfortable with adding UI elements to a native application in GTK or QT or whatnot, to those that are comfortable with enhancing a web application, it suddenly makes sense.
[1]: https://changelog.com/213/
Also the design of Hyper is one where everything goes through events, which you can intercept (and possibly re-emit) in extensions, so you don't even need nasty DOM hacking or text parsing to write extensions/plugins.
So now I'm still skeptical, but I also see the upsides. I guess my next step should be to actually try it :-) At least when a Linux version becomes available...
Hyper is just the window in which other programs such as bash, ls etc. run.
Well, its gone way beyond bloat. Basically the idea of adding features to web browsers started snowballing years ago and then turned into a new animal.
That new animal is the web platform. The leading browsers now basically contain features that cover just about every single API a programmer could want. That even includes recently added experimental support for accessing USB devices.
So its an operating system that lives inside other operating systems.
The appeal of Hyper for me, as a JavaScript programmer who has been working with Linux for at least 15 years and likes the terminal -- (I do everything in zsh or fish shell, use vim to program, was playing TradeWars 2002 on telnet last night) is that now I can keep all of my cool ANSI and linux command-line workflow etc. PLUS I can add just about any fricking thing I can think of into my terminal. From sound to SVG to 3d graphics. Or just testing my JavaScript application or component.
But really it comes down to whether your belief system allows for the possibility of a terminal to have any feature that isn't in a classic terminal -- i.e. anything that isn't monospaced colorful text.
Also, if you don't like JavaScript, and ever consider expanding the capabilities of your terminal or integrating some other application somehow, there are tons of languages that can compile to JavaScript and therefore plug in to Hyper.app, including C or many languages that compile to C via emscripten, LiveScript, Haxe, TypeScript, Dart, Elm, RubyJS, Pyjs (Python), Nim, Shen (Erlang), Perlito (Perl), GWT (Java), Scala.js (Scala), Script# (C#), ClojureScript, Moby Scheme, OCamljs (OCaml), ghcjs (Haskell), Go2js (Go), jsForth (Forth), etc.
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.
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.
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?
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.
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.
When do you need to interact heavily with a webapp? Maybe I'm missing something here.
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.
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.
A terminal emulator connects your keyboard, mouse, and eyeballs to inputs/outputs of the shell.
Those are terrible explanations, I'm sorry.
While I welcome innovation I would not want my terminal to be in charge of much more than rendering text and inserting keypresses.
Yes there are some helpful things your terminal emulator can do like multiplexing, repeating input across instances, scrolling, text resizing/flowing but these are strictly UI features at no point is the terminal in charge of interacting with the underlying system, that's what the shell is for.
The example of typing a URL and having it be rendered by the terminal blurs this line, it is intercepting a command you've typed into your shell (what is essentially a system command) and being executed in the terminal, not the shell.
If they want to blur that boundary then they can crack on, it will lead to pain and anguish down the line for the users especially when they find themselves out of their comfort zone without their toys.
1. http://superuser.com/a/144668
[1] https://hyperterm-updates.now.sh/download/linux
That, and replace TotalTerminal, which seems to have hit EOL. :( Goodbye, my love..
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!
My terminal (https://github.com/sedwards2009/extraterm) can more or less do that now:
https://raw.githubusercontent.com/sedwards2009/extraterm/mas...
> 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.
Moving you hand to the mouse, moving the mouse, clicking and clicking is quicker than `cd foo<TAB>`? Or just using a file manager and right click open terminal here?