Hacker News Reader

Comment by akanet | Hacker News Reader

I think there is a stunning amount of "resource cynicism" in this thread. Yes, this application uses much more RAM and CPU than a "normal" terminal emulator. The project author is clearly trying to explore other ways that terminal interaction could work, and is using a well known framework to accelerate this process. If you use this project, you're using it to experiment with a new way of working with the terminal, not to get screaming fast GPU accelerated screen rendering. Potentially discovering new, valuable ways of working with computers is worth doing, and should be encouraged.

View on HN

I encourage experimentation like this, and I've been spending some time thinking of how a terminal emulator could be re-invented. Some of the best ideas I already see implemented so I'm very excited to try it.

Unfortunately, in practice it falls short. RAM is one thing, but CPU usage is absolutely through the roof. The app freezes when trying to type "cd jobs", then consumes all CPU cores fully and stalls my computer. Fans spin up and doing a simple "ls -al" takes several seconds for it to complete. During this time it will not buffer keypresses properly and I experienced old keypresses being mixed with new ones, to create a command I did not type.

The project doesn't sell itself as experimentation. Even if it did I'd advice against testing it, simply because of the severity of the issues I encountered using it for 5 minutes.

This project shows what can be done. It's a step forward. Now it's up to other terminal emulators to see how far they can go towards this.

It's a hog because it uses electron (in other words chromium browser), on the one hand this makes a lot of sense for text, CSS and HTML are useful tools for this kind of experimentation, on the other hand electron is a behemoth and this makes xterm look like a twig... I think everyone is in agreement that terminal emulators should be lightweight.

From the README.md:

> Also, unlike most of the emulators you can meet nowadays it uses HTML and CSS for its UI (exactly as Atom does), which means we can stop misusing unicode characters and make a better looking terminal with appropriate tools.

I added emphasis.

When they say it's the right tool for the job, and in reality it's not... well, you get reactions like these. And justifiably I think.

The author meant it as "no more ASCII art for window decorations in the terminal console", and you just twisted it into "use a Web browser, because that's the right way", am I right?

But what extra features does this actually provide? According to screenshots, it has:

* a popup menu * colored background lines * another popup menu

well that's not exactly innovative (a popup menu for argument completion is available in fish today without eating RAM like Chrome)

It probably poses some benefits for terminal beginners, such as helping designers use git for instance in a UI more welcoming than the standard term.

I see this attitude all the time, namely the idea that difficulty is somehow proof of quality, or "professionalism" of a tool. It's obviously rooted in some instances where it is/was correct, such as the superior typesetting of LaTeX vs Word for academic work. But it's not an ironclad rule, and it shouldn't be trotted out as an argument anytime someone tries to improve existing tools. In this case:

- I'd say I need to look up any option flags or commands I use less than 15x/week

- Even the most professional 10x developer will spend a significant amount of his time with such commands, making this feedback useful

- The shell is essentially a REPL, but most people forgo most of its potential because the language isn't core to our work, and somewhat hideous. Anything that helps discoverability could be useful.

And, for what it's worth, designers that work with code usually don't have problems with git. Designers that work with photoshop would rarely need git, which is kinda out of its element with binary data

Emacs has had both shell completion popups (via Helm) and a better git UI (magit) for a number of years now.

"I can't work with this, because it's too slow" isn't resource cyncism. It has some neat ideas, but I can't use it as a terminal emulator.

You appear to be suggesting we forgive the project for its poor memory footprint because Electron was used as a sort of rapid prototyping tool to get v1.0 out the door.

I think you know just as well as everyone else that this project's use of Electron is unlikely to be an interim measure. It will (probably) always be a resource hog, just like Chrome will (probably) always be a resource hog. That's a conscious choice that is here for the duration.

Using Electron may have accelerated the process but let's not pretend that the author is going to rewrite it in something more performant once a little traction is gained.

If there is shown to be a demand for this kind of terminal UX, someone may well write a native version of it. Possibly it will push some of the existing terminal emulator projects to add new features, or someone will fork one of them.

Either way, it's nice to have options, and it's nice to see innovation, and if Electron makes it easier to innovate we should be glad of that.

Technically, adding a 5th prong to a middle of fork that bends backward is "innovative". But is it useful?

Okay that was a bit snarky, but.. aside from the primitive monkey part of my brain that cringes at any electron app's resource (ab)use, there's the fact that these apps are proliferating like crazy, and the resource usage adds up after a while.

If all you're running is Atom, you probably don't care. But when you're using Atom, Simplenote, Discord, Slack, Nylas, and Brave all on the same box at the same time (hi!), it's enough to bring even a modern desktop processor to its knees when any of them misbehave. With Moore's law on its way to being broken, I'd like to see tighter development, rather than this sprawl of easy-but-wasteful tools.

Electron is to app development as Keurig machines are to coffee. Easy, convenient, horribly wasteful and inefficient.

I'm not suggesting that at all. I'm saying this project would likely not exist in any form without Electron. If the ideas expressed within are successful enough, realistically speaking people would either:

  1. continue using it despite the footprint
  2. merge similar ideas into other emulators
  3. fork and rewrite in whatever the next paradigm for expressive UI apps is (with hopefully a smaller footprint)

>I'm not suggesting that at all.

My mistake, then.

So many people miss this. This project (and many others like it) wouldn't be faster without Electron. They flat out wouldn't exist.

If people don't want to use Electron apps then don't, but don't fill every single discussion of an Electron app with the same old whining.

>Using Electron may have accelerated the process but let's not pretend that the author is going to rewrite it in something more performant once a little traction is gained.

If we also dont pretend that the sort of people complaining are anything but a distraction.

Because nothing is stopping them from writing something they like better, except off course skill, attitude and discipline. Thankfully they are able to contribute something much more valuable: opinions.

So, yeah. Maybe its a resource hog. Its still interesting and far superior to resource friendly version with the same feature set due to it having the awesome feature of actually existing.

> Because nothing is stopping them from writing something they like better, except off course skill, attitude and discipline. Thankfully they are able to contribute something much more valuable: opinions.

If people don't want feedback, then they shouldn't post on HN. HN is a place where plenty of people provide opinions whether others like it or not. If that's not something people want, then they shouldn't be here.

As for making something better. Better solutions already exist. Terminal emulators are an already solved problem. What terminal emulator problem will be solved that hasn't already been solved by urxvt, KiTTY, Serial, or any of the other Electron based terminals like Magnesium or Hyper?

That's not to say people shouldn't try as there are many reasons to do so. To suggest that opinions are somehow less valuable than yet another implementation of a terminal emulator written in a bloated framework based on a language that was designed in 11 days just to animate web page elements - and that people should reinvent the wheel or shut up... well that's just like, your opinion, man.

>What terminal emulator problem will be solved that hasn't already been solved by urxvt, KiTTY, Serial, or any of the other Electron based terminals like Magnesium or Hyper?

Well if you clicked the link, you would see a number of original features, including html output support. And i don't think it's fair to say that modern javascript is the same language as the one Brandon Eich designed in 11 days.

But if you think that constitutes 'feedback' -- that wouldn't be my definition.

>If people don't want feedback, then they shouldn't post on HN.

Which is what i generally suggest people do -- not because they don't want feedback, but because most people would simply lose motivation when the majority of people react to the glimmer of the word 'electron' and don't bother to click the link or check out the features.

And you can replace 'electron' with anything really. If somebody writes something in Java, there is a good chance some people will react saying that the JVM is evil or how Java is a horrible enterprise language. If somebody writes something in PHP, they'll get the PHP is a horrible language. If somebody writes something in C, they'll get a 'C is too insecure'. If somebody writes an OS-X app or a Windows app, they'll get feedback about how they picked the wrong OS.

It's feedback in the same way that fat shaming a classical pianist would be feedback. If the same 'feedback' can apply to millions of projects without alteration or requiring any effort to establish whether it's applicable -- that is not feedback, that is just taking the piss on something.

So the only feedback that is permissible is adulation?

I'm sorry. I don't think i phrased it well enough. I thought this project was quite interesting, because it has interesting new features -- things radically different from the alternatives. Whether those are good or bad ideas could be an interesting discussion.

Instead, it's a thread full of people who didn't actually check it out, but abuse the opportunity to repeat a knee-jerk reaction to electron. It's just feels like going to a concert and instead of people talking about whether they liked the music or not, they just default into fat shaming the singer or something to make themselves feel better about themselves.

>So the only feedback that is permissible is adulation?

I guess we differ on what constitutes 'feedback' -- i didn't see much in this thread that would qualify as such.

> If you use this project, you're using it to experiment with a new way of working with the terminal, not to get screaming fast GPU accelerated screen rendering.

Screaming fast GPU accelerated screen rendering _is_ a new way of working with the terminal IMO. All hail alacritty. That's the kind of innovation I support. Trying to max out RAM and CPU for a slightly better looking UI is not something I am even going to consider trying out.

But why does this come up every time? When one puts a thing online for others to use, there will be responses, some positive, some negative. Nothing to be scandalised about.

Also, speed and resource useage is a valid concern. Some comments say that it's practically unusable on modern hardware, and on my laptop which is 7-8 years old, I can't touch this when it comes for linux (non that I would, but) because Electron is just too heavy for my computer, and I'd rather not use it than replace my device.

I agree with this. Also, I think that if this (Electron-based apps) keeps getting the type of attention it has been getting (people who are used to web technologies using it for native apps), it will push on Google and hardware manufacturers to start optimizing this stuff more and more. If eventually Electron apps run blazing fast and take miniscule amounts of CPU (not to mention CPUs will continue to get better and faster and more efficient), wouldn't it be better for everyone? I think this kind of stuff is innovative and keeps pushing the boundaries, so I'm all for it.

I would agree with you if the link's README wasn't so cocky

Reply on news.ycombinator.com