Hyper 1.0.0(github.com)
github.com
Hyper 1.0.0
https://github.com/zeit/hyper/releases/tag/1.0.0
212 comments
> I'm skeptical of the value of electron-ified applications when fully native alternatives suffice.
Me too, although in the case of terminal apps, they really haven't moved on since the 70s. How many support images? Completion popups? Browsable history? Current directory widget? Collapsible output?
Honestly if it takes some insane over-engineering to get some actual innovation in terminal apps I'm all for it! And when I say "innovation" I mean "obvious features that should have been there decades ago".
Me too, although in the case of terminal apps, they really haven't moved on since the 70s. How many support images? Completion popups? Browsable history? Current directory widget? Collapsible output?
Honestly if it takes some insane over-engineering to get some actual innovation in terminal apps I'm all for it! And when I say "innovation" I mean "obvious features that should have been there decades ago".
I'm busy exploring some of these ideas in my little project Extraterm https://github.com/sedwards2009/extraterm .
This little gif demonstrates what it can do now: https://github.com/sedwards2009/extraterm/raw/master/docs/ed...
Some more demos of its features are here: https://github.com/sedwards2009/extraterm/blob/master/docs/t...
It is still early days for Extraterm although I use it myself daily (mostly on Windows and Linux). It too is built on Electron. It makes it possible to try out ideas relatively quickly and grants access to a megaton of 3rd party libraries and tools.
This little gif demonstrates what it can do now: https://github.com/sedwards2009/extraterm/raw/master/docs/ed...
Some more demos of its features are here: https://github.com/sedwards2009/extraterm/blob/master/docs/t...
It is still early days for Extraterm although I use it myself daily (mostly on Windows and Linux). It too is built on Electron. It makes it possible to try out ideas relatively quickly and grants access to a megaton of 3rd party libraries and tools.
[deleted]
Very cool looking project!
Enlightenment's Terminology[1] supports a few fancy things including image previews, animated cursors (nyancat is a builtin theme...) and local file links. More impressively, it actually works really well, it's native, and it's fast (even hardware-accelerated). With all of that fanciness, it renders text even faster than suckless' st with a GPU.
[1]: https://www.enlightenment.org/about-terminology
[1]: https://www.enlightenment.org/about-terminology
>How many support images?
A lot of them, actually. Sixel is a thing.
>Completion popups? Browsable history?
No terminal emulator supports that. Because that's not the emulator's responsibility. That's your shell's job. Asking for your terminal emulator to support command completion is like asking X Windows to add tab completion to Gedit.
Go grab a copy of fish if you want, though. I've heard a lot of good things about it.
>Current directory widget? Collapsible output?
Those are just hard to implement, and usually not worth the effort. The directory widget is essentially provided by your prompt in many shells anyways.
A lot of them, actually. Sixel is a thing.
>Completion popups? Browsable history?
No terminal emulator supports that. Because that's not the emulator's responsibility. That's your shell's job. Asking for your terminal emulator to support command completion is like asking X Windows to add tab completion to Gedit.
Go grab a copy of fish if you want, though. I've heard a lot of good things about it.
>Current directory widget? Collapsible output?
Those are just hard to implement, and usually not worth the effort. The directory widget is essentially provided by your prompt in many shells anyways.
> No terminal emulator supports that. Because that's not the emulator's responsibility. That's your shell's job.
How is the shell supposed to make a popup when it can only output text? It can't make popup windows.
> Those are just hard to implement
Presumably easier if you're using Electron though!
How is the shell supposed to make a popup when it can only output text? It can't make popup windows.
> Those are just hard to implement
Presumably easier if you're using Electron though!
Why do the terminal emulator and shell need to be different things?
Because some of us want to run NetHack.
One reason terminal apps haven't moved on much, and one of the major challenges for any piece of software trying to act as a terminal emulator, is the number of escape sequences that must be supported for common emulation modes (e.g. even just vt10x I believe).
Thus over-engineering has been with us all along, much of it legacy cruft.
It might be worth considering abandoning traditional terminal emulation entirely in favor of something else if more features are desired.
Personally I think remote and virtualized devices (think qxl/spice, remote audio, etc), could use some love. We have the bandwidth to improve on these technologies today.
Thus over-engineering has been with us all along, much of it legacy cruft.
It might be worth considering abandoning traditional terminal emulation entirely in favor of something else if more features are desired.
Personally I think remote and virtualized devices (think qxl/spice, remote audio, etc), could use some love. We have the bandwidth to improve on these technologies today.
I really don't think it's all that much "over engineering".
I mean, if you want images, history, tabs, to support every language under the sun, and support for most platforms, I'd say a browser is a fantastic way to get most of that "for free".
I mean, if you want images, history, tabs, to support every language under the sun, and support for most platforms, I'd say a browser is a fantastic way to get most of that "for free".
Unfortunately, "support for most platforms" tends to result in the kind of user experience that I described above. There's something comedic about millions of lines of compiled Chromium failing to handle the Control modifier on Linux.
I can't really blame them (Linux, like every nix, does something unique at the tty level that breaks reasonable assumptions), and I'm sure it'll get a lot worse once they try to run their JS bindings over the pty/tty subsystem of something like Solaris.
I can't really blame them (Linux, like every nix, does something unique at the tty level that breaks reasonable assumptions), and I'm sure it'll get a lot worse once they try to run their JS bindings over the pty/tty subsystem of something like Solaris.
I agree, and I'm sure that the stagnancy of the plain old terminal is behind this and other modern takes on terminal emulation.
I personally prefer that the terminal delegate just about everything besides I/O to plugins or extensions, so Hyper is probably out of the picture for me. That being said, my current terminal of choice (urxvt) doesn't do much on that front either. I hope that other terminal emulator projects pay attention to the development here and adopt the best innovations.
I personally prefer that the terminal delegate just about everything besides I/O to plugins or extensions, so Hyper is probably out of the picture for me. That being said, my current terminal of choice (urxvt) doesn't do much on that front either. I hope that other terminal emulator projects pay attention to the development here and adopt the best innovations.
An easy way for me to gain an extra hour or two of battery life is by closing every single Electron.js application I have open (Slack, VS Code, Atom, Discord, Upwork, FB Messenger for Desktop, Telegram, to name a few...).
Pretty sure iterm does all those things, except maybe the collapsable output.
> Hyper tries to run `npm prune && npm install --production` on every startup.
Wait, what, really? Wouldn't that leave you without dependencies if you don't have internet connection at the time?
Seems a very dangerous thing to do for many, many reasons.
Wait, what, really? Wouldn't that leave you without dependencies if you don't have internet connection at the time?
Seems a very dangerous thing to do for many, many reasons.
Depends whether you already have the dependencies or not I guess - I'm not sure if it ships with a node_modules or not.
FWIW `npm prune` only removes modules from node_modules that aren't specified in package.json. It won't actually remove and declared dependencies.
FWIW `npm prune` only removes modules from node_modules that aren't specified in package.json. It won't actually remove and declared dependencies.
> The .deb package seems to install everything in /opt
Hm, just like another commonly installed package...
Hm, just like another commonly installed package...
$ ls /opt/google/
chrome
chrome-beta
chrome-unstable
$ ls -l /usr/bin/google-*
/usr/bin/google-chrome -> /etc/alternatives/google-chrome
/usr/bin/google-chrome-beta -> /opt/google/chrome-beta/google-chrome-beta
/usr/bin/google-chrome-stable -> /opt/google/chrome/google-chrome
/usr/bin/google-chrome-unstable -> /opt/google/chrome/google-chrome-unstableWhich is exactly what GP mentioned. Although using `/opt` to begin with is an anti-pattern in all cases including Chrome.
Seems reasonable to me if it's a third party package that doesn't want to clobber whatever the distro installs. Where else? /srv?
/usr/local, traditionally. Since it only exposes one executable anyways, I'd say the chance of clobbering is fairly small (and reversible, since it's a deb).
Augh! No no no no no no. Sorry, this is a pet peeve of mine.
/usr/local belongs to the sysadmin (I grit my teeth at FreeBSD's interpretation of this, much though I love the OS otherwise, and prefer NetBSD's addition of a /usr/pkg hierarchy to avoid jamming packages in /usr instead, which is only a bit less aggravating).
/opt exists basically for vendors to have somewhere to put things that they know won't trample on my /usr/local hierarchy.
(I still think they should've installed something in $PATH, mind, but /opt is not at all the wrong answer to my mind.)
/usr/local belongs to the sysadmin (I grit my teeth at FreeBSD's interpretation of this, much though I love the OS otherwise, and prefer NetBSD's addition of a /usr/pkg hierarchy to avoid jamming packages in /usr instead, which is only a bit less aggravating).
/opt exists basically for vendors to have somewhere to put things that they know won't trample on my /usr/local hierarchy.
(I still think they should've installed something in $PATH, mind, but /opt is not at all the wrong answer to my mind.)
[deleted]
Which is exactly what I mentioned. Are we looking for a disagreement?
Maybe, sorry if I misread your comments!
I am using the appimage and I don't have these issues.
Ranger.py runs very smooth and vim is fine. I am kind of shocked that there was no delay and I am on a 8 year old dell.
Ranger.py runs very smooth and vim is fine. I am kind of shocked that there was no delay and I am on a 8 year old dell.
OK, I just installed it on Windows. Right out of the box, it does not recognize ctrl+c. What am I supposed to think about the quality of this?
(I literally have not tried a single other thing. I made a typo on the very first command I wanted to try. I tried ctrl+c to start over, and it did not recognize it.)
EDIT
I gave it another chance. If I start a bash shell, it recognizes ctrl+c, but it does not recognize the up arrow key. Not impressed. Don't get the hype. Sorry.
EDIT2
Is this being brigaded? It's the first result on HN without clear reason, and I'm being downvoted immediately for posting this feedback. What's going on?
https://github.com/zeit/hyper/issues/1127
https://github.com/zeit/hyper/issues/1126
https://github.com/zeit/hyper/issues/1121
https://github.com/zeit/hyper/issues/1129
EDIT3
OK, seriously, what's with the downvote brigade? I'm at -3 now.
(I literally have not tried a single other thing. I made a typo on the very first command I wanted to try. I tried ctrl+c to start over, and it did not recognize it.)
EDIT
I gave it another chance. If I start a bash shell, it recognizes ctrl+c, but it does not recognize the up arrow key. Not impressed. Don't get the hype. Sorry.
EDIT2
Is this being brigaded? It's the first result on HN without clear reason, and I'm being downvoted immediately for posting this feedback. What's going on?
https://github.com/zeit/hyper/issues/1127
https://github.com/zeit/hyper/issues/1126
https://github.com/zeit/hyper/issues/1121
https://github.com/zeit/hyper/issues/1129
EDIT3
OK, seriously, what's with the downvote brigade? I'm at -3 now.
> Please resist commenting about being downvoted. It never does any good, and it makes boring reading.
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsguidelines.html
I think the downvotes may be that you're posing a rhetorical question based on a sample size of one. As opposed to spending 15 more seconds to try a few more things and saying "I tried 10 commands, nothing worked" or "I tried 10 commands, works great, but Ctrl+C is broken on Windows and that really needs to be fixed"
My experience with the Zeit team is that they're very responsive and interactive via GitHub - I'd be surprised if the issue isn't fixed soon
My experience with the Zeit team is that they're very responsive and interactive via GitHub - I'd be surprised if the issue isn't fixed soon
Did you miss the part about the next four things I tried also being broken along with the github links in which I filed the bug reports?
"I literally have not tried a single other thing"
And without clicking through to all four links, there's no indication that they were from you trying things.
And without clicking through to all four links, there's no indication that they were from you trying things.
So you completely didn't read the part that begins "I gave it another try.." before downvoting? (Yes, it's an edit, but also, yes, it was made less than 5 minutes after my initial post and a good while before you replied and before the downvote brigade hit.)
Anyway, I put my money where my mouth is and I reported each issue that I encountered with hyper on Github (the links are above) before giving up on it (for now). I'm not a bandwagon hater nor a bandwagon fan, at the moment, hyper is not ready for use or worth the hype. In a month, it may be. I'll revisit it periodically in order to re-evaluate my findings in the interest of using the best tool for the job. All these years later, putty remains the most compatible, but I can't figure out how to use it locally on Ubuntu/bash for Windows (if I can get an ssh server working, I could just start a loopback session and use that). For now, I'm using cmd.exe and conemu.
Anyway, I put my money where my mouth is and I reported each issue that I encountered with hyper on Github (the links are above) before giving up on it (for now). I'm not a bandwagon hater nor a bandwagon fan, at the moment, hyper is not ready for use or worth the hype. In a month, it may be. I'll revisit it periodically in order to re-evaluate my findings in the interest of using the best tool for the job. All these years later, putty remains the most compatible, but I can't figure out how to use it locally on Ubuntu/bash for Windows (if I can get an ssh server working, I could just start a loopback session and use that). For now, I'm using cmd.exe and conemu.
it's probably related to your 2 edits solely about being downvoted
Have you tried opening an issue on it's repo?
Someone beat me to it, and it was promptly closed: https://github.com/zeit/hyper/issues/1121
EDIT: I wrongly stated that the issue was closed. Please see further downthread. I apologize.
EDIT: I wrongly stated that the issue was closed. Please see further downthread. I apologize.
That issue looks open to me, and there is no notice in it that it was ever closed. It does however have another issue made after it reporting the same thing and a collaborator closed that issue citing it being a dupe.
Sorry, you are correct and I take that back unreservedly.
This is really cool and it's clear that a lot of work went into it. I've used it a bit and it's generally solid.
I've been looking for improved terminal clients for years. To that end, I have a simple benchmark that I run:
Hyper on linux under X actually stops rendering the output very quickly, but all subsequent input is ignored. The tmux case was the same. In addition, CPU usage spiked to 2 procs each @ 100%. Interrupting the shell was not possible with Ctrl+C or other means, though I was able to `SIGKILL` it.
This particular test is my personal benchmark of whether I can use a terminal - because nothing is more frustrating than having to kill an entire session because of a typo or bad command that generates a lot of output. Too, clients that struggle with this also have a tendency to slowly render changing curses layouts on large terminals - such as when resizing tmux panes, or rendering large amounts of scrolling content in a sub-region of the terminal.
This is a simple case, and many native clients struggle with it as well. So far, although it's not my most-favorite to use, `konsole` is the only one that handles this well.
I've been looking for improved terminal clients for years. To that end, I have a simple benchmark that I run:
find /
Hyper on linux under X actually stops rendering the output very quickly, but all subsequent input is ignored. The tmux case was the same. In addition, CPU usage spiked to 2 procs each @ 100%. Interrupting the shell was not possible with Ctrl+C or other means, though I was able to `SIGKILL` it.
This particular test is my personal benchmark of whether I can use a terminal - because nothing is more frustrating than having to kill an entire session because of a typo or bad command that generates a lot of output. Too, clients that struggle with this also have a tendency to slowly render changing curses layouts on large terminals - such as when resizing tmux panes, or rendering large amounts of scrolling content in a sub-region of the terminal.
This is a simple case, and many native clients struggle with it as well. So far, although it's not my most-favorite to use, `konsole` is the only one that handles this well.
Heh... Javascript.
To that end, I have a simple benchmark that I run:
find /
And C-c didn't work? You must have let it run a really long time. I'm surprised it didn't error out.
You must have let it run a really long time.
All of about 5 seconds.
All of about 5 seconds.
Clearly you should not have run that script at all - it was a trick.
And I was hoping that was referring to this hyper: http://hyper.rs/
And I thought it might be related to this hyper: https://hyper.sh (which is also an OSS project)
While not quite ready for a 1.0.0, there has been some neat stuff going on in hyper: over the last week, the tokio branch added support for TLS, and from what I hear, is mostly waiting on tokio's initial release to be merged into master. Soon........
Does the parser support HTTP2 yet?
No, but it is marked for the 1.0 release: https://github.com/hyperium/hyper/issues/304
Waiting for this and the tokio branch to be available. For now we have solicit, which is ok but could have a better interface for async io.
At first glance I was thinking the same thing! Then I realized it was a JS terminal emulator... sigh
haha seems like there's so many hypers. When I saw this I thought about Python Hyper (HTTP2) https://hyper.readthedocs.io/en/latest/
I also came here hands shaking thinking "YES YES FINALLY". Was a slight disappointment. Well, take your time to get it stable. :)
Me too, even though I was a bit surprised by the announcement: with the undergoing work around async IO and Futures, I don't expect hyper to stabilize quite soon.
Typesafe HTTP implementation? Meh. I go back and forth on stringly typed vs strong typing. Just this weekend I wrote an app in Objective-C instead of Swift, and it's already close enough to 1.0 that I can start using it myself. I originally tried to do it in Swift but the IDE support is just way too lacking and buggy (still!) compared to ObjC. Point being, string-typing and dynamic typing aren't really all that terrible as I keep thinking they are. It gets the job done. Sure, something will always be better. But I've given up at aiming at perfectionism in programming. There's no such thing as The Perfect Language / Paradigm / Type System / etc.(TM). I'm too old and tired to keep chasing that rainbow. Pretty sure the pot of gold's in front of me all along and I keep just not noticing it and tripping over it.
> But I've given up at aiming at perfectionism in programming.
Optional typing is the sweet spot.
Optional typing is the sweet spot.
I agree, the next missing bit is runtime structural typing (not optional of course) that allows constructs like:
```
const whatIsFoo = match (foo) {
```
```
const whatIsFoo = match (foo) {
case : nil : "nothing, really"
case : string : "it's a string"
case : number | boolean : "it's bool or number"
case [ head, ...tail ] : string[] : `it's array of strings with head ${head} and tail ${tail.join(', ')}`
case { value } : { type: 'NodeFoo' } : `it's Node Foo with value ${value}`
default: "well, something else."
```
If only there were a decades-old system that allowed that[1]
1: https://en.wikipedia.org/wiki/Common_Lisp_Object_System
1: https://en.wikipedia.org/wiki/Common_Lisp_Object_System
It kind of already feels like that's what Objective-C is. You can use pretty-strong types, or you can just cast to id. Same with NSArray, elements can either be id (default) or a specific type. I just kind of feel like using better type systems hasn't actually helped me write better/cleaner/safer code. It's just added a very small amount of confidence and sometimes convoluted my code disproportionately.
Objective-C doesn't have algebraic data types.
Optional, structural algebraic type system with runtime support (mainly for `match ...` constructs) is IMHO the sweet spot.
It really makes a difference to have it. The analogy on top of my head is this: it's like a difference, when working on text processing code, to have regexp or do things by hand. Similar to regexps, above type system support, can cut necessary code by orders of magnitude and make it much more readable/reason about.
Optional, structural algebraic type system with runtime support (mainly for `match ...` constructs) is IMHO the sweet spot.
It really makes a difference to have it. The analogy on top of my head is this: it's like a difference, when working on text processing code, to have regexp or do things by hand. Similar to regexps, above type system support, can cut necessary code by orders of magnitude and make it much more readable/reason about.
This seems to me to be a needlessly synchronic perspective. What you're not looking for anymore doesn't exist because we haven't built it yet. How many thousands of years did it take to invent most other modern tools? Why would you expect us to have perfection in such a short time after computers have been invented?
Quit looking for pots of gold and start panning for nuggets.
Quit looking for pots of gold and start panning for nuggets.
> We are shipping a fix for a very common issue: if you're using a foreign keyboard, such as Portuguese, Norwegian, Swedish etc, you weren't able to type some characters like á, ä, ~ and so on. That's not the case anymore!
emphasis mine.
I have to say I'm pretty tired of this attitude that the whole world should use the anglo-centric defaults (but in case you won't we add support for you later).
Regrettably most of us developers (even those of us who live in non-english speaking counties and don't speak english natively) seem to just "settle" for the english keyboard layouts when we are developing. We tell our self that the english layout is "superior for programming". Perhaps we are correct (I doubt we are), but that is irrelevant. When we think like that we are causing accessibility problems to a huge portion of the users of our products.
What bothers me most, as an Icelandic developer who prefers my native keyboard layout, is how we shun ISO third level shifts[1]. For example, when I type TILDE (U+007E; ~), I press and hold the third level shift (remapped to <Caps Lock>; traditionally <Alt Gr>), press and release <?>, and release the third level shift. Most English speaking developers use the ANSI keyboard layout[2], which historically doesn't have a notion of third level shift. Mac OS X is a terrible perpetrator by mapping the third level shift to the <⌥ option> key, which also serves as a modifier. I never know when I type COMMERCIAL AT (U+0040; @) (<Third Level Shift> + Q) whether I will input the character or quit the program.
[1]: https://en.wikipedia.org/wiki/ISO/IEC_9995#Levels_.28.E2.80....
[2]: https://en.wikipedia.org/wiki/Keyboard_layout#/media/File:AN...
---
Edit: Formatting
emphasis mine.
I have to say I'm pretty tired of this attitude that the whole world should use the anglo-centric defaults (but in case you won't we add support for you later).
Regrettably most of us developers (even those of us who live in non-english speaking counties and don't speak english natively) seem to just "settle" for the english keyboard layouts when we are developing. We tell our self that the english layout is "superior for programming". Perhaps we are correct (I doubt we are), but that is irrelevant. When we think like that we are causing accessibility problems to a huge portion of the users of our products.
What bothers me most, as an Icelandic developer who prefers my native keyboard layout, is how we shun ISO third level shifts[1]. For example, when I type TILDE (U+007E; ~), I press and hold the third level shift (remapped to <Caps Lock>; traditionally <Alt Gr>), press and release <?>, and release the third level shift. Most English speaking developers use the ANSI keyboard layout[2], which historically doesn't have a notion of third level shift. Mac OS X is a terrible perpetrator by mapping the third level shift to the <⌥ option> key, which also serves as a modifier. I never know when I type COMMERCIAL AT (U+0040; @) (<Third Level Shift> + Q) whether I will input the character or quit the program.
[1]: https://en.wikipedia.org/wiki/ISO/IEC_9995#Levels_.28.E2.80....
[2]: https://en.wikipedia.org/wiki/Keyboard_layout#/media/File:AN...
---
Edit: Formatting
Erm... What is it?
I've clicked through several pages and still don't know, aside from the fact that apparently it extends the command line in some way.
But I might just be missing something.
I've clicked through several pages and still don't know, aside from the fact that apparently it extends the command line in some way.
But I might just be missing something.
It says right at the top of the home page, it's a Terminal emulator, it just happens to be written with JavaScript and HTML.
It would be nice of the title of the HN post said this (Hyper 1.0 Released, A Terminal Emulator built using Web Technologies), but it's easy to figure out once you go to the home or github page.
I fault the OP for the poor title, not the project.
It would be nice of the title of the HN post said this (Hyper 1.0 Released, A Terminal Emulator built using Web Technologies), but it's easy to figure out once you go to the home or github page.
I fault the OP for the poor title, not the project.
You're absolutely right - I missed that.
BTW, it might just be the fact I have scripts blocked, but it doesn't appear to say that on the homepage at hyper.is - just the Github page.
BTW, it might just be the fact I have scripts blocked, but it doesn't appear to say that on the homepage at hyper.is - just the Github page.
1000x This.
I'm really sooo tired of projects being introduced through Github pages which have all kinds of non-descript change-lists and commit SHAs on them but lack even the most fundamental kind of information, like what the heck does it do, especially when there's about 100 other pieces of software out there with the same name.
In this case the project does actually have a proper website (which btw. is nowhere mentioned on the Github page). Why not just link to the website instead? Is that somehow not cool enough any more?
I'm really sooo tired of projects being introduced through Github pages which have all kinds of non-descript change-lists and commit SHAs on them but lack even the most fundamental kind of information, like what the heck does it do, especially when there's about 100 other pieces of software out there with the same name.
In this case the project does actually have a proper website (which btw. is nowhere mentioned on the Github page). Why not just link to the website instead? Is that somehow not cool enough any more?
> In this case the project does actually have a proper website (which btw. is nowhere mentioned on the Github page). Why not just link to the website instead? Is that somehow not cool enough any more?
I can't sympathize at all with your sense of exasperation. I know you feel like you are arguing for a cause, but you're also being condescending.
The purpose of this post isn't to introduce a project, but to announce a significant milestone version release. With that in mind, it makes a lot more sense to link to the announcement post on github. It includes plain language descriptions of the changes, download links, plenty of screenshots, and hardly any SHAs. The website is mentioned at the very top of the main github page, as well as in several other places.
I can't sympathize at all with your sense of exasperation. I know you feel like you are arguing for a cause, but you're also being condescending.
The purpose of this post isn't to introduce a project, but to announce a significant milestone version release. With that in mind, it makes a lot more sense to link to the announcement post on github. It includes plain language descriptions of the changes, download links, plenty of screenshots, and hardly any SHAs. The website is mentioned at the very top of the main github page, as well as in several other places.
The website is mentioned at the very top of the main github page, as well as in several other places.
Yea, but it's mentioned nowhere on the page that was linked.
Yea, but it's mentioned nowhere on the page that was linked.
According to their site[0], Hyper is a terminal emulator (like xterm) written 100% in JavaScript, HTML and CSS. It is released under the MIT License.
This is definitely not obvious from the release notes.
[0] https://hyper.is/
This is definitely not obvious from the release notes.
[0] https://hyper.is/
FWIW, if you get linked to a github release page then click on the project name at the top and you will get the main repository view with a short description (above the file list) and the full README below that.
It's a shell (think iTerm2 like) built using Electron (aka web technologies in a native wrapper).
It's a terminal emulator that's configurable/extendable with JS, HTML and CSS.
Windows support is really appreciated! I just switched from a MacBook to a Surface Book, and the biggest pain point has been finding a good terminal to replace iTerm2. I'll definitely try this when I get home!
Try out conemu https://conemu.github.io/ for windows. Its great because I prefer to use git bash on windows, and you can default it and switch easily between that or powershell or cmd or WSL
A lot of people suggest CMDER these days. Looks like it is a fork of ConEmu.
It's just ConEmu packaged with some additional utilities like clink and a custom launcher. Actually quite nice since you can update to the latest version of ConEmu with no issues.
When I tried it, I found it to be slower over ConEnu. ConEmu takes some customization, but I found the experience to be better once I got past that.
thanks for the suggestion. Ill give it a try
I highly recommend babun: http://babun.github.io/
The bash shell that comes with Git for Windows is the best terminal on Windows.
https://git-for-windows.github.io/
I'm actually using the bash that's bundled with git-for-windows as the shell in Hyper and it works great.
Just kind of pointed it to that bash for easy switch and didn't really see a reason to try and find anything else.
Just kind of pointed it to that bash for easy switch and didn't really see a reason to try and find anything else.
May I ask what your launch options are? I've spend hours trying to wire up these two without success...
Yeah, the only thing I changed is the `shell` key in the .hyper.js file to point directly to the bash.exe that's bundled with git for windows.
https://gist.github.com/Klathmon/355386261e4477d9b6ee237019c...
// the shell to run when spawning a new session (i.e. /usr/local/bin/fish)
// if left empty, your system's login shell will be used by default
shell: 'C:/Program Files/Git/bin/bash.exe',
https://gist.github.com/Klathmon/355386261e4477d9b6ee237019c...
Looks like I had been pointing at the wrong bash exe the whole time... Thanks!
This is probably not the best option for you but if you want unix terminals cygwin X11 still totally works, albeit with the inevitable disadvantages of cygwin.
I run full-screen cygwin X11 so I can use fvwm2 as a manager for multiple xterms, and still find it vastly superior to any alternative for me, but I'm pretty sure I'm an outlier in that regard.
I run full-screen cygwin X11 so I can use fvwm2 as a manager for multiple xterms, and still find it vastly superior to any alternative for me, but I'm pretty sure I'm an outlier in that regard.
I switched to Windows 10 about a year ago and having tried all the options listed above I would suggest giving https://mintty.github.io/ a shot.
CMDER.
Thank me later :)
I tried hyper a week or two ago. It's fun and nice... zippy enough in everyday use and fairly pretty. But I had problems pasting commands into it, and it seems incapable of remembering multi-window layouts between sessions.
But, everybody has their own list of must-haves and deal-breakers. I'm sure hyper 1.0.0 does enough for a significant number of people out there. Congrats to the team.
But, everybody has their own list of must-haves and deal-breakers. I'm sure hyper 1.0.0 does enough for a significant number of people out there. Congrats to the team.
I've been using it since I saw this post. Impressions so far:
1. It's actually not that zippy. Do a "find /" and watch it lock up.
2. Rendering is very glitchy. Resizing the window seems to cause all hell to break loose for me and I have to restart to get things working again.
3. There are hot key problems. Sometimes hot keys (i.e. COMMAND-1 open tab 1, COMMAND-2 open tab 2) don't work, sometimes they do. Clicking in the window makes them work (temporarily) but doing some other stuff can break that again.
4. Sometimes it seems like I'm focused ON that tab, not IN the tab and I have to use my mouse fix that. That's a problem for something that's supposed to be keyboard driven.
Edit:
5. I tried to exit the application and now I'm stuck in an infinite modal dialog "uncaught exception" loop.
It looks like a very promising application, but a replacement for iTerm 2 it is not. This feels like this should be a 0.10 release and not a 1.0 release to me. This app is not robust enough to justify 1.0. :(
1. It's actually not that zippy. Do a "find /" and watch it lock up.
2. Rendering is very glitchy. Resizing the window seems to cause all hell to break loose for me and I have to restart to get things working again.
3. There are hot key problems. Sometimes hot keys (i.e. COMMAND-1 open tab 1, COMMAND-2 open tab 2) don't work, sometimes they do. Clicking in the window makes them work (temporarily) but doing some other stuff can break that again.
4. Sometimes it seems like I'm focused ON that tab, not IN the tab and I have to use my mouse fix that. That's a problem for something that's supposed to be keyboard driven.
Edit:
5. I tried to exit the application and now I'm stuck in an infinite modal dialog "uncaught exception" loop.
It looks like a very promising application, but a replacement for iTerm 2 it is not. This feels like this should be a 0.10 release and not a 1.0 release to me. This app is not robust enough to justify 1.0. :(
I've had good luck with wetty: https://github.com/krishnasrinivas/wetty
It seems reasonably stable and fast, I suspect because it leverages the hterm terminal emulator that's built into ChromeOS. May not work on Windows or OSX though.
It seems reasonably stable and fast, I suspect because it leverages the hterm terminal emulator that's built into ChromeOS. May not work on Windows or OSX though.
Yeah, it's pretty sluggish rendering my fullscreen tmux session with three panes and six vim splits.
It also doesn't seem to recognize my alt+h (j/k/l) shortcuts to switch tmux panes, just prints odd characters in the terminal.
It also doesn't seem to recognize my alt+h (j/k/l) shortcuts to switch tmux panes, just prints odd characters in the terminal.
A 50MB download ( zipped ) for an Terminal App. 64MB for Slack on Windows.
150MB+ when installed, Few hundred MB Ram when running.
And just like Web Browsers, lot of little lock up and Jank.
Seriously I dont mind Apps with Web Technologies, but these problems needs to be taken into account for improvement. Opera, before switching to Chrome / Blink, were an Full Browser, with Email, RSS Reader, all packed under 11MB.
150MB+ when installed, Few hundred MB Ram when running.
And just like Web Browsers, lot of little lock up and Jank.
Seriously I dont mind Apps with Web Technologies, but these problems needs to be taken into account for improvement. Opera, before switching to Chrome / Blink, were an Full Browser, with Email, RSS Reader, all packed under 11MB.
I'm curious, on what modern computer would 150MB cause storage issues?
For work I am running a 13" MPBr with 128GB SSD. 150MB for a terminal app is... I don't know. iTerm is 14MB.
Terminal is one of those mission critical apps that I must be able to depend on at all times. The last thing I want is for my terminal program itself to be leaking memory all over the place which seems to be common with electron type apps.
Dependability has to come before the bells and whistles and this appears to be a long ways out just skimming through the amount of bugs that are caught in this comments section.
Dependability has to come before the bells and whistles and this appears to be a long ways out just skimming through the amount of bugs that are caught in this comments section.
I tried switching to Hyper from iTerm 2 and found it a bit too sluggish with no real advantages over iTerm (but I haven't tried any extensions)
I'd probably use it on Windows though.
I'd probably use it on Windows though.
Zeit team is amazing, thier OSS is examplary; what they've achieved/ing in relatively short time is astounding. I highly recommend their blog [1], an absolute joy to read.
Congrats to the team and all the contributors.
[1] https://zeit.co/blog/
Congrats to the team and all the contributors.
[1] https://zeit.co/blog/
I'm incredibly confused about why I should switch from iTerm. If you've been using Hyper, can you tell me why you switched and what was better?
If you frequently use the command line, it's probably not for you. Think of this as similar to the Atom text editor. With html/css/js, you can create your own packages and themes or download one from the community.
I'm a simple man and like pretty, shiny things, like occasionally activating power mode, or playing the John Cena theme when you open a new tab. Stupid shit like this keeps my morale up.
I'm a simple man and like pretty, shiny things, like occasionally activating power mode, or playing the John Cena theme when you open a new tab. Stupid shit like this keeps my morale up.
- looks nicer
- easier to customize (at least for me)
- runs super smooth (not that iTerm was slow or anything)
- I'd have to confirm, but a lot syntax highlighting and things that I just want to "work" out of the box seemed more applicable to Hyper than iTerm
- extensions (not sure if iTerms extension community could rival npm)
- easier to customize (at least for me)
- runs super smooth (not that iTerm was slow or anything)
- I'd have to confirm, but a lot syntax highlighting and things that I just want to "work" out of the box seemed more applicable to Hyper than iTerm
- extensions (not sure if iTerms extension community could rival npm)
Does it automatically recognize divisions printed by programs running in the terminal and use that to determine what text to select? (i.e. if I do a vertical split in vim, does it restrict text selection to one side or the other of the split?
1. Hyperpower plugin. power mode on, sync with my techno songs.
2. More disk space.
3. Can open facebook via terminal.
1. Your short description of "hyper power" plug-ins doesn't inspire hope.
2. How much disk space savings? 20MB? Please.
3. Wow, much features, such productivity.
2. How much disk space savings? 20MB? Please.
3. Wow, much features, such productivity.
> 3. Wow, much features, such productivity.
Not to mention that both xdg-open and open can both do that on GNU/Linux and OS X, respectively.
Not to mention that both xdg-open and open can both do that on GNU/Linux and OS X, respectively.
Yay! My favorite new feature is "vibrancy" using the modern OS X API for that. Terminal.app still uses Quartz filters for the blur effect, which while more flexible offers way slower performance whenever there's something animated on the background, like a video playing.
Looks really cool but I'd want to better understand how a web technology console application would fare performance and stability wise compared to terminal.app, iTerm 2 and other console applications. Looks cool though and congrats to the team on hitting 1.0.0
Try `ps -afx` in Hyper. Then in iTerm 2. Though I love the ideas behind Hyper, I'm going to stick with iTerm 2 as my daily terminal for now.
Also try `yes` in Hyper, see what happens.
Note, don't actually try this as it will lock up Hyper and you'll have to force quit it.
The benefits of your terminal emulator allocating a new DOM element in a web browser for every line of output. You can also watch Hyper's memory use climb up at a constant rate
It doesn't have to allocate a new DOM element for every line. It could recycle DOM elements as the terminal grows. This is a method that some JS libraries use, seems like Hyper probably doesn't.
what the... is that supposed to be piped into cli programs that don't have a -y switch?
Yes.
I have a program at work that does something like
Do you want to remove x from y? [y/n]
Do you want to remove z from y? [y/n]
Do you want to remove a from y? [y/n]
etc. etc, 100s of times. yes is a lifesaver.
I also like how it's used as an experiment for basic optimization: https://www.reddit.com/r/rust/comments/4wde08/optimising_yes...
4.5 GB/s of 'y'. Hilarious.
I have a program at work that does something like
Do you want to remove x from y? [y/n]
Do you want to remove z from y? [y/n]
Do you want to remove a from y? [y/n]
etc. etc, 100s of times. yes is a lifesaver.
I also like how it's used as an experiment for basic optimization: https://www.reddit.com/r/rust/comments/4wde08/optimising_yes...
4.5 GB/s of 'y'. Hilarious.
yes
Yes, that's exactly what it's for.
I have been using using Hyper kinda since the beginning and eventually switched back to iTerm because it's way faster if you use it all day long.
Maybe they improved performance with this version, I will see.
Maybe they improved performance with this version, I will see.
I tried iTerm and then Hyper, and didn't really see how either benefited me over Terminal.app so I stuck with that. But these days I do most of my development work inside Emacs, and the vast majority of my Terminal.app usage has been replaced by either a first-class Emacs plugin (like Magit[0] for git) or Eshell[1] within Emacs.
[0]: https://magit.vc/
[1]: https://www.gnu.org/software/emacs/manual/eshell.html
[0]: https://magit.vc/
[1]: https://www.gnu.org/software/emacs/manual/eshell.html
The main thing for me is split panes, but I don't primarily use an editor like Emacs that can do split panes, and I never bothered to learn tmux (iTerm does have neat tmux integration though)
Ah right, split panes are pretty nifty. Very easy to do in Emacs and convenient too. When I'm using Terminal.app, I just use two windows and place them side-by-side if needed. But most of the time a single windows suffice for the small things I'm doing.
I am from the cult of vim, using neovim and tmux all day.
What I like about iTerm are the many small options that allow me to tweak it a bit here and there.
What I like about iTerm are the many small options that allow me to tweak it a bit here and there.
> I have been using using Hyper kinda since the beginning and eventually switched back to iTerm because it's way faster if you use it all day long.
This is how I feel about Sublime Text vs Atom. Every time I try to switch to Atom, I run into this problem. The slight sluggishness gets increasingly annoying the more time I spend using it.
This is how I feel about Sublime Text vs Atom. Every time I try to switch to Atom, I run into this problem. The slight sluggishness gets increasingly annoying the more time I spend using it.
I was using Atom for a long time and performance got better over time. I like to use OSS so Sublime was not an option for me.
Once I went back to vim, though, I was impressed again by its performance.
It's a pity that electron still has some trouble with performance. Slack, for example, does not make me happy. Visual Studio Code, on the other hand, is fast and is written using the same platform so there must be a way to do it right.
Once I went back to vim, though, I was impressed again by its performance.
It's a pity that electron still has some trouble with performance. Slack, for example, does not make me happy. Visual Studio Code, on the other hand, is fast and is written using the same platform so there must be a way to do it right.
This was exactly my experience. I didn't see any benefit over iTerm 2 and the performance was just sluggish enough to be subconsciously annoying after awhile.
As far as windows performance goes, @rauchg posted this on Twitter today - https://twitter.com/rauchg/status/808353136926593024
Performance and stability wise, not quite as well.
However, the ability for quick, easy, and familiar customization and automation for web developers is hard to deny either.
However, the ability for quick, easy, and familiar customization and automation for web developers is hard to deny either.
I've been very surprised so far by how little memory and how performant this terminal is even though it's written in JavaScript and runs on electron. All the other electron apps I know of are kind of known to be performance hogs (atom, slack). So it's refreshing to see something neat like this that also works well.
Why? I don't need a hyper extensible terminal emulator. All I need is some form of customization (so I can use solarized: I happen to like it), the ability to select fonts (Terminus is the best font, by the way), and the ability to produce Unicode characters properly (and even that is optional). Oh, and VT-100 emulation at the very least. That's just kind of expected.
URxvt, XTerm, etc. do this very well, and they're also quite fast. Why would I switch to an implementation that is demonstrably worse at everything I care about, and better at things that don't matter? Do I just really hate my DRAM, and want to see it under constant max use?
URxvt, XTerm, etc. do this very well, and they're also quite fast. Why would I switch to an implementation that is demonstrably worse at everything I care about, and better at things that don't matter? Do I just really hate my DRAM, and want to see it under constant max use?
I find the idea interesting, but the execution leaves much to be desired. I'm using it on Windows and some of the basic readline shortcuts don't appear to work correctly (e.g. ctrl+a is doing select all instead of moving the cursor to the beginning of the line.) It also doesn't seem to have any mouse support, like the ability to scroll or resize panes in tmux. There's a very real need for better terminal emulation on Windows, but this doesn't seem to deliver.
I’ve been using Hyper on and off for a while now. I recently returned to zsh in iTerm2 for the same reasons many others mentioned here. It _works_.
I still do toy with Hyper from time to time. A feature I do like is the hotkey-enabled pane-splitting. CMD+D to open a vertical pane. CMD+SHIFT+D to open a horizontal pane. CMD+W closes them — though I wish this option would prompt as I’ve accidentally closed panes a number of times by a poorly-timed keystroke. For somebody who doesn’t use swap files with VIM, this can be a killer.
I am very much looking forward to installing this on my Windows machine tonight, however. ConEmu is a beast, but sometimes I just want quick, simple access to a text editor or a few commands in a familiar environment.
Some days jumping into ConEmu feels like an alien world (especially when it comes to setup/options), and Powershell just so different from what I work in most of the time.
The bit of crossover, even if there are a few sacrifices, is appreciated as an option here.
I still do toy with Hyper from time to time. A feature I do like is the hotkey-enabled pane-splitting. CMD+D to open a vertical pane. CMD+SHIFT+D to open a horizontal pane. CMD+W closes them — though I wish this option would prompt as I’ve accidentally closed panes a number of times by a poorly-timed keystroke. For somebody who doesn’t use swap files with VIM, this can be a killer.
I am very much looking forward to installing this on my Windows machine tonight, however. ConEmu is a beast, but sometimes I just want quick, simple access to a text editor or a few commands in a familiar environment.
Some days jumping into ConEmu feels like an alien world (especially when it comes to setup/options), and Powershell just so different from what I work in most of the time.
The bit of crossover, even if there are a few sacrifices, is appreciated as an option here.
> I’ve accidentally closed panes a number of times by a poorly-timed keystroke.
PSA: In iTerm you can hit CMD+Z within a few seconds to unclose a tab or window.
PSA: In iTerm you can hit CMD+Z within a few seconds to unclose a tab or window.
Thanks for the tip. That will be useful.
The 'rewrite everything in Javascript' hysteria reminds me of the 'rewrite everything in Java' hysteria we saw a couple of decades ago.
I wonder if it will end the same way. Will Javascript eventually go on to die where all languages go to die -- as as enterprise backend language?
I wonder if it will end the same way. Will Javascript eventually go on to die where all languages go to die -- as as enterprise backend language?
I tried Hyper out a while back because I thought the customizability offered interesting options and the ability to have terminal and browser tabs literally side by side, in the same window, had the potential for a good workflow.
I ended up switching back to iTerm2 because encountering minor bugs was a frequent enough occurrence and iTerm2 works perfectly well for me.
I'm now curious what people who have been using Hyper consistently think about its usability and whether it's worth it to switch over? For me, worth it means at least matching iTerm2 in basic functionality and utility, having no noticeable performance issues, and not being a high battery drain. Thoughts?
I ended up switching back to iTerm2 because encountering minor bugs was a frequent enough occurrence and iTerm2 works perfectly well for me.
I'm now curious what people who have been using Hyper consistently think about its usability and whether it's worth it to switch over? For me, worth it means at least matching iTerm2 in basic functionality and utility, having no noticeable performance issues, and not being a high battery drain. Thoughts?
I have a idea for a kind of terminal (but not a terminal emulator) more in the style of ipython. But the trouble is that multi platform is complicated.
Is possible to have a fast html rendered just for the UI and use native code for the rest?
Is possible to have a fast html rendered just for the UI and use native code for the rest?
Sure, with Electron/Node you can easily do that: https://nodejs.org/api/addons.html
A good example for a performant Electron/Node application is Microsoft VSCode
A good example for a performant Electron/Node application is Microsoft VSCode
Mmm... maybe I was not clear.
I like how html/css work for build the UI, but wish not to use node at all. Also, exist a engine more light and fast than webkit?
I like how html/css work for build the UI, but wish not to use node at all. Also, exist a engine more light and fast than webkit?
if you're using native code anyway, why not just use gtk or qt? they both solve the "multiplatform is complicated" issue, as long as you're willing to compile separately on each platform and host native executables for end users to download.
This is amazing. It looks 100 times better than anything available.
It doesn't have tab reordering, nor "close other tabs"/"close tabs on the right", but I'm sure there are plugins for that.
It doesn't have tab reordering, nor "close other tabs"/"close tabs on the right", but I'm sure there are plugins for that.
This should be the default terminal software for all IoT devices. >:)
Is this what used to be HyperTerminal?
I thought this was about Hyper, the Rust crate for HTTP functions.[1] That's at 0.9.14 and has major outstanding bug reports. If that had reached 1.0.0, that would be significant.
[1] https://crates.io/crates/hyper
I thought this was about Hyper, the Rust crate for HTTP functions.[1] That's at 0.9.14 and has major outstanding bug reports. If that had reached 1.0.0, that would be significant.
[1] https://crates.io/crates/hyper
It feels pretty performant and I don't mind the extra ram usage, however, I can't afford the constant 10+% cpu usage. Even when it's just sitting there, it's constantly eating tons of cycles.
Is that a problem exclusive to the Windows version? Is there any setting I should tweak?
Is that a problem exclusive to the Windows version? Is there any setting I should tweak?
Funny this comes out today, I was looking for a good terminal that would look decent when used with bash on ubuntu on windows. I tried xming and urxvt but fonts and colors were a nightmare, maybe this will be better.
Just tried in windows and compare it to cmder by opening a small json file in vim. cmder is much quicker rendering the next page of code. I guess is still much more good looking than cmder though.
So let me get this straight. This is a mini-webserver written in Javascript running the terminal as a webapp in a mini-webbrowser, right? This makes sense why?
On the other hand: My favorite iOS SSH/Mosh client seems to be built on top of this and it's awesome.
On the other hand: My favorite iOS SSH/Mosh client seems to be built on top of this and it's awesome.
This makes sense because the authors were comfortable writing apps this way. At least they started it on a stack that has the potential to be multi platform. I see way too many nice / stylish apps released as OSX only.
But it's only the potential. In practice you still have to depend on the vendor to decide to support your OS.
On the other hand, it's really hard to make a closed-source app that you can sell, and still make it cross-platform.
I don't think if you plan ahead it would be to disaster to maintain. We have tools like QT or Skia that help you create native cross platform UI-s. I agree that the dev experience is a light-year ahead with CSS+JS, I've done it before, but once you go down that road, it's close to impossible to switch without a serious rewrite. This is not necessarily a bad thing, but something to keep in mind.
Looks like it is using the electron framework http://electron.atom.io/
To be sure, JavaScript can sometimes be fairly terrible as the scope of projects grow. The advantage here is how easily rich (or even absurd) UI elements can be implemented across all platforms by using web technologies. It also makes it comparatively easy to create a platform that is highly customizable and pluggable.
To be sure, JavaScript can sometimes be fairly terrible as the scope of projects grow. The advantage here is how easily rich (or even absurd) UI elements can be implemented across all platforms by using web technologies. It also makes it comparatively easy to create a platform that is highly customizable and pluggable.
I'm excited because that would still be better than the terminals currently available for Windows.
It makes sense because JavaScript has, through several bizarre turns of events, become the language du jour, which means all sort of clueless people are falling over themselves to abuse it in increasingly convoluted ways, so that the clueless people in corporate HR who've been told "We need someone who is a JavaScript rockstar!" can be wowed by the description of some nightmarish contraption that "really takes insane JavaScript chops".
Language fads are very tiring.
Language fads are very tiring.
You know what's tiring? People getting out of their way to gratuitously criticize the collective effort of a coordinated group of passionate people who just want to have fun reinventing the wheel.
the collective effort of a coordinated group of passionate people who just want to have fun reinventing the wheel
Best long winded alias for the field of programming to date!
Best long winded alias for the field of programming to date!
I wouldn't say my post is gratuitous criticism. I believe my post describes the motives behind a sizable number of such projects. If that is not the case with Hyper, and the Hyper developers are aware and conscious that they made a bizarre language choice and are just trying to have fun with it (although they do seem to be recommending that random people use this as production, non-toy software), then that's great, more power to them. There's no reason for them to be offended or unsure of themselves based on my comments.
> passionate people who just want to have fun reinventing the wheel
Maybe instead of building square wheels they should work on improving some of the existing round wheels.
Maybe instead of building square wheels they should work on improving some of the existing round wheels.
Some people make round wheels better. Some people try to create a better wheel than a round one. Both types are usually good for society. The former is most likely to yield any results at all; the latter, when it yields any results, is most likely to produce massive steps forward.
Where would we be if Einstein had spent all his time trying to improve Newton's gravity rather than reinventing it?
Where would we be if Einstein had spent all his time trying to improve Newton's gravity rather than reinventing it?
Where would we be if Einstein had spent all his time
trying to improve Newton's gravity rather than
reinventing it?
General Relativity is the implication of Special Relativity being true, generalized for all observers.
Einstein's approach was very much step 1, just repeated 2-3 times.
Special Relativity didn't necessarily destroy Newton's gravity. To be generalized in GR gravity had to stop being force. It was just a natural implication of a prior step.
The idea you can chase a total alien solution nobody supports and pull complete magic out of thin air is rarely true. Normally it is just a myth created by people who don't actually understand the solution or process that attained it.
General relativity was seen as a huge leap forward at the time, and it still is today. I offer two quotes in support of this:
"As an older frield I must advise you against [generalizing relativity to incorporate gravity] for in the first place you will not succeed, and even if you succeed, no one will believe you." - Max Planck to Einstein, 2 years before Einstein succeeded. It was a big deal to even attempt to do this, and people tried to talk Einstein out of it.
And why did Planck say no one would believe Einstein? Because Einstein was trying to do something fundamentally different; he was trying to create a new kind of wheel.
"Newton, forgive me." - Albert Einstein -- why ask for forgiveness?
Einstein's role was something quite different from the role that most physicists play. Most physicists add small refinements to existing theories. Einstein upended quite a lot of existing physics and replaced it with something new. Newton saw gravity as action at a distance. Einstein showed that it was something quite different.
"As an older frield I must advise you against [generalizing relativity to incorporate gravity] for in the first place you will not succeed, and even if you succeed, no one will believe you." - Max Planck to Einstein, 2 years before Einstein succeeded. It was a big deal to even attempt to do this, and people tried to talk Einstein out of it.
And why did Planck say no one would believe Einstein? Because Einstein was trying to do something fundamentally different; he was trying to create a new kind of wheel.
"Newton, forgive me." - Albert Einstein -- why ask for forgiveness?
Einstein's role was something quite different from the role that most physicists play. Most physicists add small refinements to existing theories. Einstein upended quite a lot of existing physics and replaced it with something new. Newton saw gravity as action at a distance. Einstein showed that it was something quite different.
Einstein got there by starting with the conventional models and knowing it didn't fit, and working on a way to make it fit.
Einstein didn't start out in left field, he didn't set out to invent a new wheel. He just saw some problems in the old one, and suggested an updated wheel that would resolve them. That's the difference. One is being contrarian or experimenting on their own, which is not necessarily wrong and can certainly be useful experience to draw on, but it's just not likely to yield large advancements on its own.
Large advancements occur when someone is current with the cutting edge, accepting of the established truths, and still striving to solve the larger puzzle (which may involve rotating the puzzle pieces that make up parts of the "established truths" -- but you can't get there if you don't have the pieces at your disposal).
Do you suggest that these people set out to make a great terminal emulator, and were eventually driven into the arms of JavaScript as the one true answer to the fundamental problem?
I think it's more likely that they said "Let's try to do this thing that's been done hundreds of times ... IN JAVASCRIPT!!!" And again, there's not anything wrong with that per se. It just doesn't make a good value proposition when you're trying to convince users to use your product.
Einstein didn't start out in left field, he didn't set out to invent a new wheel. He just saw some problems in the old one, and suggested an updated wheel that would resolve them. That's the difference. One is being contrarian or experimenting on their own, which is not necessarily wrong and can certainly be useful experience to draw on, but it's just not likely to yield large advancements on its own.
Large advancements occur when someone is current with the cutting edge, accepting of the established truths, and still striving to solve the larger puzzle (which may involve rotating the puzzle pieces that make up parts of the "established truths" -- but you can't get there if you don't have the pieces at your disposal).
Do you suggest that these people set out to make a great terminal emulator, and were eventually driven into the arms of JavaScript as the one true answer to the fundamental problem?
I think it's more likely that they said "Let's try to do this thing that's been done hundreds of times ... IN JAVASCRIPT!!!" And again, there's not anything wrong with that per se. It just doesn't make a good value proposition when you're trying to convince users to use your product.
You offer vague platitude where I offer mathematics.
I'll repeat this quote
The idea you can chase a total alien solution nobody supports and pull complete magic out of thin air is rarely true. Normally it is just a myth created by people who don't actually understand the solution or process that attained it.
I'll repeat this quote
The idea you can chase a total alien solution nobody supports and pull complete magic out of thin air is rarely true. Normally it is just a myth created by people who don't actually understand the solution or process that attained it.
You know what's tiring have to over time be forced to use or maintain people's poor decision to reinvent the wheel.
Don't complain. Figure out how to charge consulting fees!
JavaScript has become the PHP of ten years ago.
Runs everywhere (client and server), is the language picked up by beginners, and is abused to fit every square peg into a round hole.
Runs everywhere (client and server), is the language picked up by beginners, and is abused to fit every square peg into a round hole.
Can't wait for the general sentiment to turn to match. Whereas PHP has been sneered at by non-PHP devs since time immemorial, JavaScript is seeing widespread uptake by supposedly "senior" people across the spectrum.
I've asked several of these people to explain the attraction (one of whom had a fascination with the even-worse CoffeeScript) and thus far I have not really come across a satisfactory explanation. To me, JavaScript is still the language you only use when you have to because it's the only runtime the browser vendors will embed.
I've asked several of these people to explain the attraction (one of whom had a fascination with the even-worse CoffeeScript) and thus far I have not really come across a satisfactory explanation. To me, JavaScript is still the language you only use when you have to because it's the only runtime the browser vendors will embed.
I've asked several of these people to explain the attraction
http://quoteinvestigator.com/2013/02/10/where-money-is/
Javascript is a "workable" or "decent" language, and it happens to run where the users are. This is also a large part of why C++ was a success and C before it.
http://quoteinvestigator.com/2013/02/10/where-money-is/
Javascript is a "workable" or "decent" language, and it happens to run where the users are. This is also a large part of why C++ was a success and C before it.
This works when you're executing code "where the users are", as I conceded in the parent post (it's the language you use when you have to). It doesn't explain why they'd willingly switch away from another server-side language to re-implement the whole thing in server-side JavaScript.
The only really "good" reason in my opinion is to use the same code that renders the page in the browser to be used to render the page on the server. I've never seen this done well in production though.
Dav Glass did some awesome hack day projects in the early days of Node.js demonstrating how this could work for Yahoo mail. Hit your inbox for the first time in a browser session and it'll send back a full HTML page rather than a bunch of JS files and expect the client to render before anything appears. With this you could have less than one second full render times for a complex single page app. Imagine if Gmail did something like this, you wouldn't need to leave a tab open to avoid the 5-10sec it takes from login till inbox shows. Furthermore, you could build this out further where if the "compose page" JavaScript hadn't loaded yet, you could then roundtrip to the server and get the markup rather than waiting on it to parse and execute on a slower machine.
Not saying everyone should do this obviously, but it is a valid use case for JavaScript on the server if done right IMHO.
Dav Glass did some awesome hack day projects in the early days of Node.js demonstrating how this could work for Yahoo mail. Hit your inbox for the first time in a browser session and it'll send back a full HTML page rather than a bunch of JS files and expect the client to render before anything appears. With this you could have less than one second full render times for a complex single page app. Imagine if Gmail did something like this, you wouldn't need to leave a tab open to avoid the 5-10sec it takes from login till inbox shows. Furthermore, you could build this out further where if the "compose page" JavaScript hadn't loaded yet, you could then roundtrip to the server and get the markup rather than waiting on it to parse and execute on a slower machine.
Not saying everyone should do this obviously, but it is a valid use case for JavaScript on the server if done right IMHO.
I can't really defend their language choice perse, but if you look at the aims of the project - make a terminal that's consistent across platforms and focuses on extendability and interface, what IS your best option? Writing natively for each platform doesn't seem feasible. Using something browser based that has many of those cross platform kinks ironed out doesn't seem like that bad of a choice if that's your top priority.
Whether or not that makes it a solid, durable terminal program is another question, though.
Whether or not that makes it a solid, durable terminal program is another question, though.
There's numerous cross-platform alternatives to using JavaScript. Not saying they are inherently better, but there are a hundred different ways to accomplish this.
OK, sure, but not exactly what I was pointing out.
If your goal is to provide a consistent look and user experience across platforms and be easily extendable, what do you choose? Feel free to name one.
If your goal is to provide a consistent look and user experience across platforms and be easily extendable, what do you choose? Feel free to name one.
Remember, this is a terminal emulator. It's fairly easy to get a consistent look and feel, even across platforms.
You asked for one, here's five:
* GTK+
* wxWidgets
* Swing
* SWT
* Tcl/Tk
You then mentioned "easily extendable". I'm not sure if you'll agree Swing/SWT are easily extendable (I'd argue they can be), but wxWidgets and GTK+ have bindings available in many common scripting languages (heck, even PHP!) which are just as easy to extend as JavaScript is.
Again, I'm not arguing any of these are better suited, just responding to your point that there was no alternative.
You asked for one, here's five:
* GTK+
* wxWidgets
* Swing
* SWT
* Tcl/Tk
You then mentioned "easily extendable". I'm not sure if you'll agree Swing/SWT are easily extendable (I'd argue they can be), but wxWidgets and GTK+ have bindings available in many common scripting languages (heck, even PHP!) which are just as easy to extend as JavaScript is.
Again, I'm not arguing any of these are better suited, just responding to your point that there was no alternative.
I said it "isn't a bad choice", not "there is no other alternative".
Of the 5 alternates you provided, can you name me an app that runs on major platforms that people describe as a good user experience? Not just that they work, but that they serve as good example of how to design a user experience. The only one that I can think of that I use on an everyday basis is the JetBrains apps which are built in java, although what UI implementation they're using I'm unsure. Beyond that, all the good cross platform apps that I can think that aren't using something webkit based (slack/atom/discord/etc) use native OS GUI implementations. I'm sure there are others, but it's hard to completely discredit the browser-as-an-app approach.
From what I gathered from the project, it's aim is to go beyond being just another terminal emulator and provide a certain amount of bells and whistles through its interface. Turns out interface bells and whistles is something that HTML+CSS+Javascript has nailed pretty well while remaining cross platform compatible.
Of the 5 alternates you provided, can you name me an app that runs on major platforms that people describe as a good user experience? Not just that they work, but that they serve as good example of how to design a user experience. The only one that I can think of that I use on an everyday basis is the JetBrains apps which are built in java, although what UI implementation they're using I'm unsure. Beyond that, all the good cross platform apps that I can think that aren't using something webkit based (slack/atom/discord/etc) use native OS GUI implementations. I'm sure there are others, but it's hard to completely discredit the browser-as-an-app approach.
From what I gathered from the project, it's aim is to go beyond being just another terminal emulator and provide a certain amount of bells and whistles through its interface. Turns out interface bells and whistles is something that HTML+CSS+Javascript has nailed pretty well while remaining cross platform compatible.
First, I've never understood the obsession with the "native feel". I guess it just irks some people in a basic way that I can't relate to at all.
However, the major cross-platform toolkits of wxWidgets, Qt, and GTK+ have run long projects to allow for native interface components on the platforms they support. This is usually something that can be configured at compile time.
VLC is wxWidgets and it offers a consistent user experience across platforms. Chromium is GTK+ and it does so as well. I'm not sure what's trendy in the UX snob circles these days so I don't know if they qualify as "amazing UX" or not, but they're two widely-used, major projects that incorporate standard cross-platform desktop toolkits.
Personally, I've always been partial to Qt, though I can't think of something off the top of my head that uses Qt and has widespread usage across platforms (Qt of course powers the entire KDE suite, but that usually doesn't cross over to Mac or Windows users, and Amarok's glory days are long gone). I guess Clementine uses Qt, and it may be widely used. I used it on both Win and Linux and the UX is identical.
However, the major cross-platform toolkits of wxWidgets, Qt, and GTK+ have run long projects to allow for native interface components on the platforms they support. This is usually something that can be configured at compile time.
VLC is wxWidgets and it offers a consistent user experience across platforms. Chromium is GTK+ and it does so as well. I'm not sure what's trendy in the UX snob circles these days so I don't know if they qualify as "amazing UX" or not, but they're two widely-used, major projects that incorporate standard cross-platform desktop toolkits.
Personally, I've always been partial to Qt, though I can't think of something off the top of my head that uses Qt and has widespread usage across platforms (Qt of course powers the entire KDE suite, but that usually doesn't cross over to Mac or Windows users, and Amarok's glory days are long gone). I guess Clementine uses Qt, and it may be widely used. I used it on both Win and Linux and the UX is identical.
Because it's the same code as the client, which is "where the users are." I guess you'd assert that having the same language on the client and server doesn't justify the cost of using the language.
Correct. This argument, IMO, is mainly made by programmers who are afraid of working in more than one language at once, traditionally .NET developers who are used to an entire, ready-made, tied-up-in-a-bow ecosystem being dropped on their doorstep. I have a lot of trouble sympathizing with that perspective (even though I've had multiple jobs as a full-time .NET developer).
JavaScript is not good. We should be working to get it out of the way, not converting everything in our environments to run on it.
JavaScript is not good. We should be working to get it out of the way, not converting everything in our environments to run on it.
This is a desktop app, "where the users are" isn't a compelling argument because it could be in practically any language and have the same barrier to entry.
Does it culminate with a cryptocash exchange written in it?
This made my whole day. Time for bed.
the language du jour, which means all sort of clueless people are falling over themselves to abuse it in increasingly convoluted ways
That's simply how the programming "field" works. Also in the category of "how it works": People grousing about it. (Seriously, that is the way it works, and do we dare suppose there is a better way?)
That's simply how the programming "field" works. Also in the category of "how it works": People grousing about it. (Seriously, that is the way it works, and do we dare suppose there is a better way?)
One of the worst possible things: to get a sense of what the hell Hyper is, you need to scroll down and find it.
I really don't understand why their first line isn't: "Hyper is a ..."
I really don't understand why their first line isn't: "Hyper is a ..."
Because we're looking at a link to release notes, which I would expect the hyper devs expected people to come to -after- looking at the project page.
One of those situations where submissions being a single URL isn't quite ideal.
One of those situations where submissions being a single URL isn't quite ideal.
uses quite a bit of cpu on my little dual core i5, terminal looks great tho
EDIT:
Also who came up with using the hotkeys (Alt + Ctrl + tab) & (Alt + Ctrl + Shift + tab), How are you even supposed to use those O.o
EDIT:
Also who came up with using the hotkeys (Alt + Ctrl + tab) & (Alt + Ctrl + Shift + tab), How are you even supposed to use those O.o
If you choose to install this via homebrew, be aware that there are actually two hypers that can easily be installed.
This Terminal Emulator: brew cask install hyper
Docker Hosting: brew install hyper
This Terminal Emulator: brew cask install hyper
Docker Hosting: brew install hyper
As much as I love this project, the commit messages and release notes are terrible for figuring out what's been fixed. Actually the only way I was able to track bugs was by watching the repo and seeing everything or checking in on an issue every so often. For releases they've streamlined it but I still have to dive into the code between releases to find fixes and reverts.
I've switched back to iterm2 due to these two issues which can easily be fixed by the maintainer(s)
I've switched back to iterm2 due to these two issues which can easily be fixed by the maintainer(s)
Looks cool, but for some weird reason I was expecting something related to Apple's HyperCard <3 :D
Fails my standard "Too many clicks to understand what this is" test.
Posted link has virtually no description of what the project is.
Going to the root of the github repo has release notes and with the most detailed description as "HTML/CSS/JS Terminal" but burned into a PNG file.
Best description of the product is on "hyper.is" in an animated GIF form.
People working on project like this need to understand that without a reasonable textual description of their product, outlining basic features and benefits over other existing systems, that the uptake is going to be very, very low.
Posted link has virtually no description of what the project is.
Going to the root of the github repo has release notes and with the most detailed description as "HTML/CSS/JS Terminal" but burned into a PNG file.
Best description of the product is on "hyper.is" in an animated GIF form.
People working on project like this need to understand that without a reasonable textual description of their product, outlining basic features and benefits over other existing systems, that the uptake is going to be very, very low.
This is right at the top of the GitHub page:
> A terminal built on web technologies https://hyper.is
On the home page, the very first thing it says is:
>Hyper™ JS/HTML/CSS Terminal
Then I scroll down and everything else I see pretty much confirms this. It's a terminal which uses HTML and JavaScript to make things look pretty (which is what I would have inferred from both of those descriptions).
I've seen some terrible pages, but I think you're being a bit harsh on this one.
> A terminal built on web technologies https://hyper.is
On the home page, the very first thing it says is:
>Hyper™ JS/HTML/CSS Terminal
Then I scroll down and everything else I see pretty much confirms this. It's a terminal which uses HTML and JavaScript to make things look pretty (which is what I would have inferred from both of those descriptions).
I've seen some terrible pages, but I think you're being a bit harsh on this one.
Not sure if "that the uptake is going to be very, very low" is very true, since the project has over 11000 stars on Github and I've seen people in the wild using it. But I'm a web developer, so...
Also, I found it easy to figure out what it was. Github description has " A terminal built on web technologies", website says "JS/HTML/CSS Terminal" and the readme mentions "HTML/JS/CSS Terminal" again. Sure, would be nice of a description of what the basic features and such there is, but probably not needed for their target developers, web developers who want to be able to modify their terminal.
Btw, I don't use Hyper myself, just felt that parent comment was a bit off.
Also, I found it easy to figure out what it was. Github description has " A terminal built on web technologies", website says "JS/HTML/CSS Terminal" and the readme mentions "HTML/JS/CSS Terminal" again. Sure, would be nice of a description of what the basic features and such there is, but probably not needed for their target developers, web developers who want to be able to modify their terminal.
Btw, I don't use Hyper myself, just felt that parent comment was a bit off.
Hmm, I've never personally heard of or used the product, but I immediately understood it was, just from the release notes. What more were you looking for to clarify what it is?
This was the version page on github.
If you go to the root github readme "A terminal built on web technologies https://hyper.is"
> People working on project like this need to understand that without a reasonable textual description of their product, outlining basic features and benefits over other existing systems, that the uptake is going to be very, very low.
For people using terminals I would HOPE people would know what "HTML/CSS/JS used to make a terminal means. What audience is this going to reach? Most will find this to be a unholy heresy and we will stick with our urtv terminals.
If you go to the root github readme "A terminal built on web technologies https://hyper.is"
> People working on project like this need to understand that without a reasonable textual description of their product, outlining basic features and benefits over other existing systems, that the uptake is going to be very, very low.
For people using terminals I would HOPE people would know what "HTML/CSS/JS used to make a terminal means. What audience is this going to reach? Most will find this to be a unholy heresy and we will stick with our urtv terminals.
These are release notes so don't expect a project description there. And I think the gif on the homepage makes it perfectly clear (to me at least).
I wish more projects would adopt this mentality. I feel like there was a time whenever you went to a project page the first thing you would find was a description and how it was helpful, followed by screenshots and a quick start guide.
Nowadays they all just tell you what was in the latest release, or give some instructions on how to install it without telling me why I should even bother take time out of my day to install it.
Nowadays they all just tell you what was in the latest release, or give some instructions on how to install it without telling me why I should even bother take time out of my day to install it.
It's the version release notes
It's a terminal emulator built with Electron, the same tech behind the Atom and VS Code editors.
Like xterm, iTerm, Terminator, Gnome Terminal, Konsole, etc.
Like xterm, iTerm, Terminator, Gnome Terminal, Konsole, etc.
What's startup time like? Is it instant?
Why is there no "clear" command?
It's a nonsense.
Why do I want this?
I mean, I don't get how your supposed to run all these web browser based apps on a mac, when you know, the default mac has 8gb... chrome alone is taking up half that already.
My Chrome is only using 200 MB + ~100 MB per tab, depending on the page size. It's a lot, but not a constraining amount.
* The .deb package seems to install everything in /opt. This seems to be pretty common practice for electron apps and isn't a huge deal, except for the fact that a wrapper executable/link isn't installed anywhere else on the system. As a result, I had to go looking for the install directory and invoke hyper as a fully-qualified path (i.e., /opt/Hyper/hyper).
* Hyper tries to run `npm prune && npm install --production` on every startup, which (naturally) fails when the user doesn't have node (much less npm) installed globally.
* Most control modifiers don't work on Linux at all, making it impossible to work inside of programs like nano, alpine, etc.
* Throughput seems to be an issue. Running `cat /dev/zero` locked the entire application up.
These problems are understandable considering the (often unappreciated) complexity of terminals, but they're also surprising in a 1.0.0 release.