Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hyper 2, Electron based terminal

zeit.co

Post reply on HN
Print view View original

191–200 of 231 posts

Re: Hyper 2, Electron based terminal

#191

Post by agumonkey »

pantulis wrote: post #156
agumonkey wrote: post #93

Earlier quoted context omitted.

yeah, I was. I understand the appeal of having html/css hyperdynamism everywhere. And at the same time I don't want to pay the price to the point that I prefer living in lotech linux land. I value frugal over potential flexibility these days. I told that often, but the other day I booted win9x (on a pentium 3 or less, some MB of ram, maybe 64) and ran an old copy of turbo pascal 7 (dos). That thing was flying. It had…

Oh, Turbo Pascal had those Turbovision-powered ASCII shadowed floating editing windows in 1993 or so, and it flied on a 386 CPU... the P3 would be a screamer for that ;)

Thanks for that input, I was very curious to know about performance on much older hardware. This makes TP's worht even higher. 600kB total .. can you believe that ?

Re: Hyper 2, Electron based terminal

#192

Post by s73v3r_ »

WorldMaker wrote: post #160
s73v3r_ wrote: post #143

Earlier quoted context omitted.

"Second, the benefits of using electron are enormous for any JS developer and there are a lot." Disagree. I'd argue using Electron actually holds back developers, because they don't learn languages other than JS.

Except that's not strictly true? First of all, JS isn't a bad language. It's also a lot different in 2018 than at its worst in 1998. It's becoming so common because it is a pragmatic choice that is fine to work in in 2018. Secondly, there is the giant ecosystem of transpile to JS languages: Typescript, CoffeeScript, PureScript, Elm, Haxe, Fable, etc. If that doesn't count, Electron's duct tape itself and many Node pa…

It is true. The entire point of things like Electron is so you don't have to learn another language, continuing to use JS skills, and not branching out into other things. Electron itself may be in C++, but I'd wager that very few of those using Electron as a GUI toolkit are diving that deep.

Re: Hyper 2, Electron based terminal

#193

Post by notheguyouthink »

Siilwyn wrote: post #173
notheguyouthink wrote: post #140

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.

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

Wow that is amazing looking!

Makes me want to make something like that for Kakoune! Wonder if Oni will ever get to the state where you could write different backends for it; ie emacs, kakoune, etc.

Re: Hyper 2, Electron based terminal

#194

Post by matzy »

notheguyouthink wrote: post #171
matzy wrote: post #168

Earlier quoted context omitted.

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.

Emacs is a gui editor. It has a shell mode, but it's primarily supposed to be used through the GUI. GUI Emacs is literally everything you described looking for above - an advanced GUI with more features than you could evere learn, yet one that still retains first class focus on keyboard UX.

Re: Hyper 2, Electron based terminal

#195

Post by movedx »

hungerstrike wrote: post #112
fbnlsr wrote: 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?

Vim isn't that popular with coders. Visual Studio and Notepad++ are the most popular across the board while Vim is preferred by Sysadmins according to this Stackoverflow survey from 2017 - https://insights.stackoverflow.com/survey/2017#technology-mo... Notice how those numbers don't add up to 100%. They let you pick multiple answers on the survey. Therefore, I would consider Vim percentage even lower in reality since…

> Vim is used by a small but very loud minority. Don't listen to them - they're optimizing for the wrong thing (keeping your fingers on the home-row of the keyboard) at the expense of just about every other aspect of computing.

It would be good if you could unpack this some more and explain it in detail. If I'm wasting my time then I'd like to know why and consider whether or not I should change my practices.

The part of your statement that stands out to me is, "keeping your fingers on the home-row of the keyboard". I think this is called touch typing and I can assure you, I don't do it. I'm fast on the keyboard, but not as fast as a touch typist. I throw my fingers all over the place, actually.

Vim for me simply boils down to being a fast, simple, lightweight tool that offers years upon years of development in both the core of the product and plugins, themes, etc.

I'm not really sure how my choice of hammer can be optimising for the wrong thing if it does the same thing your hammer does and we're both productive?

Re: Hyper 2, Electron based terminal

#198

Post by seba_dos1 »

smolsky wrote: post #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).

Wouldn't a Quake engine based terminal emulator actually be way lighter? :P

Re: Hyper 2, Electron based terminal

#199

Post by movedx »

Sean1708 wrote: post #145
movedx wrote: post #51

Earlier quoted context omitted.

Good read. Thanks. And I agree: Electron is horrible to deal with as an end-user. I've been using Vim for some time and then decided to use VS Code. The integrations, plugins, and everything else were awesome, but man the 3-4GB of RAM was just crazy. Despite the fact my machine has 16GB of RAM, I'm dealing with quite a few VMs and Docker containers locally, so actually 16GB isn't a lot.

> but man the 3-4GB of RAM was just crazy What kind of files do you usually work with? Because I've currently got two 10000+ line python files open which are part of a project that is at least a million lines of code, and my VSCode instance is using less than 300 MB of RAM.

I've got three Go files open and looking at all the processes related to "Visual Studio Code.app", I see a residential memory footprint of 660MB. I'm using the latest version.

That also coincides with:

https://medium.com/@caspervonb/why-i-still-use-vim-67afd76b4...

And

https://github.com/jhallen/joes-sandbox/tree/master/editor-p...

Re: Hyper 2, Electron based terminal

#200

Post by WorldMaker »

s73v3r_ wrote: post #192
WorldMaker wrote: post #160

Earlier quoted context omitted.

Except that's not strictly true? First of all, JS isn't a bad language. It's also a lot different in 2018 than at its worst in 1998. It's becoming so common because it is a pragmatic choice that is fine to work in in 2018. Secondly, there is the giant ecosystem of transpile to JS languages: Typescript, CoffeeScript, PureScript, Elm, Haxe, Fable, etc. If that doesn't count, Electron's duct tape itself and many Node pa…

It is true. The entire point of things like Electron is so you don't have to learn another language, continuing to use JS skills, and not branching out into other things. Electron itself may be in C++, but I'd wager that very few of those using Electron as a GUI toolkit are diving that deep.

You seem to have a lot of interesting base assumptions in your assertion.

Is "continuing to use JS skills" a bad thing? What makes "branching out into other things" a better thing? We will likely continue to disagree that JS is a bad language. While I agree that learning a gamut of languages is a good idea for any developer (and will heavily encourage devs to challenge themselves to try to learn different languages with different paradigms to keep from growing "stale", to keep up lifetime learning), it's not positive or negative value for a platform like Electron if it "requires" learning a new language to use it. Do you maybe think people are more likely to learn JS as a first language? That too is an interesting assumption.

Beyond those value opinions, existing JS skills may not be the only reason to use Electron. Existing HTML/CSS skills may be the more important reason for some developers. Cross-platform GUI toolkits haven't kept up with HTML/CSS in a lot of areas including ease of testing and availability of designers with design skills. Use of JS may be entirely orthogonal to that decision.

(Certainly in my own usages of Electron, that has been the larger factor. Xamarin seems like the next best bet, but it's still a lot easier for very small teams with no platform-specific UI designers on hand to audition design work in a handful of browsers than to bounce back and forth between a variety of iOS and Android emulators and devices.)

Whether or not that it is "very few" people using Electron today that don't also want to directly use JS is a demographic question that you also seem to conflict with some sort of value judgment. Even if "very few" people are using anything more than "just JS", that doesn't mean it is valueless that people have an option to leverage Electron with other languages.

Even if demograghics did matter, I already pointed to a case where Rust-sourced code is shipping in major Electron apps (I know VSCode has dependency, I believe Atom has a dependency). VSCode is written entirely in Typescript, and I don't think it's the only major Electron project doing so (and if we start to play the dependencies game, a lot of Open Source in the Node world is Typescript). Even Atom seems mostly "vanilla" JS, but still has ~7% of its source in CofeeScript, and its "vanilla" JS has a lot of ES2015+-isms that would look unrecognizable to older versions of JS, and I've heard it argued that ES2015+ starts to be a different language than what a lot of people that have not followed JS in the last few years imagine when they discuss JS.

Post reply on HN