Live data from Hacker News

Electron is flash for the desktop (2016)

josephg.com

261–270 of 1001 posts

Re: Electron is flash for the desktop (2016)

#261

Here's the thing. You know what the alternative to all of these Electron apps coming out is? If your answer is "A native Cocoa/WPF app", you are on another planet, the answer is, "It wouldn't exist at all". Nobody in the last 5-10 years cared about writing Desktop apps before Electron came along, there's basically zero money in it, and it's massively expensive, both in terms of actual dev time per feature (easily 10x…

One more "Big Deal" is that both Chrome and Electron are not accessible by default like native apps and take performance hits when VoiceOver is enabled.

I'm not "excited" that macOS is flooded with apps that have poor accessibility experience while Apple itself is fanatical about delivering first-class accessibility experience - like Safari having accessibility always enabled.

Re: Electron is flash for the desktop (2016)

#262

Earlier quoted context omitted.

Yes. You just described modern computing.

Computing for ever. We use C to avoid writing assembly. Use Java to avoid writing C. Use Python to avoid writing Java. The world is asking for more and more software, and the resources to provide it are not following so people are taking shortcuts. Want something better ? Someone has to pay for it.

We use Java because Python proved to be too slow.

Re: Electron is flash for the desktop (2016)

#263

Earlier quoted context omitted.

That's nonsense . Desktop apps have been frequently released since forever. The underlying issue here is that Electron reduces the barrier to entry for cross-platform development . That is, it's cheaper to build a single cross-platform application in Electron than it is to build two or three native applications, and you can re-use your existing web experience. I can completely understand why companies might choose th…

> That's nonsense. Proper this and proper that, and don't get me wrong, I agree, but parent is correct -- and that is these apps wouldn't even exist if it wasn't for Electron. It just wouldn't have been a consideration for it to be a desktop app. Instead it would have just been thrown up on the web. For example VSCode would have just been some type of online IDE clone like Cloud9 or something similar. If you think th…

I think people are talking past each other.

Yes. Electron enables some new stuff. New stuff that wouldn't exist otherwise.

Yes. Electron is a bucket of bloat that saddles what should be small, simple apps with enormous amounts of crap that has nothing to do with the app's functionality.

Both of these can be (and are) true.

Re: Electron is flash for the desktop (2016)

#264
post #116

Earlier quoted context omitted.

What you call "trade-offs" appears to me to be developers externalizing their costs onto users. There are costs to developing desktop applications and developers don't want to pay them, so they make users pay for them in wasted hardware dollars, bandwidth, RAM, battery life, and poor integration.

Everything in the world of web-stack development has turned externalizing costs onto users as a core first principle.

How about PWA, Service Workers, WebAssembly? Thousands of developers are working hard on improving the UX, reduce battery usage, wasted CPU cycles, network traffic, latency.

Re: Electron is flash for the desktop (2016)

#265
post #61

Telegram Desktop is very good example of modern desktop client done in the most efficient way. C++ and qt, nothing else. Works like a charm an all major operating systems. Easy to install, use and update. Great stuff.

Except they've rewritten their Mac app in Swift now. So there must be a reason they moved away from that.

Probably because Qt apps don't feel like native macOS apps.

Re: Electron is flash for the desktop (2016)

#266
I've slowly started to remove Electron apps from my workflow. I used to use Atom, but I've switched to an paid for Sublime. The last two apps I have which use electron are Hyper and Slack. Hyper could go, but I really like the interface and Slack probably isn't going anywhere.

Real-time update:

I just checked Activity Monitor and Hyper is leading average energy impact followed by Xcode. Looks like I might be switching back to iTerm this weekend.

Re: Electron is flash for the desktop (2016)

#267

Here's the thing. You know what the alternative to all of these Electron apps coming out is? If your answer is "A native Cocoa/WPF app", you are on another planet, the answer is, "It wouldn't exist at all". Nobody in the last 5-10 years cared about writing Desktop apps before Electron came along, there's basically zero money in it, and it's massively expensive, both in terms of actual dev time per feature (easily 10x…

Bullshit. Spotify, for example, existed before Electron, and it was very fast. Text editors existed before Electron, and they didn't require 300 MB minimum to run. Same with collaborative chat programs. Electron is just a way to reuse web developers for desktop development - I.e. a way companies now have to cut development costs.

Vim and Emacs are probably much slimmer, but a comparable GUI editor- Sublime Text, is using 311 megabytes for just one window of a folder that has 200 files in it.

Re: Electron is flash for the desktop (2016)

#268

Earlier quoted context omitted.

That's nonsense . Desktop apps have been frequently released since forever. The underlying issue here is that Electron reduces the barrier to entry for cross-platform development . That is, it's cheaper to build a single cross-platform application in Electron than it is to build two or three native applications, and you can re-use your existing web experience. I can completely understand why companies might choose th…

> ... Electron applications are shite in comparison with proper native applications. Is that true from a user's perspective? The average user I know would not have the idea that Slack is somehow inherently worse than say MS Word or any other truly native app they use everyday. What would Slack gain by integrating better with my Mac? Slack starts up too fast for me to read the little quotation (penultimate Macbook Pro…

I totally agree with you. I only use Slack from we app but I'm a heavy user of VSCode and Spotify. I believe in standardized Web API's rather than a clusterfuck of native API's.

The problem here is the base platform Electron and underlying Chrome/Nodejs

But as consumers we feel when our browser lags, so browser vendors optimize speed over memory and cpu, caching the shit out of everything. The Web is a dangerous place so they further isolate every tab as process, sandbox them and keeps lots or copies of the same thing in RAM because a security flaw is a lot more shameful than a memory flaw.

You are right, electron is a hog. Last I checked all, electron, chromium and Nodejs were open source. We can actually make a difference.

Making noise also makes a difference. When someone complained about VSCode cpu usage because of idle cursor and it blew on HN, next month's release had a fix (for all platform)

The truth is you can't move fast doing native development with different libraries. Electron keeps your dev costs down and allows you to move very fast.

Re: Electron is flash for the desktop (2016)

#269

I've slowly started to remove Electron apps from my workflow. I used to use Atom, but I've switched to an paid for Sublime. The last two apps I have which use electron are Hyper and Slack. Hyper could go, but I really like the interface and Slack probably isn't going anywhere. Real-time update: I just checked Activity Monitor and Hyper is leading average energy impact followed by Xcode. Looks like I might be switchin…

What is the draw of Hyper over iTerm2?

Re: Electron is flash for the desktop (2016)

#270
post #196

Electron is just another proof that ease of programming matters. Node.js too was a terrible idea. Who in their right mind would write server-side javascript? It turns out: pretty much anyone who didn't want to have to screw around for hours before being able to respond to a simple http request. Similarly, it is way harder to write a desktop app than a browser app. DOM / CSS manipulation, however bad they are, are yea…

> Node.js too was a terrible idea. Who in their right mind would write server-side javascript? It turns out: pretty much anyone who didn't want to have to screw around for hours before being able to respond to a simple http request.

Pretty sure you could do that as easily in PHP, Ruby, Python, Perl before Node.

> And what about Python for data analysis? The one language that is known to be 10x slower than C becomes the de-facto standard for a field where what matters most is code performance. Again: ease of programming.

When code performance matters most, you're probably still using Hadoop, C/C++, Fortran. Python is mostly in competition with R, Matlab, SPSS and Excel. Julia is the new kid on the block, and it was designed to be more performant than Python and R.

Post reply on HN