Hacker News Reader

Comment by lhnz | Hacker News Reader

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.

View on HN

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.

I don't think there needs to be a discussion and central planning over whether there 'needs to be UX innovation'.

It however does make it easier which increases the chances of useful innovation occurring naturally.

  * * *

When software moved first from the shell to the desktop and then from the shell to the browser it became less accessible and less interoperable.

Why shouldn't we be able to one day pipe Unix tools directly into our Web apps?

You can, you use APIs.

I wrote a reply to you here: https://news.ycombinator.com/item?id=12655745

You can't do what I'm suggesting already. You're thinking of sending data to backend APIs which is completely different from sending data into a visualisation function.

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

or even provide a command to let you reuse previous output, such as here:

https://raw.githubusercontent.com/sedwards2009/extraterm/mas...

More information and an implementation can be found here:

https://github.com/sedwards2009/extraterm/blob/master/docs/t...

So you can rewrite terminal output (really? I know people like rewriting history in git but in you terminal?) and emulate `echo`?

The point in these examples is that it is often very useful to be able to reuse the previous output to craft another command, or to work in a more iterative way by massaging the text and getting feedback along the way.

Isn't that what the pipe operator is for?

True, the classic shell tools like the pipe can do a lot of this. But there are important differences. Firstly, to use the pipe you need to know in advance which output you want to keep/capture when you run the command. (e.g. by redirecting into a tmp file or using a pipe directly.) In this terminal you can decide afterwards if you want to do something else with previous output.

Another difference is that this works across tabs, sessions and machines, but the classic pipe doesn't.

It makes your interactive shell a lot more interactive. Classic pipes etc still work as expected too, so you are feel to mix and match.

> "you know what my terminal needs? CSS!"

Actually, editing colors in my term... I could use some CSS there.

Reply on news.ycombinator.com