Live data from Hacker News

Electron is flash for the desktop (2016)

josephg.com

331–340 of 1001 posts

Re: Electron is flash for the desktop (2016)

#331

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…

If you basically agree with the parent post, why do you say it's nonsense? > The underlying issue here is that Electron reduces the barrier to entry for cross-platform development. Precisely. > The trade-off — and there is a trade-off — is that Electron applications are shite in comparison with proper native applications. But native applications are shite in terms of portability. > But let's be honest here – there is…

The "nonsense" part was that "nobody" was writing desktop apps for the past 5-10 years.

Re: Electron is flash for the desktop (2016)

#332

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…

> Nobody 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 the cost), and also in finding specialist developers who know these dated technologies. Clearly Java never existed. I've been experimenting with Swing lately because Java has a library I'm interested in using. It's a breath of…

If, instead of Swing, you use JavaFx (which comes included with Java) your UI will look nicer. It even has an embedded Webkit browser that can easily interact with JVM code. This means you can program your UI in any HTML/CSS/JS framework you want, and any other logic in any JVM language (Java, Scala, Groovy, Clojure, Kotlin, Ceylon, Frege, etc.)

Re: Electron is flash for the desktop (2016)

#333

People complaining about electron are the same type than the ones that used to say : - why are people writing this stuff in C. It's so slow and you don't have as much control on memory. Write it in Assembly. - why are people writing this stuff in Java. It's so slow and you don't have as much control on memory. Write it in C. - why are people writing this stuff in Python. It's so slow and you don't have as much contro…

> why are people writing this stuff in C. It's so slow and you don't have as much control on memory. Write it in Assembly.

did anyone ever actually say this?

> why are people writing this stuff in Python. It's so slow and you don't have as much control on memory. Write it in Java.

this one is odd to me considering Python came first...

Re: Electron is flash for the desktop (2016)

#334
post #62
post #18

A lot of Slack's high (background) CPU usage is caused by GIFs, in my experience. Just did a quick check on my quadcore MBP, having Slack fullscreen out-of-view with nothing animated in view gives it a CPU usage of 0,1% with spikes up to 2,5%. Switch to a conversation with a single animated party parrot emoji, go to another fullscreen app once again, and CPU usage never drops below a whopping 22%. For an animated par…

Post author here. I thought about that, but there weren't any visible animations playing when I took those measurements. And the 5% figure survived a restart of the client. Its possible there were gifs playing above-the-fold somewhere and reloading themselves, but if so I'd say thats a bug somewhere in the interaction between the 15-20M lines of code in slack, electron and chrome. Its also worth noting that blog post…

Have you noticed any improvement in your other apps?

I have Atom and Mattermost (Slack clone) running right now with very little avg. "energy impact". MM is at about a half gig in memory though.

Re: Electron is flash for the desktop (2016)

#335

Earlier quoted context omitted.

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

seriously. and skype is a grand example of how shitty a native client can be. tired of this argument. if you put in the proper effort, your users won't care or notice.

You are of course correct. It's possible to make awful native applications, and good non-native applications.

The sliders mean that you will trade performance off against ease-of-development. It will be easier to ship a basic Electron/web-stack app than a native one for multiple platforms. However, it will be harder to do this is in a high-performance and well-integrated way.

I went through all this with Cordova back in the day when trying to build cross-platform mobile apps. I was able to ship apps quickly, but at the expense of quality – it's okay to do this so long as you are aware of the trade-off.

Re: Electron is flash for the desktop (2016)

#336

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…

> Nobody 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 the cost), and also in finding specialist developers who know these dated technologies. Clearly Java never existed. I've been experimenting with Swing lately because Java has a library I'm interested in using. It's a breath of…

> It may not be proper "native" development, but I don't have to deal with hell. It has proper layout management

If you want something that's much closer to proper native, have a look at SWT. It's faster than Swing and actually looks/feels native since it's actually using native widgets. It's really a shame that the poster child application, Eclipse, is so bloated and slow, because people attribute that slowness to SWT when it's really primarily the plugin architecture that's responsible. And I actually find the more spartan developer interface to be more pleasant than Swing, so to me it's win-win. Swing will always have an uncanny valley, SWT has never had that issue, yet still allows you to write for the desktop in only Java.

Re: Electron is flash for the desktop (2016)

#337

Earlier quoted context omitted.

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

seriously. and skype is a grand example of how shitty a native client can be. tired of this argument. if you put in the proper effort, your users won't care or notice.

Is Skype native?

Except for the very old 4.x Linux version - which is native Qt - and comparably old Windows ones, I thought, all of the recent versions are webbrowser wrappers (one sort or another) with some occasional native widgets around that.

Re: Electron is flash for the desktop (2016)

#338
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…

> 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. Almost everything done in Python for data analysis is just a thin wrapper on top of a fast C/C++ library: Numpy, scikit, Pandas, Tensorflow, etc

That's a good point. You can get away with quite a bit of non-performant user code if the majority of the actual code execution is in the "inner bits" and not the user code. The user code ends up being the "driver" and the heavy lifting is all done by code that is able to provide the required performance. It's also a good reason why PHP has been able to become so pervasive.

Re: Electron is flash for the desktop (2016)

#339

People complaining about electron are the same type than the ones that used to say : - why are people writing this stuff in C. It's so slow and you don't have as much control on memory. Write it in Assembly. - why are people writing this stuff in Java. It's so slow and you don't have as much control on memory. Write it in C. - why are people writing this stuff in Python. It's so slow and you don't have as much contro…

> why are people writing this stuff in C. It's so slow and you don't have as much control on memory. Write it in Assembly. did anyone ever actually say this? > why are people writing this stuff in Python. It's so slow and you don't have as much control on memory. Write it in Java. this one is odd to me considering Python came first...

> did anyone ever actually say this?

Wordperfect is famous for failing because they sticked to assembly while the competition moved to C.

> this one is odd to me considering Python came first...

It is indeed. But date of creation has no importance in this. Java became popular first, and is faster and consume less memory than Python. I'm a Python dev now, and I when I picked up the language more than a decade ago, people where looking at me like I was crazy.

Re: Electron is flash for the desktop (2016)

#340

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…

> 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 the cost), and also in finding specialist developers who know these dated technologies.

Come on man, it's a little too easy, but NOBODY? People write desktop apps all the time. What you mean is "nobody I know", which probably says more about your social circle.

Post reply on HN