[rawfan]

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.

[kowdermeister]

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.

[imtringued]

But it's only the potential. In practice you still have to depend on the vendor to decide to support your OS.

[sdegutis]

On the other hand, it's really hard to make a closed-source app that you can sell, and still make it cross-platform.

[kowdermeister]

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.

[Jizzle]

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.

[OhSoHumble]

I'm excited because that would still be better than the terminals currently available for Windows.

[cookiecaper]

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.

[VeejayRampay]

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.

[stcredzero]

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!

[cookiecaper]

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.

[nix0n]

> 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.

[zeven7]

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?

[valarauca1]

    Where would we be if Einstein had spent all his time
    trying to improve Newton's gravity rather than
    reinventing it?

Einstein did just set out to improve Newtonian Mechanics. Special Relativity is just Newtonian Mechanics over the Lorentz Transform.

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.

[zeven7]

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.

[castis]

Which round wheels would you like to see improved?

[nix0n]

They could be working on Konsole, or iTerm, or ConEmu, or a long list of others I haven't even heard of (although the admirable goal of being cross-platform seems to align most directly with Konsole).

[meddlepal]

You know what's tiring have to over time be forced to use or maintain people's poor decision to reinvent the wheel.

[stcredzero]

Don't complain. Figure out how to charge consulting fees!

[jsjohnst]

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.

[cookiecaper]

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.

[stcredzero]

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.

[cookiecaper]

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.

[jsjohnst]

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.

[debaserab2]

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.

[stcredzero]

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.

[flukus]

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.

[stcredzero]

Does it culminate with a cryptocash exchange written in it?

[grep4master]

This made my whole day. Time for bed.

[stcredzero]

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?)