Live data from Hacker News

Hyper 2, Electron based terminal

zeit.co

161–170 of 231 posts

Re: Hyper 2, Electron based terminal

#161

My gripe was always having a terminal not blend in with the editor which makes this nice but vscode essentially does that out of the box for me. Now if I ever need the terminal and I'm not looking to code anything, I just use the native terminal. I can see why some people might like this if they are using sublime, atom, etc other editors that don't have terminal included but that was the only void this somewhat filed…

It's useful to note that Hyper 2 is sharing the core terminal emulator (xterm.js) with VSCode now, so future improvements should continue to benefit both. Also, if you need a terminal outside of VSCode from time to time, Hyper might be a familiar option in that case.

Re: Hyper 2, Electron based terminal

#162
post #141

On my Mac I still prefer iTerm, but I really like using Hyper on my Windows box.

Really looking forward to trying this out on my Windows box at home. About twice a year I look for good terminal programs for it and it seems nearly impossible. To this day I just have a bunch of Git Bash windows running...

Re: Hyper 2, Electron based terminal

#163
post #17

I had high hopes for this project. Particularly considering the fact default terminal in Windows is a total crap and it seems Microsoft is not interested at all to fix the problems (yeah, I know, they are saying they are working on it but they haven’t delivered in 3 years, how hard it is to add unlimited scroll bar option? Or hide scroll bar?. I wish I could’ve run gnome-terminal in Windows.) Back to hyper. Hyper dis…

> they are saying they are working on it but they haven’t delivered in 3 years

The CommandLine blog is a fascinating read of Microsoft's progress over the last three years:

https://blogs.msdn.microsoft.com/commandline/

They've delivered a lot (much of it WSL-driven now that Linux apps run inside it more often), even if they haven't added your particular wishlist items.

For revamping a part of Windows that had almost died on the vine, they seem to be doing a fascinating job, over the last few years, even within Windows' strong mandate to maintain backward compatibility at all costs.

Re: Hyper 2, Electron based terminal

#164

Earlier quoted context omitted.

But why would I want to use Node JS?

* 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 don't have that problem with other tools, so I don't think I'm unable to read and follow instructions. I'm disappointed, because there are a couple of toolkits for mobile development that I'd love to use, and there's a big Node roadblock in my way.

Re: Hyper 2, Electron based terminal

#165

Earlier quoted context omitted.

I just went through a simple exercise; for my tests, a minimal JavaFX app starts at ~100MB while a minimal Electron app starts around ~65MB.

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.

Re: Hyper 2, Electron based terminal

#166

Earlier quoted context omitted.

> Then learn a new language? Learn a new language (Python/C++/other) in order to learn and use a different framework (Qt)? Thanks for your advice I'll down tools right now and get on with that using my time the way I want to. (Actually I've never developed anything using Electron yet, though some personal projects may get implemented that way in future should they ever get off the ground) I fully understand much of t…

Isn’t it just as entitled to refuse learning something because you will only use the language you want? Even if it’s forcing a square peg in a round hole? Cmon tho, any competent engineer can switch between languages without many issues.

> Isn’t it just as entitled to refuse learning something because you will only use the language you want?

Not really IMO. If users don't like it, they can usually use something else.

A point I didn't make clear at all is "you have used Electron, eww" is a poor judgement. "It is too slow for my needs, look at this benchmark" or "it takes too much RAM, look at the problem this causes" or "it takes a while to load, look at this metric that shows the effect it has on me" are all valid and constructive criticisms. "I don't like part of what, to me as a user should be a black box, is made with" isn't (if it works for you, it works, if it doesn't for a practical reason then it doesn't, how it is made and how the maintainers might solve your issue if they chose to address it is their problem). If going from a fellow developers PoV then by all means give constructive critique but "you use Electron, you a stupid" (a tone I've seen a fair few times) isn't that, and as a developer if you want an X made a different way go make an X that way (or, back to user-land, go find one made that way, there will probably be other options).

> Even if it’s forcing a square peg in a round hole?

This can be a problem created by switching language (or framework, or other) without sufficient acclimation time: you end up using the new tools like they were your old tools, which might produce something that works badly because the new options are not optimal for that construction pattern or at least that pattern does not use the other tools to their best advantage. Have you never heard the pained yelps of "but... that just isn't Pythonic!" or similar?

> Cmon tho, any competent engineer can switch between languages without many issues.

Depending on experience level, that is rarely without at least some context switching cost even if you are already familiar with what you are switching to. Maybe you are a natural star engineer for whom this is as close to zero as makes no odds, but most of use are not quite that perfect!

Re: Hyper 2, Electron based terminal

#167

Earlier quoted context omitted.

What about good ol' QT?

Both QT and GTK have more restrictive licensing, which is fair on its own, but when comparing to Electron you have to consider it a disadvantage.

Qt is licenseable under LGPLv3, Electron under the MIT license. There is practically little difference between the two types of licenses.

Re: Hyper 2, Electron based terminal

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

you mean....like emacs?

Re: Hyper 2, Electron based terminal

#169
Oh, great, people are still latched onto the Electron hype.

We now have another 150MB/window application. Great. How about pushing the envelope further and using a Quake engine as the base (it has a console).

Re: Hyper 2, Electron based terminal

#170
post #80
post #63

Earlier quoted context omitted.

I've been using VSCode for years and it's been great, but I'm always looking for learning something new. I keep reading about Vim and last time I checked it seems SO complicated to use. I don't understand how it's so popular. Is it because it's blazing fast?

You can use vim keybindings in VSCode. It mostly works, except for more advanced stuff. Correct indentation when pasting is a pain in my opinion. And somehow I find the VSCode's multi-cursor feature so much more convenient than Vim's macros.

gg=G

couldn't be easier my friend

Post reply on HN