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.
Hyper 1.0.0
171–180 of 214 posts
Re: Hyper 1.0.0
#172I'm skeptical of the value of electron-ified applications when fully native alternatives suffice. However, ignoring that, there are a few (pretty severe) problems with this release: * 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…
> 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 whe…
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.
Re: Hyper 1.0.0
#173Funny 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.
Re: Hyper 1.0.0
#174Earlier quoted context omitted.
It's a shell (think iTerm2 like) built using Electron (aka web technologies in a native wrapper).
It's not a shell, it's a terminal emulator. A shell is the program that handles the words you type into your terminal emulator.
Mea culpa. Obviously knew that, just said the wrong thing. Thanks!
Re: Hyper 1.0.0
#175Earlier quoted context omitted.
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.
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.
Re: Hyper 1.0.0
#176Earlier quoted context omitted.
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.
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 pr…
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.
Re: Hyper 1.0.0
#177Earlier quoted context omitted.
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,…
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.
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.
Re: Hyper 1.0.0
#178I'm skeptical of the value of electron-ified applications when fully native alternatives suffice. However, ignoring that, there are a few (pretty severe) problems with this release: * 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…
> 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.
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.
Re: Hyper 1.0.0
#179I'm skeptical of the value of electron-ified applications when fully native alternatives suffice. However, ignoring that, there are a few (pretty severe) problems with this release: * 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…
> 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 whe…
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.
Re: Hyper 1.0.0
#180Erm... 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.
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 me…
> 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.