Hacker News Reader

Comment by StevePerkins | Hacker News Reader

I can definitely see a niche in which Electron serves well.

However, it seems weird that when talking about mobile apps, the PhoneGap/Cardova "web wrapper" concept is derided as awful compared to native code or maybe cross-plat frameworks. From my anecdotal experience, those same people tend to think that Electron or NW.js are the greatest thing since sliced bread.

Electron is PhoneGap for the desktop. That's not necessarily a bad thing or a good thing, it's just a thing that makes sense in certain use cases and not others. The fact that web wrappers have different levels of "street cred" across mobile/desktop contexts feels more subjective than objective.

I suspect it's simply a matter of the younger crowd having more exposure to native mobile development, and little or no experience with native desktop development... so this discrepancy reflects those different comfort levels.

View on HN

> the PhoneGap/Cardova "web wrapper" concept is derided as awful compared to native code

Yes, but mobile and desktop are quite different. For one, desktop has a lot more power - one of the biggest issues with PhoneGap etc. is that it's just slow, and, particularly, single threaded. That doesn't matter so much on desktop.

Also the other complaint is that PhoneGap doesn't use native UI components. Desktop has a huge variety in UI compared to mobile (think Microsoft Word vs Photoshop) - another "not native" format isn't quite as notable.

More importantly, though, is that developers hate PhoneGap and the experience it provides. I'd be interested to see the results of a survey where normal users are given a PhoneGap app and asked to point out what's wrong with it. I suspect many would think it's just fine. Not great, but fine. Similarly, if you asked anyone about the Slack desktop app I suspect they'd say it's fine.

I am genuinely curious, but why would you consider it not as important on a desktop to be fast or easily multi-threaded?

Especially the latter is really puzzling to me.

Desktop processors generally have much higher single threaded performance. Thus apps can more often afford to take a performance hit on desktop than on mobile.

I think that's where we have a different opinion. The performance incurred by Electron applications is larger than I care to afford them, even on my speedy desktop.

Well, the same actually largely holds for me. Low responsiveness is something I despise in applications. However, the general principle obviously stands: if you have more hardware performance you can be more inefficient and still have good responsiveness.

Electron happens to cross the threshold for sensitive users like you and me, but for a large number of users it seems the step in performance from mobile to desktop is enough to buy you the "Electron/PhoneGap/Cordova abstraction" (seeing as how there are popular Electron apps but few for PhoneGap/Cordova).

I'm not saying that being fast doesn't matter on desktop, I'm saying it's a lot easier to be fast because desktop CPUs are faster. I'm not saying that an optimized experience doesn't matter, just that it's less important than it is on mobile.

Ok fair enough, I get what you're saying.

My point is that tools like Electron are actually making it harder to do fast and multi-threaded code on desktop compared to other (native) options. So in that sense Electron's just as "bad" as PhoneGap on a mobile device: it actively hinders developers that want to build decently performing applications.

This even happens with applications that are considered "toy" in this thread like Atom: Performance is really much worse than other editors like Sublime or TextMate.

> My point is that tools like Electron are actually making it harder to do fast and multi-threaded code on desktop

Absolutely. Electron is worse than native, I'd never disagree with that. But I don't think people are looking at Electron and saying "hmm, shall we do Electron or native?", they're saying "oh great, Electron means we can make a capable cross-platform desktop app, something we don't have the time nor budget to do otherwise".

That's true. It's an enabler for some companies, which can only be applauded. I'm not sure I'm too happy with the "worse is better than nothing" mentality I guess, but that's a more general problem :)

Nothing precludes an Electron app from being multithreaded (though WebWorkers, child processes and more) or relying on native components to improve CPU intensive tasks.

If someone is wanting to release a shitty application, they're going to do so irrespective of Electron availability.

I don't use Electron and haven't been following, but isn't Electron a UI only framework?

What I mean is what is preventing you from writing a C/C++ library, installing it down with your Electron UI and having the Electron App call out to the high performance .so?

PhoneGap gets a lot of hate because it's _slow_ and single threaded in an environment that is starved for resources. This can impact user experience even in _just_ a UI context. On a desktop, a single core is many times faster and there are much greater resources so I don't see it as having as large an impact on UI (if any at all noticeable user experience degredations). This is of course provided Electron is (or can be) UI _only_.

Just curious :) since I have never really heard of Electron before this.

While I guess you can do that, most developers using Electron are so familiar with HTML/Javascript/CSS and related web technologies that building a C/C++ module for the bulk of their app might seem only a step above going "full native".

The underlying JS engine is, iirc Node based... you can definitely use/utilize C/C++ modules/packages there... and very little is stopping someone from doing that. There are also child processes (and iirc, web-workers). While a Process !== a thread, on some OSes they are more similar or less in terms of creation cost. RPC/Communication channels are another issue combined with message serialization/deserialization which is the biggest cost to overcome with this type of model.

How does the existence of Electron decrease the ability to use other tools? It only offers another option... Just like .Net/Java do, both of which have disadvantages over C/C++ and the like.

What it comes down to in the end is, is the trade off worth it. With Electron/PhoneGap and the like, you have a much faster path towards an application. Web tooling is broadly understood, and a lot of that logic/workload can and often is already done, and being able to reuse it is helpful... Having a stack that is closer to the rest that you are using anyways means less disconnect.

It's not for everyone, but in the end it doesn't stop anyone from using C++, Go, Java, C#, Python or a number of other languages/tools.

And this isn't just desktops. We're also talking about laptops, and Electron based software completely disregards battery life concerns.

Chrome (technically not Electron but it includes all the same problems) and Spotify gobble down enough power that I make a point of not using them if I'm away from my power cord.

Here I thought the gradual year-over-year percentage increases in battery technology were going to get us better battery life, but it turns out we'd rather just write shittier software.

Why does Chrome use up so much battery?

IRT Battery life concerns - Electron utilizes OS based power management and will auto-sleep the app.

What other battery life concerns do you have that are automatically solved by another framework?

I couldn't tell you precisely why Chrome has comparatively bad battery usage, but it does:

http://blog.getbatterybox.com/which-browser-is-the-most-ener...

Even if you just leave it sitting in the background with one tab open, Chrome uses more power than Safari. I'm currently measuring an "Energy Impact" of 1.9 vs 0.1 for that test.

I don't have any hard data for Electron apps, but my experience is that they're worse than their native counterparts. For example, Spotify (playing offline files) vs iTunes.

The slower your application, the more battery it will consume to do the same task.

A JS+HTML application will be slower than a C++ application that uses the OS's native UI toolkit, and therefore will consume more battery.

Well, he is presuming that the increased performance of a typical desktop makes the performance difference smaller. Considering that Atom performs pretty well even on my five year old desktop, that seems like a reasonable assumption. Although I think this is discounting the fact that the performance difference between desktop and mobile platforms is shrinking every year.

I agree with you with regards to multithreading, though. It seems like that is actually important on both the desktop and mobile for compute intensive tasks.

The red herring in the original comment is that Electron apps can't be multithreaded. They absolutely can be - through web workers, child processes and more. They can also fall back to calling native components for CPU intensive tasks.

Just because Electron is used in a technology stack doesn't automatically mean that the developers are going to be lazy.

Lazy devs be lazy, bro.

Just want to point out that the browser, and electron, and even node.js are multithreaded... it's only the JS engine itself that is a single thread. Asynchronous code and the UI engine itself definitely runs and interacts across threads. Also, there's also WebWorkers (while not great, can work in some cases).

There are also native modules for Electron/Node which can work in background processes.

In the end, for the most part, in most applications, there isn't much logic that actually takes advantage of multiple concurrent threads for logic, and I/O is already multi-threaded.

Does Electron have native UI components? I use Atom/Nuclide daily and it looks like a web app to me (aside from file requesters).

Native for where? You can always use stylesheets to adjust the appearance... you can even have targeted stylesheets for the different platforms. That said, "native" is pretty subjective, as windows has many "native" look/feel over generations... Office 2000 vs the latest or Windows across the same timeline... there's also GTK vs Qt on Linux, and their themes...

Electron is not native, and beyond that, there are too many variables cross platform for anything to look truly native everywhere even for a compiled C++ app without a lot of work. That said, you can definitely style to a platform more appropriately (again, there is work to that).

> I suspect it's simply a matter of the younger crowd having more exposure to native mobile development, and little or no experience with native desktop development...

Precisely this.

Mobile devs care about their artisanal/bespoke/authentic Objective-C or Swift code, while no-one really cares about Qt, GTK or wxWidgets in quite the same way.

There's social cachet to be gained by coming out in favour of native mobile development, while the same is not true for native desktop development.

They're obviously no majority but it's quite common for Mac dev to exhibit much of the same care seen in the mobile dev crowd. Given that all Objective-C developers were Mac devs before they were iOS devs, I'd bet that's where that bit of mobile dev culture has its roots.

I'm not sure that that's entirely fair. I for instance don't dislike Cordova for some philosophical reason, but because I have so far hated every single iOS/Android Cordova app - mostly for performance and polish reasons.

I do enjoy Visual Studio Code, Atom, Slack, and other apps built with Electron. Yes, people also use it to build horrible apps, but Electron has proven that it's capable of powering apps people love. I have yet to see a Cordova app people love.

TL;DR: I love various Electron apps. If I see an amazing Cordova app, I will reconsider my position towards Cordova.

Cordova apps performance is the main reason I dislike it. It's wonderful in principle, but when every Cordova app I try seems to have issues like delay and malformed UI components, I find it difficult to appreciate.

Electron has been the basis for several great applications though, just looking at their website[0] you can see a good number of apps that look and run great. Discord[1] and Gitkraken[2] among them, for starters.

[0]: http://electron.atom.io/

[1]: https://discordapp.com/

[2]: https://www.gitkraken.com/

I wonder if it is a sample size issue here: the number of Electron apps in the wild is currently fewer and the number of well written apps for seems like something of a statistical anomaly. Meanwhile there seem to be a larger overall number of apps written with Cordova/PhoneGap and the ones everyone notices are the ones that are poorly written. I'd wager that the Cordova apps that are well written are mostly invisible, even given how well most people think they recognize "native" widgets in mobile, the gap between HTML5 performance and native performance I think is narrower than a lot of people give it credit.

> given how well most poeple think they recognize "native" widgets in mobile

Every time I've opened a Cordova app I haven't known it was done in Cordova, but immediately thought the app was acting very oddly. Checked the source and yeah, there it is. Cordova.

That's not to say that every Cordova app is bad, I'm sure there some that work well, and if I had a need for any of the example apps in their showcase[0] I would have already tested some. HTML5 performance isn't so much the issue as the implementation of the wrapper. Electron stands as a testimonial to the capability of web technologies as an application platform, it's the history of Cordova applications, even in the last month I have tested an up to date Cordova app, and it just doesn't hold up to the hype. And I'm someone who really wants cross-platform web-based development on mobiles to be great.

Do you think this a bad app given it is one guy trying to target both iOS and Android, and both phone and tablets form factors? http://bland.com

This was already a ton of work. I shudder at the thought of having to have done this with 2 seperate native versions instead. I would have never shipped.

That link sends me to a page that says "Click here to buy Bland.com for your website name!".

How embarrassing... http://blanqd.com

Cool. You might also want to update the link in your profile :)

Ugh. Autocorrect strikes again!

I don't think it's the same people that dislike Cordova and like Electron at the same time. Usually the native-only crowd is against the bloat and performance issues that these wrappers bring in general but of course it is more of a problem on mobile where resources are way more constrained and good UX at the same time is a lot harder to do.

Yes.

The most relevant use case is getting away from different browsers.

You doing your web-app, make it responsive and give people who are like "We want to use IE5" an electron wrapper for the web-page.

Not me, usually such applications don't get to stay around on my hard disk.

Currently I am using Visual Studio Code, because it is one of the best IDE experiences for when I need to play around with Rust.

And being pragmatic, I rather enjoy the productivity of VS Code for Rust than being religious about it and losing the said experience.

I think it's because many web apps wrapped by PhoneGap/Cordova are not optimized for touch and UX expectations on a mobile device. I've seen plenty of these "apps" which didn't even bother to properly deal with the tap delay.

desktop is not so cpu constrained, so perceived performance of electron is "fast enough" but on mobile need native code and APIs to get there.

Reply on news.ycombinator.com