6 ms·

Maybe I'm just a crotchety old admin but I really don't "get" the recent tsunami of everything being written in JS. I mean what is the appeal of node for syste

Maybe I'm just a crotchety old admin but I really don't "get" the recent tsunami of everything being written in JS. I mean what is the appeal of node for system applications over something a bit more systems oriented? Is it just an overspill of web developers getting into systems and not knowing any other language? Does JS really offer something different languages don't?

perlgeek 10y ago
When I first read about Hyperterm, I was pretty sure I wouldn't use a terminal emulator that uses a browser. Heavy-handed and a security nightmare. But eventually I head a podcast[^1] about it, and it started to make sense. It's nearly all about hackability. If you simply compare the number of people that are comfortable with adding UI elements to a native application in GTK or QT or whatnot, to those that are comfortable with enhancing a web application, it suddenly makes sense. [1]: https://changelog.com/213/ https://changelog.com/213/ Also the design of Hyper is one where everything goes through events, which you can intercept (and possibly re-emit) in extensions, so you don't even need nasty DOM hacking or text parsing to write extensions/plugins. So now I'm still skeptical, but I also see the upsides. I guess my next step should be to actually try it :-) At least when a Linux version becomes available...
- maemilius 10y ago
  According to the GitHub page, you can build it on Linux. I haven't tried it myself, as I see no reason to abandon bash just yet.
  - perlgeek 10y ago
    You can use bash inside the terminal emulator. Hyper is just the window in which other programs such as bash, ls etc. run.
mshenfield 10y ago
It's just a different (and popular) platform for developing applications. Seems comparable to developing a terminal app with Java swing, or QT, or whatever native Mac apps are written in.
viiralvx 10y ago
I think with Electron, making desktop web apps become as easy as knowing HTML, CSS, and JS. So perhaps it's easier to style? I'm not sure, that would be my guess though.
- jrs95 10y ago
  It might not be if you were working with the native toolkit on Mac or Windows, but for a cross platform application it's probably easier than something like Qt (and is already known by many developers).
- catnaroek 10y ago
  Will it be as easy as making forms in VB (classic, not .NET) used to be in the 90's?
alexmingoia 10y ago
I think it's many things: - Recent generation of developers who entered programming through JavaScript. - Node.js being fashionable and hip. - "Not invented here" syndrome. - Open-source as a signaling mechanism for hiring and social pecking-order, which feeds the last three points.
thaumaturgy 10y ago
There has been an Eternal September in systems administration. The sysadmin niche has recently been flooded with young people coming from development backgrounds (which, today, the cutting edge is dominated by languages like JS and Go and Python), and they are approaching systems administration from a software development point of view -- attempting to abstract away the systems themselves, set up repeatable and testable environments, that sort of thing. There's a lot of it that's not bad, but as always happens in these situations, they're ignoring the advice and experience of everyone that's kept the lights blinking for several decades now, and those older folks are finding it impossible to keep up with the flood of new people. If anything kills this project one day, it'll be that it's no longer considered "okay" to connect to an individual server over ssh at all; you're supposed to use an IDE-like interface in a web browser, that connects to a service written in Node, that uses an API to download crowd-sourced pre-written web server configurations from a paid service, that then spins up a new VM using an API from another service, that then installs a daemon written in Go, that then installs the new web server configuration, and then all of your data gets migrated over to the new server and the old one gets decommissioned. If you actually ever touch a server or, gods forbid, edit your own Apache or nginx configuration files, you're a fool and an old-timer and you should retire. (Inspired by an actual comment I saw on HN not too long ago.)
- deadbunny 10y ago
  To be fair I agree with most of that (except the web IDE), abstraction can do a lot for productivity, stability, and scalability but you certainly need the hard won experience when it all goes wrong. My point was more towards the JS side of things. JS just seems like a terrible choice of language for the tasks being performed where there are so many better alternatives, sure it makes writing a desktop app as easy as a web app but it just doesn't seem suited for the purpose. To me it's like writing complex systems in bash, sure it works but it's a pretty terrible choice.
  - thaumaturgy 10y ago
    KDE (plasma), Windows, Gnome to a lesser extent, all web browsers, and now the server side all support application development in Javascript. If you're trying to write something once that, with a lot (a lot!) of effort, can run mostly anywhere, Javascript does make sense. But I agree, I wish it had been a different language.
lhnz 10y ago
1. JavaScript's ecosystem is really huge. There are lots of libraries to help you quickly get a useful product out. (The problems you will have will arrive later and will be problems caused by building a large application in JavaScript.) 2. Electron and React allow you to create desktop applications similar to how you create web applications. This make it easier to recruit engineers to work on your project. This also means you can follow modern best practices. 3. There are perceived benefits to tools that are created with web technologies in how easily they interconnect to the web. For example: - This terminal supports displaying a website within itself. - You get things like cascading style sheets for cheap, rather than needing to build your own theme system. I think it also gives a lease of life to the terminal environment. There has not been very much UX innovation there for a long while. Hyper in many ways is already much more interesting.
- deadbunny 10y ago
  Does it need any UX innovation? It's for entering text and control characters, what else does it need to do? I certainly can't think of a time I've ever said "you know what my terminal needs? CSS!" and I have a browser to render webpages. They also seem to be unclear the difference between a terminal and a shell.
  - sime2009 10y ago
    > Does it need any UX innovation? It's for entering text and control characters, what else does it need to do? It could, for example let you operate and reuse the text it just displayed: https://raw.githubusercontent.com/sedwards2009/extraterm/master/docs/edit_direct.gif https://raw.githubusercontent.com/sedwards2009/extraterm/mas... or even provide a command to let you reuse previous output, such as here: https://raw.githubusercontent.com/sedwards2009/extraterm/master/docs/from_command.gif https://raw.githubusercontent.com/sedwards2009/extraterm/mas... More information and an implementation can be found here: https://github.com/sedwards2009/extraterm/blob/master/docs/tour.md https://github.com/sedwards2009/extraterm/blob/master/docs/t...
    - deadbunny 10y ago
agumonkey 10y ago
A side effect of Programming Language orientation. Old systems requires programmers to map higher levels to the machin themselves and accept legacy the hard way. With javascript level, you can play the abstraction game which "can" make learning and prototyping way easier and unleash ideas.
ilaksh 10y ago
You may have noticed this phenomenon of 'browser bloat'. Well, its gone way beyond bloat. Basically the idea of adding features to web browsers started snowballing years ago and then turned into a new animal. That new animal is the web platform. The leading browsers now basically contain features that cover just about every single API a programmer could want. That even includes recently added experimental support for accessing USB devices. So its an operating system that lives inside other operating systems. The appeal of Hyper for me, as a JavaScript programmer who has been working with Linux for at least 15 years and likes the terminal -- (I do everything in zsh or fish shell, use vim to program, was playing TradeWars 2002 on telnet last night) is that now I can keep all of my cool ANSI and linux command-line workflow etc. PLUS I can add just about any fricking thing I can think of into my terminal. From sound to SVG to 3d graphics. Or just testing my JavaScript application or component. But really it comes down to whether your belief system allows for the possibility of a terminal to have any feature that isn't in a classic terminal -- i.e. anything that isn't monospaced colorful text. Also, if you don't like JavaScript, and ever consider expanding the capabilities of your terminal or integrating some other application somehow, there are tons of languages that can compile to JavaScript and therefore plug in to Hyper.app, including C or many languages that compile to C via emscripten, LiveScript, Haxe, TypeScript, Dart, Elm, RubyJS, Pyjs (Python), Nim, Shen (Erlang), Perlito (Perl), GWT (Java), Scala.js (Scala), Script# (C#), ClojureScript, Moby Scheme, OCamljs (OCaml), ghcjs (Haskell), Go2js (Go), jsForth (Forth), etc.

perlgeek 10y ago

When I first read about Hyperterm, I was pretty sure I wouldn't use a terminal emulator that uses a browser. Heavy-handed and a security nightmare. But eventually I head a podcast[^1] about it, and it started to make sense. It's nearly all about hackability. If you simply compare the number of people that are comfortable with adding UI elements to a native application in GTK or QT or whatnot, to those that are comfortable with enhancing a web application, it suddenly makes sense. [1]: https://changelog.com/213/ https://changelog.com/213/ Also the design of Hyper is one where everything goes through events, which you can intercept (and possibly re-emit) in extensions, so you don't even need nasty DOM hacking or text parsing to write extensions/plugins. So now I'm still skeptical, but I also see the upsides. I guess my next step should be to actually try it :-) At least when a Linux version becomes available...

maemilius 10y ago
According to the GitHub page, you can build it on Linux. I haven't tried it myself, as I see no reason to abandon bash just yet.
- perlgeek 10y ago
  You can use bash inside the terminal emulator. Hyper is just the window in which other programs such as bash, ls etc. run.

mshenfield 10y ago

It's just a different (and popular) platform for developing applications. Seems comparable to developing a terminal app with Java swing, or QT, or whatever native Mac apps are written in.

viiralvx 10y ago

I think with Electron, making desktop web apps become as easy as knowing HTML, CSS, and JS. So perhaps it's easier to style? I'm not sure, that would be my guess though.

jrs95 10y ago
It might not be if you were working with the native toolkit on Mac or Windows, but for a cross platform application it's probably easier than something like Qt (and is already known by many developers).
catnaroek 10y ago
Will it be as easy as making forms in VB (classic, not .NET) used to be in the 90's?

alexmingoia 10y ago

I think it's many things: - Recent generation of developers who entered programming through JavaScript. - Node.js being fashionable and hip. - "Not invented here" syndrome. - Open-source as a signaling mechanism for hiring and social pecking-order, which feeds the last three points.

thaumaturgy 10y ago

There has been an Eternal September in systems administration. The sysadmin niche has recently been flooded with young people coming from development backgrounds (which, today, the cutting edge is dominated by languages like JS and Go and Python), and they are approaching systems administration from a software development point of view -- attempting to abstract away the systems themselves, set up repeatable and testable environments, that sort of thing. There's a lot of it that's not bad, but as always happens in these situations, they're ignoring the advice and experience of everyone that's kept the lights blinking for several decades now, and those older folks are finding it impossible to keep up with the flood of new people. If anything kills this project one day, it'll be that it's no longer considered "okay" to connect to an individual server over ssh at all; you're supposed to use an IDE-like interface in a web browser, that connects to a service written in Node, that uses an API to download crowd-sourced pre-written web server configurations from a paid service, that then spins up a new VM using an API from another service, that then installs a daemon written in Go, that then installs the new web server configuration, and then all of your data gets migrated over to the new server and the old one gets decommissioned. If you actually ever touch a server or, gods forbid, edit your own Apache or nginx configuration files, you're a fool and an old-timer and you should retire. (Inspired by an actual comment I saw on HN not too long ago.)

deadbunny 10y ago
To be fair I agree with most of that (except the web IDE), abstraction can do a lot for productivity, stability, and scalability but you certainly need the hard won experience when it all goes wrong. My point was more towards the JS side of things. JS just seems like a terrible choice of language for the tasks being performed where there are so many better alternatives, sure it makes writing a desktop app as easy as a web app but it just doesn't seem suited for the purpose. To me it's like writing complex systems in bash, sure it works but it's a pretty terrible choice.
- thaumaturgy 10y ago
  KDE (plasma), Windows, Gnome to a lesser extent, all web browsers, and now the server side all support application development in Javascript. If you're trying to write something once that, with a lot (a lot!) of effort, can run mostly anywhere, Javascript does make sense. But I agree, I wish it had been a different language.

lhnz 10y ago

1. JavaScript's ecosystem is really huge. There are lots of libraries to help you quickly get a useful product out. (The problems you will have will arrive later and will be problems caused by building a large application in JavaScript.) 2. Electron and React allow you to create desktop applications similar to how you create web applications. This make it easier to recruit engineers to work on your project. This also means you can follow modern best practices. 3. There are perceived benefits to tools that are created with web technologies in how easily they interconnect to the web. For example: - This terminal supports displaying a website within itself. - You get things like cascading style sheets for cheap, rather than needing to build your own theme system. I think it also gives a lease of life to the terminal environment. There has not been very much UX innovation there for a long while. Hyper in many ways is already much more interesting.

deadbunny 10y ago
Does it need any UX innovation? It's for entering text and control characters, what else does it need to do? I certainly can't think of a time I've ever said "you know what my terminal needs? CSS!" and I have a browser to render webpages. They also seem to be unclear the difference between a terminal and a shell.
- sime2009 10y ago
  > Does it need any UX innovation? It's for entering text and control characters, what else does it need to do? It could, for example let you operate and reuse the text it just displayed: https://raw.githubusercontent.com/sedwards2009/extraterm/master/docs/edit_direct.gif https://raw.githubusercontent.com/sedwards2009/extraterm/mas... or even provide a command to let you reuse previous output, such as here: https://raw.githubusercontent.com/sedwards2009/extraterm/master/docs/from_command.gif https://raw.githubusercontent.com/sedwards2009/extraterm/mas... More information and an implementation can be found here: https://github.com/sedwards2009/extraterm/blob/master/docs/tour.md https://github.com/sedwards2009/extraterm/blob/master/docs/t...
  - deadbunny 10y ago

agumonkey 10y ago

A side effect of Programming Language orientation. Old systems requires programmers to map higher levels to the machin themselves and accept legacy the hard way. With javascript level, you can play the abstraction game which "can" make learning and prototyping way easier and unleash ideas.

ilaksh 10y ago

You may have noticed this phenomenon of 'browser bloat'. Well, its gone way beyond bloat. Basically the idea of adding features to web browsers started snowballing years ago and then turned into a new animal. That new animal is the web platform. The leading browsers now basically contain features that cover just about every single API a programmer could want. That even includes recently added experimental support for accessing USB devices. So its an operating system that lives inside other operating systems. The appeal of Hyper for me, as a JavaScript programmer who has been working with Linux for at least 15 years and likes the terminal -- (I do everything in zsh or fish shell, use vim to program, was playing TradeWars 2002 on telnet last night) is that now I can keep all of my cool ANSI and linux command-line workflow etc. PLUS I can add just about any fricking thing I can think of into my terminal. From sound to SVG to 3d graphics. Or just testing my JavaScript application or component. But really it comes down to whether your belief system allows for the possibility of a terminal to have any feature that isn't in a classic terminal -- i.e. anything that isn't monospaced colorful text. Also, if you don't like JavaScript, and ever consider expanding the capabilities of your terminal or integrating some other application somehow, there are tons of languages that can compile to JavaScript and therefore plug in to Hyper.app, including C or many languages that compile to C via emscripten, LiveScript, Haxe, TypeScript, Dart, Elm, RubyJS, Pyjs (Python), Nim, Shen (Erlang), Perlito (Perl), GWT (Java), Scala.js (Scala), Script# (C#), ClojureScript, Moby Scheme, OCamljs (OCaml), ghcjs (Haskell), Go2js (Go), jsForth (Forth), etc.