Live data from Hacker News

Hyper 2, Electron based terminal

zeit.co

171–180 of 231 posts

Re: Hyper 2, Electron based terminal

#171
post #168

Earlier quoted context omitted.

Agreed (though I use Kakoune). With that said, first class integration around a shell could definitely make me change editors. As much as I like terminal editors, it's a very limited medium to write an editor. I imagine a Vim/Kakoune/Emacs/etc could be written in a GUI and have even more features yet still retain first class focus on keyboard UX.

you mean....like emacs?

I'm confused, isn't emacs in the shell? Are you saying that emacs is a gui editor?

I was talking about GUI editors. I already use a term editor. I even game an example of vim/kakoune/emacs, ie, term editors.

Re: Hyper 2, Electron based terminal

#172

Earlier quoted context omitted.

This is only the case if you bundle the JVM with your application. Without the JVM you can write a simple application without exceeding the .jar file size of 1 MB.

I should have been more explicit; this is the default in memory footprint of a simple hello world app. I didn't really try to reduce the heap or stack of the JVM, I'm sure that would help.

Oh I think this is a misunderstanding. I thought you were talking about the binary file size which is very big for electron apps since they ship a full-blown browser. It is possible that JavaFX apps also use a lot of memory (RAM) but I was referring to the file size of the .jar file of a JavaFX app.

Re: Hyper 2, Electron based terminal

#173
post #137

Earlier quoted context omitted.

I solve this problem by using vim, so my terminal is my editor.

Agreed (though I use Kakoune). With that said, first class integration around a shell could definitely make me change editors. As much as I like terminal editors, it's a very limited medium to write an editor. I imagine a Vim/Kakoune/Emacs/etc could be written in a GUI and have even more features yet still retain first class focus on keyboard UX.

Check out Oni: https://github.com/onivim/oni It's under heavy development, wouldn't recommend it at the moment but it looks promising.

Re: Hyper 2, Electron based terminal

#174
post #155
post #138

Earlier quoted context omitted.

A physical "terminal" is a piece of hardware: https://en.wikipedia.org/wiki/VT100

I think people also refer to a "terminal" as one of the virtual terminals (CTRL+ALT+F[1-9]) that Linux provides. But yeah, people use the term to mean different things.

These “virtual” terminals of course are also emulations of the original hardware terminals.

Re: Hyper 2, Electron based terminal

#175
post #46

I just can't stand Electron based applications at all. I can't stand JavaScript actually, but that's something different entirely. I'm really looking forward to learning Flutter ( https://flutter.io ) so I can finally do some mobile based application development in a cross platform manner without having to use JavaScript. Prior to Flutter I was considering Swift and Kotlin and just maintaining two code bases (and two…

Using JavaScript to implement a terminal emulator makes sense if you take advantage of html/css. If it's just to implement a conventional terminal emulator, it may be difficult to justify the perforance/memory costs. But html/css does enable a lot of neat features, such as embedded graphics, css styling, etc. I think for DomTerm the features justify the costs: https://opensource.com/article/18/1/introduction-domterm-ter...

Re: Hyper 2, Electron based terminal

#176
post #146

Earlier quoted context omitted.

I like to Keep it simple - and it's very painfull to do that in C++. Yes, you can write simple code, but it's lot easier to do it in other languages.

Modern C++ is not simple, but modern JavaScript is?

Before you use modern c++ you have to learn all the "old" features to really understand what you're doing. Also I didn't say a thing about JavaScript.

Re: Hyper 2, Electron based terminal

#177

Earlier quoted context omitted.

No they don't. JS running on a modern engine like V8 are easily 10x faster than CPython which PyQt uses. If you think Python and JS are about the same speed then it is because of Qt itself, but certainly not because of CPython.

I have coded with both, and practically, yes, they are. The only place where JS would beat Python would be a big loop with number crunching, which you would do with numpy anyway. Or pypy, which is 50 times faster than V8. A desktop app would not see any difference. A sysadmin script neihter. Data analystics is made using numpy/scipy/pandas. Web sites bottleneck are incredibly rarely the server side scripting language…

I like neither python nor JS, by my experience is more like the parents. Once you step outside of the highly optimized C that much of the standard python is written in, it is not a very fast language.

V8 has been running many many laps around cpython for the use cases I have been using it for, and PyPy has generally been slightly slower.

Re: Hyper 2, Electron based terminal

#178

Earlier quoted context omitted.

* runs on a fast JIT * package management and modules actually work * huge ecosystem of packages * ability to use native code modules in needed * has webassembly too * runs a huge range of other languages. It can fill a role similar to the JVM and .Net runtimes in this respect.

Okay, I'm going to jump on the "package management and modules actually work" thing; I'm not a noder, but I've considered using several tools that are built on Node, and every time — almost literally — `npm install whatever` fails. Linux, Windows, doesn't matter: I see the latest cool thing on Node, try to install it, and think, "If they can't even get installation to work, why should I bother?" Am I alone in this? I…

If you have a C++ compiler that works, you should be fine. I've never had an issue installing a package that isn't, in fact, a C++ issue.

Meanwhile, Python versioning of plugins is really broken, unless you use virtual environments. Maven seems to be fairly hard to integrate with IDEs (Eclipse seems to come bundled with a separate one, not sure about IntelliJ). Most other package managers I use don't have enough packages to be as useful.

Re: Hyper 2, Electron based terminal

#179
I used Hyper for a little while a few months ago and thought it was okay. Still prefer iTerm for daily use.

One thing that it’s amazing at, though, is taking promotional screenshots. It hides the OS bar by default, plus looks just generally great.

For instance: https://github.com/snapcrafters/fkill

Re: Hyper 2, Electron based terminal

#180
Some comments comparing DomTerm (http://domterm.org/) and Hyper2 (H2):

DT does not require Electron: There are also embeddings for Qt (using QtWebEngine), Atom, Theia - or you can use a desktop browser. If you use Electron, it is only used for the "chrome" (menus etc). The "backend" (server) is a C program. (It works great on Windows using WSL.) There is also a simplified pure-Java backend.

Hyper2 is clearly faster. Using canvas seems like a win in that respect, but I'm concerned this limits the ability to style the output using CSS. Using a more structured representation (e.g. DOM) also preserves valuable information about the output. The ideal might be to have a structured representation as "the truth" but render to a canvas. This might still be less flexible in terms of using CSS, but that might be an ok tradeoff.

Om H2, if you change the window width, wrapped lines are not re-calculated.

H2 does not "remember" tabs. I.e if you 'cat Makefile', and copy the output, you get spaces, not tabs.

H2 shows a lot more errors when running the vttest test suite.

DT supports hyper-links to file positions. For example clicking on FILENAME:LINE:COLUMN: (as produced by many compilers) will open a (customizable) editor and go to that position.

DT supports "printing" images, rich text, and general HTML.

DT supports tabs, draggable panes, detachable sessions (like tmux/screen), and a builtin input editor.

Post reply on HN