Hyper 2, Electron based terminal | Hacker News Reader

Hyper 2, Electron based terminal

zeit.co

106 pointskiyanwang226 comments

Wow so much hate in this thread.

First, the author is not doing this for his CV.

Second, the benefits of using electron are enormous for any JS developer and there are a lot.

Third, I also hate electron apps and wouldn’t use this app, but I’m not going to jump back to “why electron is bad” discussion, since I can’t suggest anything better in 2018.

What about good ol' QT?

Last time I checked the bindings of QT[1] for NodeJS were not updated since 6 years.

I think they are still unmaintained and also are lacking the community around it. I think GitHub embracing Chrome-wrapped-apps was a significant move, since no other company did something similar for desktop javascript applications.

Maybe we will need to wait a bit more, until some of the big tech companies realises that having better QT / GTK bindings and build tools, examples, proper documentation will benefit a lot the company and the community around it. Until then, we are stuck.

[1] : https://github.com/arturadib/node-qt

But why would I want to use Node JS?

The obvious answer to that is "because you are familiar and comfortable with JS and don't want to (or ATM don't have time to) learn the ins-and-outs of another language and its ecosystem."

That seems to be one of the main drivers behind Electron's popularity, others being easier cross-platform support (or at least the perception of that) and the vote of confidence in its stability from the likes of MS using it in their products (primarily VSCode in MS's case).

What would be your alternate suggestion, and why? (genuine question rather than a rhetorical dig: I plan to tinker with Electron for a couple of projects soon so if there is something better (or simply that is a suitable alternative to consider) out there I'm not aware of, I'd like to be made aware)

* 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.

> * package management and modules actually work

> * huge ecosystem of packages

This is satire, right?

NPM (both the tool, and the repository of packages it pulls from) are a joke to anyone outside the NodeJS bubble of Stockholm syndrome.

A company that was given $8M in venture capital and can't find more than two people to work on the main way people interact with their service, cannot be taken seriously.

Remember when everyone found out that the progress bar made NPM install packages 3x slower?

Then lets get into the actual 'ecosystem'.

The community actively encourages and embraces the sort of culture and decision making that leads to an entire module to do what you can do with this: `$foo % 2 === 0` (i.e. 'is even')

You would type more characters just requiring the module than you would just using the modulo operator.

Then you find out the same author published another module that literally just calls the other one and negates the returned result.

Let that sink in: a module, to do nothing more than prefix a function call with a `!`.

No fucking surprise the 'ecosystem' is huge. What other people call "writing code" NPM module developers look at as another opportunity to bump their ridiculous package count e-penis.

You can use NPM and NodeJS if you want, you can even "like" them. But don't for a second think that the community and practices of that environment are "good" by any comparison.

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.

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.

> Python versioning of plugins is really broken

It is not broken - you ARE supposed to use virtual environments. I would say its is much saner than nodejs ecosystem where every conflict is being solved by having multiple versions of overlapping dependencies.

"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."

I've also had a compilation problem on Windows caused by Python not being installed (IIRC, the SASS package needed gyp, which uses Python). That was exceptional: I expect npm packages to install without issue, although I'm still bothered by how many dependent packages every tool seems to need.

> Most other package managers I use don't have enough packages to be as useful.

Let me guess, no `iseven` package?

Then learn a new language? It shouldn’t be that hard to transition between languages for UI stacks

> 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 the criticism of Electron and similar: the results are rather bulky in terms of both package size and memory use (and if you aren't careful sometimes CPU use) which can add up to quite a performance hit if running a number of small apps/tools that are large because of the framework. For interactive (or script-called) non-resident utilities startup time can be a significant issue too.

But there are a lot of entitled people out there who seem to be of a mind that because they don't like Electron (for those reasons or whatever else) they have the right to demand that developers stop using it. If you don't want to use an Electron driven application then the solution is to not use that Electron driven application. There are no doubt alternatives out there. If not then the deep knowledge you have that makes you an expert on why it would be better developed other ways should allow you to write your own and compete.

This is true for both paid-for services like this (show them who is boss by collectively voting with your wallets) and free and/or open source options (in which case making demands of the creator/maintainer seems even more egregious IMO).

</rant>

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.

The basics of switching to a language in the same/similar paradigm isn't that hard. Re-learning tooling, libraries, etc takes a very long time. I can rattle off reams of stuff in the languages I know, but I'd have to spend hours searching for that same stuff in other languages.

Thats very true. The tooling and dependency part about switching sucks for sure.

> 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!

Pretty sure no one thinks 'js' when they think about slim desktop apps

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.

The problem is that your language choice is very limited. You can choose C++, no thanks, or Python which is very slow. There are no good options for languages or VMs on Qt in the Java/C#/VM/Jit range of the language performance spectrum.

> Python which is very slow

well it might in relative terms, but a pyqt app is almost certainly going to be an order of magnitude faster than electron.

Python and js apps have the same order of magnitude of speed.

But pyqt apps are way faster than electron

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.

> JS running on a modern engine like V8 are easily 10x faster than CPython which PyQt uses.

Citation needed. As I've said numerous times before, saying one language is faster than another is pointless. You have to give a full context around it. What particular scenario is CPython slower than V8?

While it's true that a pure CPython tight loop will be slower than one in V8, I have a hard time imagining that being the bottleneck of desktop applications.

> As I've said numerous times before, saying one language is faster than another is pointless.

Never thought about it this way but you're right. I could very well write an interpreter for C that's slow as molasses and I'd be willing to be that no one will try it and say "C is slow."

It doesn't seem like languages that are already interpreted get that courtesy, though. V8 isn't the only JS engine, after all.

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, and when it is, you go rust/go.

But for our current debate, electron VS PyQT, well yes, the C++ does the heavy lifting and you get to use Python only for the stuff it is good at. Win-win.

The problem with using PyQT is making an exe or making fancy graphics is harder than in electron.

Everything else, and I do mean everything else, is easier and more performant with PyQT.

> pypy, which is 50 times faster than V8.

Ehhh V8 is pretty competitive with C for number crunching. Where are you getting that 50 times figure from?

threads.

http://doc.pypy.org/en/latest/faq.html#does-pypy-have-a-gil-...

If you're using parallelism for non-IO-related reasons, then in either language, you'll probably end up using multiple processes rather than multiple threads.

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.

You can't say that "a desktop app/sysadmin script/website/etc would not see any difference" without knowing what the app was doing. An app like VSCode has a ton of shit to do.

However, the real problem with PyQT is that Python is relatively garbage compared to JS and that's why it's not nearly as popular as JS.

A project I'm working on: https://github.com/pauldotknopf/net-core-qml

This will allow you to fully interoperate Qml and .NET (Mono/.NET Core/Full Framework).

Thanks for working on that. I've been trying to use Avalonia and it already drives me slightly insane.

I haven’t tried it, but isn’t JavaFX supposed to be the future of JVM based GUI’s? I’m actually very curious about others experiences with it.

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.

Not sure how you built your minimal example, but current versions of Java will allow you to produce much smaller native bundles using jlink. Steve Perkins did a nice little writeup with an example repo at https://github.com/steve-perkins/jlink-demo.

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.

If you just count the JS and HTML, then a minimal Electron app is (hopefully) also tiny.

That's not the same though. You have to bundle electron to run your app. Your Java app is fine as long as Java is installed.

Yes, but theoretically Electron apps could use the browser. (I think Google killed that option though.)

Yeah, it would be nice if the API's were standardized and then every browser had an "App Mode".

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.

So? If you want a lightweight app, both JavaFX and Electron are bad.

There are no good options for languages or VMs on Qt in the Java/C#/VM/Jit range of the language performance spectrum.

Qt had pretty good Java support with Qt Jambi. But nobody cared and they cancelled the product.

https://en.wikipedia.org/wiki/Qt_Jambi

alas, there have been many attempts over the years for language bindings even to interesting targets like the JVM and mono/.Net, but none of them really gained "escape velocity", except for PyQt (which is great might I add).

I'd have to use bad old C++ with it, so how about no.

No you can use python, and get a fast app and a high level language with huge ecosystem, a rich stdlib and a large set of material to get going.

Come on, what is bad and old on c++? :)

Not sure it is a good idea to use a language that is not memory safe for GUI.

We are all afraid of errors due to manual memory management, but it seems wrong to me to believe that every language that is "safe" from the memory perspective is safe.

I'd argue that in some situations interpreted languages are much more dangerous compared to a simple compiled language like C. With new "safe" languages you do not encounter an error most of the time, but when you do see an error it is quite discouraging to see that your "safe" language fails and you don't have any idea why it fails.

In order to be safe we need simplicity. We need to move the main part of the program to compilation time to have static checks. We need to write comprehensive tests on the parts we leave to the runtime. We need to check inputs at every stage.

We need to be very very careful when using concurrency.

In that matter I find the OpenBSD developers' use of C much more secure than any package on npm.

OTOH C++ is a different beast, it is complex, it has many fine-points to master.

I'd say programming in Go and using QT could be a good choice, if you're considering memory safety above all things.

> With new "safe" languages you do not encounter an error most of the time, but when you do see an error it is quite discouraging to see that your "safe" language fails and you don't have any idea why it fails.

I think it is very odd that you argue for C, which has the concept of undefined behavior, which is much, much worse than any kind of failure the memory-safe languages without static types can offer.

> In that matter I find the OpenBSD developers' use of C much more secure than any package on npm.

Bold claim, they still fall victim to undefined behavior:

https://www.cvedetails.com/vulnerability-list/vendor_id-97/O...

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.

Untrue though Qt itself is not updated to take advantage of C++14 and newer features.

I'll take slightly more complex syntax over untraceable dynamic weak typing of JS.

How many times have you got random undefined?

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.

"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 packages are native code in C/C++.

Further beyond that, Web Assembly is already expanding the language diversity in the Node world. An immediate example is that the major source map processor used by a number of debugging projects (including VSCode) has already moved parts into Rust via Web Assembly: https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with...

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.

I find that a specious argument. The same could be said of anything from programming languages to pizza toppings.

"Thing X is bad because it discourages people from learning about things which are not X."

I would argue that JS platforms actually make it much easier to try out other languages because change languages while keeping the rest the same. Tons of languages compile to and/or run on top of JS.

Honestly, I only clicked on this page to read all the comments hating on electron.

Not helping with my confirmation bias though.

Came here for the same reason. Although I am more interested in what @rauchg is doing

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

I know you're joking, but I did one in Unreal Engine 4, although it's attached to a Z80 CPU emulation for running CP/M (and hopefully FUZIX later on).

https://i.imgur.com/Q6307w3.jpg

The terminal has pretty good ANSI X3.64 support and can connect to a Linux box via telnet.

Ow that is pretty cool! Can we play around with that somewhere?

Hopefully by the end of the year. It's one of those situations where the emulator works great, but there's no game as such for it to interface to yet, and I'm sort of struggling to come up with basic gameplay mechanics.

I would LOVE to play around with that in the unreal engine editor just to see what cool stuff I can do with it. Please release it as a component somewhere by itself without the rest of the game. So much retro <3 for this little console you built.

I have considered that it could be useful for other people just as a component, yeah. I'm still working on the SDK to go with it (a C library and some example programs). Work has gotten really busy lately so I don't know when I'll get it done, but I do really want to finish it off.

Yet people still insist on using Chrome as their web browser.

Is there anyway why it can't be done in Sciter?

https://sciter.com

I mean HTML / JS based solution aren't all bad, it is just we have far too many baggage to carry in the current implementation.

Interested to see how this compares in performance and resource usage with Alacritty[1]

[1]:https://github.com/jwilm/alacritty

Have you tried Kitty? https://github.com/kovidgoyal/kitty, Pretty good too in terms of performance

Rust Evangelism Strike Force to the rescue.

I laughed real hard at this phrasing: > Alacritty is the fastest terminal emulator in existence.

Bold.

Depends what you mean by "fast". It seems to have the highest stdout throughput, but that is not necessarily the most important metric: https://danluu.com/term-latency/

Especially true when the methodology to test performance was just `find /usr` [1], and comparing it with a just a few alternatives. I'm sure they have a better and more thorough benchmark these days, but that was pretty funny.

[1] https://github.com/jwilm/alacritty/issues/289

Alacritty's primary focus appears to be performance (GPU accelerated, no scrollback, no tabs, no native split panes).

Hyper 2's primary focus appears to be features and extensibility.

I doubt they will be in the same ballpark.

tl;dr: Hyper 1 did pretty bad. I don't expect much from Hyper 2

https://drive.google.com/file/d/1eQJPan-hs4AgX1pK45WS2UNjjVg...

source: https://danluu.com/term-latency/

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.

Maybe I'm missing something... is there a benefit to this over a normal terminal/terminal emulator? (eg xterm, mac terminal etc)?

As far as I can tell, putting it in electron would mean that you could embed arbitrary HTML structures inside the terminal (like web page previews or something), but from what I've read, it doesn't look like that's the goal.

I've always wanted a terminal with bloom effects and it seems that Hyper 2 might be able to provide that. But I haven't found a theme that does that, and I haven't wanted it enough to look into that.

Never fear, you're already covered: https://github.com/Swordfish90/cool-retro-term

Bloom effects? As in, glowing and stuff?

I think he means it becomes covered in algae

The benefit is for the authors' CVs

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

Uses weird window decoration, uses a weird type face, doesn't support tabs ... And hell, it's Electron. I'll stay with the few-kb, vala[C]/gtk elementary terminal.

Although it does support tabs and you can use any decoration/type face you want.

With rendering moved to canvas, does it still make sense to use Electron? A lightweight drawing surface + js bindings could do the same in a much lighter package.

While everyone fights about Electron I have a slightly off topic question- why are programs like these called a terminal emulator (emphasis on emulator)?

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.

If it's just drawing pixels… what's the benefit of the web stack?

- Easier to make a multiplatform application, compared to alternatives.

- Makes it possible for people who don't know (and/or don't want to know) anything beyond the web stack to build "desktop" applications.

- Easy to make it look nice by default, because you can reuse all the work that went into building the browser as a runtime, + you have a ton of eyecandy JS libraries to choose from.

Also you can have interesting rendering possibilities like in-line display of images, charts, tables.

Longer-term: new generation of command-line tools with different ux paradigms for interactive use?

Like, <3 TERM=linux and "everything is text" but there are also a lot of possibilities here which would be interesting to explore.

Funny that people "get" jupityr notebooks but not this.

Those possibilities are the reason why I started my terminal project, Extraterm. You can get an idea of its unique features here: http://extraterm.org/features.html. The advantage that Electron has over the alternatives is access to a massive ecosystem of libraries and components which can be reused. For example, if I want to add support for showing tabular data directly, I can grab an existing JS component, maybe a spreadsheet component even, and integrate it.

I've done a little bit of experimenting with "alternate UX and display paradigms" shall we say, and that is a long term goal of the project too. Right now the current implementation focus is on filling out the list of standard boring terminal features which everyone needs and expects, plus some more performance work.

The comparison with jupityr notebooks is a good one and it would be nice to support a richer experience while still being keyboard and command line focused.

jupityr notebooks provides something that is difficult to get else where: multiplayer interactive programming sessions. its also not overly heavy.

Electron is just half remembered dream of flash, but without the efficiency or programming environment. That compiled once and worked the same everywhere.

We threw away flash because the iphone was underpowered, only for it to be replaced with the horror that is modern js centered webdev.

> We threw away flash because the iphone was underpowered, only for it to be replaced with the horror that is modern js centered webdev.

Also a sad thing: Flash sucked for building UIs, because it did not have a set of standardized elements and interactions built in. I'm thinking of all the trivial details like mouse pointer changing when you hover over a text field, or a text field that supports arrow navigation, selection, copying and pasting, a context menu, etc.

Now the browser, as a runtime, has all those expected UI interactions built into all the standard HTML components. And what does the web crowd do? They throw it all away by building their own half-assed reimplementations of every UI element. There's lots of man-hours being wasted replicating the problems of Flash.

For what it's worth, I don't get Jupyter notebooks either.

I see them as a "worse is better"-style half-implementation of Org Mode's tangling functionality on a more mainstream stack. For iteratively building a document that's mixed with some code and some output and looks kinda-nice, Jupyter is good enough.

I'd totally love to see that happening. Except it isn't. I would even accept Electron if the primary motivation was to enable such a rich terminal interaction experience. But that's not what's the case here, apparently.

Also you can have interesting rendering possibilities like in-line display of images, charts, tables.

Like iTerm2? ;)

https://iterm2.com/documentation-images.html https://github.com/lunaryorn/mdcat

There are probably Linux terminals that can do the same.

Funny that people "get" jupityr notebooks but not this.

I think one reason is that Jupyter does not sell itself as a UNIX terminal, so people feel less strongly about it. Also, Jupyter uses a web browser that you probably have running anyway.

DomTerm (https://domterm.org) can "embed" HTML in the output. So to "print" hello.md in an existing DomTerm window you can do:

pandoc hello.md | domterm hcat

This does a much better job than mdcat, because it can use variable width fonts, bigger fonts for headings, and can handle raw html.

I think you are getting down votes because you are answering 'why electron?' instead of the 'why base it on Canvas?' the GP meant. (The release notes say this version switched to Canvas rendering from DOM.) I would like to know too.

>- Easier to make a multiplatform application, compared to alternatives.

If your target machine can run an electron based shell, you can leave the shell alone and just run your web app.

>- Makes it possible for people who don't know (and/or don't want to know) anything beyond the web stack to build "desktop" applications.

Again, changing the shell does what exactly? Just build the web app you knew how to build...

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. (And yes, you can edit up the native terminal but you still get a different looking top bar).

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.

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.

This looks amazing and exactly what I want if I didn't suck with vim.

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.

That's interesting, I'll give it a look! Granted, I'm a big lover of Kakoune and vim-style modal editing.

In your opinion, what does Emacs GUI do that a terminal (or emacs in term) doesn't do well? Ie, how is it best exploiting the GUI aspect?

Sorry for the late reply. I'm actually a huge fan of modal editing as well, can't live without it, so I use evil - and it's perfect. GUI emacs does everything that any other IDE does, and that's what I like so much about it. With vim or any of it's GUIs, normal IDE features feel like "duct tape" on top of the program. Whereas, emacs was meant to be used in this context. I mean, for example, when programming in C I can even use emacs to debug (it has a GUI for gdb). And those kind of advanced IDE features are available for any language. Not even touching the fact it's just a lisp machine and you can build any kind of program you want in it, it takes extensibility to the next level with a lisp dialect that's relatively easy to learn, whereas extensibility in vim is limited to googling for vimscript code someone else wrote (unless you take the time to learn vimscript shudders). Emacs gave me everything you said you were looking for, at a time when I was looking for those exact things. I wanted a modal editor like vim that actually was an IDE, had IDE features, and was completely extensible. Emacs checks all of those boxes.

If you're a vimmer and want to start out with emacs, try spacemacs. I used it for a year before building my own emacs config. It's an incredible program, won't take you long to get running if you're used to vim, and after a week I'd bet you'll have a hard time going back to gVim.

Emacs has a GUI version with gorgeous fonts, images and everything. Vim also has a gui version, though it's not as good. I think neo-vim has a few gui front ends as well.

Believe me, I wish I spent more time getting familiar with vim to enjoy that workflow. The bottleneck in programming something is very rarely my typing speed though.

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.

The ultimate is when you can jump back and forth between your editor and your terminal without having to grab a mouse touch your trackpad. Tmux is so beautiful for this. I have Atom doing it, but it's a bit clunky.

Gnome jumps back to my last application with alt-tab. Pretty sure most desktops do.

Oh great, a terminal emulator using 100+ MB of RAM. Just what I needed.

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 disappointed me.

1) Text wrapping is a such important feature in modern terminal emulators I cannot live without. They added text reflow in 2.0 as far as I checked. But when you use you would see it is complete disaster. Text does not wrap sometime. Sometime it completely erased. So long story short it is completely buggy.

2) Start up time is horrible. Electron based app should generally design a background service and a UI process. This way when you launch UI it would be way faster than cold start up. I do this for chrome, slack, discordapp, etc. I wish they had better architecture and was a option to enable background thread or service.

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

"2) Start up time is horrible. Electron based app should generally design a background service and a UI process. This way when you launch UI it would be way faster than cold start up. I do this for chrome, slack, discordapp, etc. I wish they had better architecture and was a option to enable background thread or service.

I don't even know where to begin with this. So, the suggestion for "the stack for my thing is so large and deep that it takes forever to startup" is not "hey, maybe don't do that" or "hey, maybe we should find a way to optimize", it's "make sure it's always warm".

I don't even begin to understand why this is a world we want to live in.

> Start up time is horrible

I'm surprised to hear that there are people who fully close and quit their terminal emulator.

Try cmder for Windows. It’s nice and fast.

I am using Hyper 2 since the beta and I really like it. It has replaced iTerm for me. Performance may still be an issue for some people. For example, printing to stdout seems slower on Hyper than on, let's say iTerm. To me it is noticeable but still feels nearly instant.

Why did you choose Hyper? IMVHO iTerm2 is still far way better as a terminal.

Purely due to aesthetic reasons. I am not using the terminal for any complex stuff and this allows me to use the terminal which looks the best to my eyes. If my requirements change I may go back to iTerm but for now: something simple and nice looking is okay.

It supports the same themes I use for vs-code, which I like. Plus I prefer the minimal window borders.

Pop quiz: what's more ridiculous, nodejs based command line utilities that do the same thing as two existing shell utilities and a pipe or a while loop etc; OR, an electron "shell"... which can then run those same nodejs "utilities"...

Oh maybe that's the whole point. They want "it's javascript all the way down".

I think I'd literally rather use a shell built on actual turtles. A turtle-shell, if you will.

My annoyance with Electron surfaces when it's being used for tools that you need to use a lot and that potentially are started often, with a lot of instances. Slack clients for instance, but editors and terminals as well. These are precisely the kinds of applications where you want low memory usage and milliseconds worth of startup time.

Additionally, this annoyance probably has more to do with the fact that Electron is used by developers for other developers. If it would be used to replace Excel the rage would probably be less pronounced. I'm still wondering what would happen though, because of all the subtle ways in which the UI experience would be broken for someone who's used to Excel.

We're getting here - https://www.destroyallsoftware.com/talks/the-birth-and-death...

If you want an aquatic shell, there's always fish

https://fishshell.com/

Zeit's generally pretty JavaScript focused so it doesn't surprise me, but another electron app. Man :'(

To really get into the 'JS all the way down' you could run it on JSLinux [1] or a similar JS-based full system emulator.

[1] https://bellard.org/jslinux/

Turtle [0] indeed is a much more useful "shell" (it's not actually a shell, but so isn't this electron thing)

[0] - https://hackage.haskell.org/package/turtle

The whole electron stack disgusts me. Mainly because of battery usage on my laptop and my phone!

Its a clear example of "We can do it but should we do we?" The answer is NO!

Electron doesn’t work on iOS or Android, so phone is inaccurate.

It's not because it exists that you should use it. If you don't like it, don't use it, and it won't take any battery usage on your phone

I personnaly think a terminal based on web technologies is not something I would use, but if people are happy to use it, as soon as they are aware of the tradeoffs, why not?

hey, how else can I change the transparency of my shell with css ?

You can't. You can only change the transparency of the terminal.

This comment (though probably by mistake) manages to perfectly illustrate the "reinventing things that we don't even understand" mindset that's going on in most of tech.

(Also, there exist terminals written in C++ with Qt, and QtWidgets has had CSS support for custom styling for at least 10 years, probably much longer.)

This is a great "well actually" that also manages to be technically incorrect. If you change the styling in your terminal emulator, it changes the transparency of your shell (and other terminal programs).

The main example would probably be Konsole from KDE. Quite a hog in the world of terminals but doors is things well. Compared to running an electron instance, it is slim.

you're kidding, but that's really it: people love to hate on electron, but nobody has a better solution. it's about "I can reuse my web-based UI on all desktops, mobile and web", not about css

Well web based uis are subpar IMO, especially accounting for resource cost.

/me goes back to emacs

Why do you need to use CSS specifically?

macOS built-in Terminal.app has had transparency (even varying transparency for focused vs background windows) for years.

Edit: oh, maybe you were being sarcastic? It's been a long day.

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 80% of what I wanted (including, hear this, ascii shadowed floating editing windows.. talk about overfancy) and used zero resources.

Today to have that kind of interactions you'd need a somehow recent quad core and 4GB+ of ram. All that mostly for a bit of eye candy (css may be of some use to decorate tokens/entities to give additional info, but I rarely see that).

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 ?

Turbo Pascal had more tricks, it could compile to memory (at least in version 5, if memory serves well). Mind you, not a RAM disk, it could compile and run a MSDOS .COM file from memory itself. Following the filenames during compilation was difficult, as they passed so fast (20Mhz 386sx with 2MB).

The compilers and IDEs from that era were truly pieces of art. I also remember TopSpeed Modula-2 that also included its own task scheduler for real time DOS (using clock interrupts, I guess).

With Gnome Terminal, it uses CSS to style the desktop.

When you absolutely need that "tar xf" to take 23900 times longer.

why would it take 23900 times longer

`tar xf` probably wouldn't take longer, but `tar xvf` might, depending on how good/bad the stdout performance is.

I'm somewhat on the fence when it comes to Electron applications, because I do tend to prefer everything to be "lightweight" even if the machine it is on has a ton of performance overhead.

That said, I have not disliked my experience with VS Code and Hyper. I like iTerm's performance better but I aesthetically prefer Hyper. I like Sublime Text's performance far more than VS Code, but VS Code has come a long way and is free, and I don't use it enough to justify paying for ST currently.

For something so essential in my daily work as terminal, I'd rather stick with iTerm or similar. However, it's an interesting project and congrats to the author on v2.

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

Have you tried DomTerm (http://domterm.org)? It works great on Windows, though it requires WSL: https://dzone.com/articles/running-domterm-terminal-emulator...

Give ConEmu a try if you haven't yet. https://conemu.github.io/

When the aliens will slurp up our "latest advancements in technology" they will have a huge clusterfuck and some serious hickups. Maybe we should put warning-stickers upon some stuff.

tried it for a bit, moved back to iterm2

While it was thinkable all the time, it renders me speechless, that finally somebody has put that stack under a terminal. The next big thing will be electron-based smooth-scroll, mouse-animation and finally: a 70mb beep.

I'm just waiting for an electron based web browser.

That has already been done [0].

[0] https://github.com/brave/browser-laptop

I'm speechless. It's monday today and the day just begins. I hope for better news along the way ...

Actually it makes a lot of sense. For an electron based browser the vast bulk of it is in the HTML/CSS/JS engine just like normal, but instead of doing the higher level code and UI chrome in C++, you just use the same language and facilities which the engine itself already provides.

Brave is actually really good from my perspective. I use it as my main mobile browser. They're looking to add support for the p2p `dat://` protocol this year as well!

I also don't get it. Why would I want a full web browser to power my terminal? Just because we can, doesn't mean that we should...

You wouldn't. It's pretty much purely a convenience for the author of the software.

Windows?

why bother with a cross-platform framework, then?

No operating-system specific bar on the top of the window is kind of nice for screen casting.

Hyper is the only proper terminal emulator on Windows. Time to upgrade.

DomTerm (https://domterm.org) works very well on Windows using WSL (https://dzone.com/articles/running-domterm-terminal-emulator...).

Have you tried ConEmu? That's definitely my favorite.

ConEmu makes Windows a bit more palatable. But the lack of a "UNIX philosophy" (everything is a file), makes the CLI less powerful on Windows.

Some may argue that PowerShell fills that void. While it helps, it is not the same.

Maybe not for long: https://github.com/Microsoft/vscode/issues/34442

Also the default Windows terminal is getting tabs: https://github.com/Microsoft/console/issues/49

This is also fascinating: https://github.com/Microsoft/console/issues/57 - a proper PTY for Windows, implemented by Microsoft, with the ConEmu guy giving it a thumbs up.

Have you tried Powershell?

Interesting experiment, but I think I will stick to rxvt.

Why would anyone pay for a terminal?

Why does everything have to be built on HTML/CSS/JS nowadays? What happened to the days when people would learn new languages that were appropriate for the project they were taking on?

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 languages.) Hopefully I won't need to now.

On desktops I would just go native. Is it really that hard to maintain several code bases? Is there literally no other options at all? I'm considering Go + QT here, or something along those lines.

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

I've been playing with Flutter and it seems pretty good. Dart isn't too hard to get your head around and isn't too annoying, although I do find myself disappointed that I have to learn yet another language for it. I don't have a particular problem with learning languages, but it's another speedbump on the way.

And Dart is about a million times better than JS for the way I like to think about code.

Glad to hear it! I'm looking forward to giving it a try, but right now I'm hooked on Lua and Corona! Ha! :)

I think that electron desperately needs boot loader and own kernel, then they will be able to reimplement whole operating system in js.

...god of bloated software and goddess of complex solutions of simple non problems got their blood sacrifice and the sun will rise again.

Like I've said a million times, https://medium.com/p/electron-is-cancer-b066108e6c32

Why would you use a full web stack terminal emulator, over.. well a normal native and actually reasonably fast terminal emulator?

The trend is catching on, so maybe one day we can't even reach for a native email client because it will be unmaintained in favour of the hackable html webstack email client.

Congratulations on reaching v2 tho!

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

Yeah that seems a lot more like what I would expect.

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 many people would specify it on a survey since they basically have to use it while working on a server.

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.

> 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?

> if it does the same thing your hammer does...

It does not do the same thing as my hammer. Not even close. As a matter of fact, with Vim you cannot get even half the functionality of a good graphical IDE or even something like VSCode without drastically lowering your standards.

> Optimizing the wrong thing...at the expense of just about every other aspect of computing...

Vim lacks discoverability. That's the first major aspect of computing that Vim just completely throws out the window.

Speaking of windows - Vim also lacks integration with the rest of your graphical OS by default. You can't use your normal graphical file picker, you can't just drag files into Vim and you can't easily configure Vims activity to be reflected in the rest of your OS (in areas such as recently-edited-files and so on). Sure, you can get a graphical version of Vim, but now you have 2 problems - you have to configure different versions of Vim to use it the way you want to.

Even the mouse pointer a hallmark of modern computing, is largely useless in Vim!

Also, text-based configuration is throwing out another majorly useful aspect of computing: convenient and easy to access settings.

Anyway, if you enjoy editing text like it's 1976 - that's fine with me. Just don't try and tell me it's as good as my hammer because it simply is not.

I switched over the past month or so - started by using the vim plugin, and then eventually when ditched it and went with vim itself.

The scary thing for me, even after getting used to navigation, was the lack of it feeling like an IDE - autocomplete, compile on save, etc.

After installing some plugins - it's now wonderful and I enjoy it much more than VSCode.

There's a ton of little extra benefits you get from the switch besides the usual - for example, when you use a mouse, the time you spend navigating visually is kinda wasted. With a keyboard, that time is spent thinking about "what's the next parenthesis" or "what's inside these quotes" which turns idle time into something more useful like getting more familiar with the code.

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.

> And somehow I find the VSCode's multi-cursor feature so much more convenient than Vim's macros.

That’s not an unpopular opinion, I suspect it’s because multiple cursors provide an extremely tight visual feedback loop (feedback after every action) as compared to macros where you kind of just shove actions into a black box and pray it works correctly for the next location you test it on

> Correct indentation when pasting is a pain in my opinion.

    :set paste

gg=G

couldn't be easier my friend

Using vim is like driving a car with manual transmission. The first time you do it, it seems so extremely complicated and you think you never would be able to be fast with it. After some time you are got used to it and you think it‘s impossible to be fast without it.

Does editing text with the keyboard alone make sense to you? That's the gist of it, you use commands to manipulate text. It's hard to grok at first when you're only used to textarea style editors without modes.

It has a learning curve that'll take about 2-3 weeks to convert to muscle memory and become habit. Give it a shot. You'll learn something new and if it doesn't work out, VSCode will still be there :-)

"Electron is horrible to deal with as an end-user" - this is not reflective of your average user at all. Most people are just happy to have an app that looks, acts and feels native.

The average end-user has less than 4GB of RAM and would struggle to run electron apps at all. They would get frustrated with the computer being slow but would not know who to blame.

Aside from that, electron apps do not look, act or feel native.

Does the average developer though? I wouldn't want to work on a developer machine without at least 8gb.

It really depends, some work might necessitate 8GB+ but most really shouldn't and only do because the tools they use were built by developers with that much RAM.

At work I need my 16GB but that's because Visual Studio and the app I'm working on the most are memory pigs. Visual Studio 2017 doesn't really have any compelling features over 2005, but 2005 ran quite comfortably in 2GB, so with this piece of software alone I need a lot more memory for no gain.

At home in the other hand I have a fairly low end (and now 3 year old) dell laptop with 8GB of RAM, but with my current c project and DE (i3, riced way more than necessary) I'm using less than 2GB (with vim+unix as the IDE), so plenty to burn when required. This is a more productive environment too, I have a fully incremental build that will compile, run unit tests and run memory tests in the blink of an eye every time I save a file, so I'm getting much more feedback much quicker than I do with Visual Studio.

Devs on lower resource machines will also be dogfooding much better. If their apps are slow and bloated then they'll feel the pain their users will and be much more likely to address them. Windows 10 might have a start menu that didn't take several seconds to open if the developers weren't on top of the line surface pro's.

I can work productively on my 6yo notebook with 4 GB RAM, because a terminal, CLI tools, vim and a browser covers my needs. If I had to use Electron apps, I'd probably have to look into buying a new notebook, which is quite wasteful both on the money side and on the material resources side of things.

Some developers will probably need more than that because of the resource demands of their specific fields, but other than that, 640 KB ^W^W 4 GB should be enough for everyone.

Electron apps don't look/act/feel native.

I'm generally pretty pragmatic about using stuff that is convenient even if might not be too efficient, but I have to agree with most usage of Electron that I find. I'm using a MacBook that, while a few years old, still does almost everything well. It struggles when I have a few Electron-based apps open and that's just ridiculous. It also drastically impacts battery life.

It's reached a point where I use my iOS devices for Spotify and/or Slack just so my laptop can run whatever other crappy Electron app I need to use.

I find that VSCode is almost worth it, but that's perhaps one of the few exceptions (and I still go for Sublime Text most of the time).

Any app that needs to be persistent really has no business using Electron. It's a terrible waste.

Oh and as for the title on that article, Bunch of people took offence and no one got it but it's a reference to when Balmer called GPL/LGPL cancer and hippie culture.

Because it's pretty. Because you get state of the art Unicode decoding and support. Because you can get a terminal on Linux in a first class GUI system that's normalized across all major operating systems backed by billions of investment.

Because you get state of the art Unicode decoding and support.

What does this even mean? UTF-8 decoding is trivial. In fact it's designed to be simple: it's a prefix code that is self-synchronizing.

Rendering glyphs and composing characters is hard in comparison. But Cocoa, Qt, etc. have had great support for rendering unicode for ages now.

I have no recollection of having problems with iTerm, Terminal.app and many Linux terminals for rendering unicode the last decade or so. (Only with people setting their locales wrong.)

Most modern terminal emulators will give you all of this, in fairness, and it’s probably one of the simplest classes of programs for which to provide this!

Look several years into the future and what you could have there is electron being faster/lighter.

Being web-based gives you a standard way for fetching and displaying content. It's just a matter of time that the performance improves. Especially when many people are experimenting with it.

> maybe one day we can't even reach for a native email client because it will be unmaintained in favour of the hackable html webstack email client.

It's definitely possible, once the browser becomes the new OS.

Why spend the time and effort to do that, though? The amount of resources used to bring Electron into something reasonable could be better used elsewhere, advancing things that we don't already have.

That's what has been said for a while about Electron: it'll be optimized and less heavy. Most applications use Electron are just as heavy as they always has been, and where there are exceptions, it's more due to moving away from the Electron-stack and putting functionality in lower-level languages, or things like this where it uses only a few elements and defers to other rendering techniques.

Reply on news.ycombinator.com