3 ms·
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 t
by na85 10y ago
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.
- jsnathan 10y agoIf 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.
- Karunamon 10y agoTechnically, 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.
- akanet 10y agoI'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)
- na85 10y ago>I'm not suggesting that at all. My mistake, then.
- markmark 10y agoSo 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.
- ralfn 10y ago>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.
- iuguy 10y ago> 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.
- ralfn 10y ago>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.