I can instantly tell, not by the looks or aesthetics, but by the way an Electron app behaves that it's not a native app. It has got that "browser"-like feel to it. VSCode/Slack/etc have a different "feel" to the UI vs. say Mail/Messages/Photos app. Not sure how to describe it. It is just the way it reacts and responds. Does anyone else experience the same?
If there was a A/B test, I am pretty sure I can nail almost 100% of the Electron-based apps. Same thing with MacOS vs Windows apps - Windows is a lot "snappy" and MacOS is very "rounded and smooth" when it comes to the UI feel (not looks).
For those curious about why we describe non-visual things in terms of visual metaphors (sharp, smooth, etc) is because of adjacency of brain structures and cross-wiring between them . It is called the Bouba/Kiki effect, "Bouba" is round shape, and "Kiki" is a sharp shape, in almost every culture and it's universal: https://en.wikipedia.org/wiki/Bouba/kiki_effect
Edit: It feels like it is impossible to talk about opinions without getting shafted by the "Electron lovers/haters" crowd. Wtf. I am not saying one is better than the other. Even if I did, why can't we talk about it if it is substantiated? A lot of this stuff is subjective and experiential.
Edit2: Stop upvoting you people! There is nothing to see here and I don't know anything about the original topic, i.e. 9.0 release. Dump this thread please.
> why can't we talk about it if it is substantiated?
Because we don't need every bit of news about Electron to turn into a thread of people saying, yet again, "I don't like them compared to native apps".
We know already, and it's not relevant to the article. If the article was opinion or research on the differences between Electron and native apps, or suitability of Electron for certain use cases, etc., then your complaint would be relevant.
But your comment is not relevant - it has almost nothing to do with the contents of the article.
This. I almost didn't click to read the comments simply because I knew that it would be the same old religious argument. I hoped I was wrong, but wasn't.
Any half-decent dev is aware that VSCode would be slightly better if it was a native app. Any half-decent dev is also aware that doing so with cross-platform support would be a humongous PITA.
The biggest magnet for this phenomenon on Hacker News is Amazon. Every Amazon article will undoubtedly have at least one comment complaining about counterfeits.
It'll show up everywhere. Apple articles will get something about MacBook keyboards (perhaps a bit less now that they've "fixed" it), Microsoft doing anything with open source will get "EEE", Google will be "Google needs better support", Facebook is "why would you ever use this privacy-violating democracy-destroying nightmare". I haven't even gotten into non-company topics yet.
You're right about the relevancy. Nothing to do with the 9.0 release. I had an itch that I asked and now its blowing up. I can't delete my comment now.
Could you please stop posting unsubstantive and/or flamebait comments to HN? You've been doing it a lot lately, and it's against the site rules: https://news.ycombinator.com/newsguidelines.html.
I think that the problem it's not the "Electron lovers/haters", the problem it's that the post it's above the 9th release, you expect to see discussion regarding the release, not above that non-native apps feels round or sharp, that's matter of preference, and everyone here knows about the resource hungry of Electron
VS Code looks/behaves quite "native" to me...You can have success if you choose Electron. Many projects proved. The tech doesn't seem that important. Now go build something great and people won't unpack it to see if it's electron or native. As always the execution is more important(and the project/idea itself).
Meh - I used IntelliJ IDEA, Visual Studio and Visual Studio Code on a daily basis and VSCode is the most responsive environment by far - both in terms of UI responsiveness and operation speed. Now you can argue it's not as fully featured as the mentioned IDEs but it's obviously not just about native vs electron, and electron can provide a good enough experience.
The performance I'm talking about is stuff like code analysis chugging and stalling the editor so I don't understand how your link is contradicting anything from my post.
Lint/hints taking forever to update after code editing, autocomplete popup takes a second to show, etc. This depends on codebase naturally but in my experience for the cases where VS Code works well (mostly typescript) on the same codebase and same PC it's much more responsive than IDEA tools or Visual Studio (and I'm running this on a i9 MBP with 32GB ram so not a weak HW thing).
I type on a 60hz monitor and I'm not particularly sensitive to that kind of latency (this is where I consider VS Code good enough)
The zero latency sounds cool, but there are other issues with the IDE on OSX. There is issue [1] how the UI is repainted on any interaction with the IDE [2]
I'd agree that Swing feels heavy... but Electron feels an order of magnitude heavier.
Though, when done right, it feels fairly close to native. I earn my pay working with IDEA and if you turn off the plugins you don't need its actually quite snappy where you would reasonably expect it to be. I would bet it takes far less optimization to get there than an equivalent Electron application
Matching native UI with non-native toolkits is extremely difficult. But the success of so many electron apps suggests that in many cases this doesn't matter that much.
I don't know - success of x and some property of x can be orthogonal. It probably is orthogonal in the case of electron apps. The main reason for their popularity is because they are easy to develop in cross-platform way. Doesn't mean that "x property doesn't matter".
I think it’s because the DOM just isn’t as responsive as native components - interacting with anything in a browser or in an electron app has that subtle latency that doesn’t make it feel as good. Seems that this could go away with react native desktop.
The first time I experienced such a feeling was when Visual Studio .NET came out. Compared to the previous version, Visual Studio 6, the dialogs and wizards in VS.NET gave me a "web-like" feeling. I guess it was one of the first attemps to use the web technologies to make a desktop app. Along with the Active Desktop feature, they were truly ahead of time.
However, that doesn't mean I loved them. VS.NET was slow as hell and I believe it was one of the reasons why VS6 lasted for so long.
> but by the way an Electron app behaves that it's not a native app. It has got that "browser"-like feel to it.
Aren't browsers native apps?
Edit: Chrome on windows is just as native an app as MS Word on windows, so that "feel" may have nothing to do with the tech it was built on, but a native vs browser mindset that even blinds you to the fact that all mainstream browsers are actually very native apps, regardless of the "feeling" they give you.
Yup. I'm just shocked that https://github.com/microsoft/vscode/issues/76594#issuecommen... has been open for more than year now. Two finger scroll that lags for up to 1 second! Imagine the uproar if Apple introduced this bug into XCode and then ignored the ticket for an entire year.
I don't know, for example for me VSCode feels 1000x faster than Photoshop, which is a native app. Photoshop takes a long time to open, breaks the "Windows" keyboard shorcut, is basically slow in general. VSCode has a fast start-up time and everything in it feels responsive. I see a lot of comments from Apple users, maybe Electron works better on Windows than on Mac for some reason?
The reason you see a lot of comments from Apple users is because the system has had a consistent paradigm for desktop applications, designed by the party making the operating system, for years, which means that they have come to rely on and become used to such software. The fact that Electron breaks all of those expectations and is a horrendous resource hog to boot is an unwelcome development if you've been used to high-quality native applications for all this time.
Except Apple's design system has taken a backseat in the post-Jobs iPhone cash grab era, and becomes less and less consistent with every release.
And we're saying that people who use Catalina are expecting a gold-standard, performant experience? Do we use the same Catalina? Because it represents a major regression in the macOS line.
Also FWIW, Messages.app is poorly maintained almost certainly next in line to be converted to Catalyst. (Web views are used in other parts of the OS as well; all the "services" panes for example, as well as Safari's web inspector.)
> Didn't Slack rewrite their app to be native and move off of Electron?
What are you talking about? That has never happened.
They posted this blog post [1] on July 22, 2019 and you probably misunderstood their point.
They did not rewrite the application to build on native libraries, they simply redesigned the architecture of their UI logic to draw web components only when strictly necessary, sharing states between workspaces and stuff like that, but it is —as of today May 19, 2020— still 100% a web application running on top of Electron. They recently announced another visual rewrite [2] on March 18, 2020 which also resulted in the same web application running on top of Electron, no changes in that part whatsoever.
You don't like Electron apps? OK, we know. We know because every single time anything about Electron is posted we have the same conversation why native is better, and it gets the same replies articulating the reasons why people still choose to develop with Electron anyway. As best I can tell absolutely nothing has changed in this respect.
Perhaps this thread could discuss the v9.0.0 release of Electron instead?
Posts about incremental releases nearly always turn into generic threads about the project in general. I wrote a long thing about this recently, with the hope of being able to reuse it when the issue inevitably comes up again.
And despite all that, Apple's own apps (like Music.app) have very unintuitive UX easily beat by 3rd party developers. Native apps also are privacy nightmares and don't have uBlock nor a network tab. Let's not rehash this every damn time.
Your complaints aren't relevant either, though: Music.app is terrible because it doesn't follow the guidelines, and Electron apps are no better than native apps from a privacy angle.
> Native apps have UI elements that have tremendous research behind it by operating system vendors with deep pockets
Yeah, and web UI design languages and the frameworks implementing them like Material Design and Fluent UI have neither research nor deep-pockets vendors behind them.
Counterpoint: Google's Material Design framework has tremendous research behind it, and has a variety of both native and web implementations.
The broader point is the one I already made: this isn't new. None of this is. Going over the same points every time there's any post about Electron is pretty tiresome.
The "electron is too slow" problem is really just a mask for the real "electron is eating into our desktop app market" problem. Or to put it another way FUD.
I assure you "Electron is slow" is not FUD. Electron is slow and has been measured to be slow many, many times. Perhaps "Electron is eating into our desktop app market" is a problem, but it is also possible that the real complaint is that "something slow is eating into the desktop app market".
The fact that an app built with electron may be fractions of a second slower than one built using native tech, does not change the fact that most of the people who keep on harping about this whenever electron is discussed are native app developers spreading fear, uncertainty and doubt about a competing tech stack. And it is a big threat because it makes creating desktop apps accessible to millions more developers, and therefore cheaper and faster from a business point of view. So what is essentially an economic problem pretending to be a technical one. I moved from Notepad++ (screaming fast) to VS Code, and those micro-second differences in speed do not matter at all.
...when did I suggest they did? Come on. What I'm saying is that it is not possible to have a conversation about the release of version 9 of Electron on this site. So far the thread has proved me right.
Am I a fan of Electron? Like most people here - I've never built on it.
But I am thankful that it has ushered in a ton of useful apps that do indeed work across 3 different operating systems.
That argument really only makes sense for small companies who can't otherwise afford to develop for multiple platforms. For huge companies like slack or spotify, using electron is a cost-saving measure for them that creates an externality for end users, in the form of greater resource usage.
The only native music streaming app I've tried is Apple Music, which is worse than Spotify, Idagio and Tidal in many ways. It's certainly slower and less responsive. This might be for legacy reasons but if even Apple with limitless resources can't be bothered to build a new native client on their own stack why should we expect companies a small fraction of their size to do it?
I didn't realize the new one was a web wrapper. I guess the point still stands though that even Apple can't be bothered to build a truly native app on their own platform.
One trend I noticed is many large software these days: Office, Adobe Suite, Spotify, Steam, Apple Store/iTunes/etc are all using web technology to build at least, their frontends.
One can't help but think, maybe web stack makes it the easiest to build good looking apps that are responsive
Another factor is that you very likely need some kind of web UI so there's a huge benefit in using web technologies across the board. Once again Apple music is a good example. They had to build a browser-based UI to keep up with the competition and once you've done that there is a strong incentive to reuse it.
The web stack has the most inertia, so its substantial and glaring flaws actually get addressed, whereas other GUI stacks change at a much slower pace (for better or worse).
And yet Slack and Spotify are some of the most used apps. I wonder if most end users just don’t care about resource usage, as long as they can comfortably run all their apps, why should they?
I hate electron apps so much that I only use Spotify on my smartphone. My computer is not old or weak. But when Spotify is open, it feels like this.
Our boss uses Slack. He must be communicating with me through another chat program.
But it's true, he obviously doesn't care about the performance of his computer. Why should he, it's not his job to think about such things.
Perhaps, but making the assumption end users care about resource consumption seems a bit silly. Most of these apps run perfectly fine, sure they use a bit more resources than their native counterpart. But even for a technical person like myself, I barely notice it.
So I’m not sure this arguments outweighs the cost of having to maintain different native apps.
My experience is that as a technical person with a beefy computer, I am mostly frustrated by the knowledge of how much of a waste these apps are, and how much faster they could start/run on my devices.
But a lot of my non-technical friends, many of them with much cheaper computers, definitely grumble about Slack and the like. The difference is much more noticeable on their hardware, and anyone I know who can get away with it prefers to use WhatsApp or, in some cases, Telegram.
Lock-in definitely plays a big role. If you already need to keep Slack open for your employer, you might as well use it for other things, for example.
> My experience is that as a technical person with a beefy computer, I am mostly frustrated by the knowledge of how much of a waste these apps are, and how much faster they could start/run on my devices.
I understand this point, and I definitely agree. But I'm also of the opinion that some of these companies wouldn't be as popular if they tried to build native apps from the start. They wouldn't be able to move so quickly, and would be restrained by money and resources. Of course, once you grow (Slack & Spotify) you should invest in making the experience as painless as possible.
Maybe. I used to assume as much, and as a solo developer I think there's a good chance I would pick a non-native solution when necessary.
However, not only am I starting to doubt this, I think it's even less of an issue for a startup that can afford at least a handful of developers.
First off, the few projects I've done with 'web tech' that had to be native-ish (cordova, so web apps as 'proper' apps on your phone) have made me more skeptical. Sure, at first it was nice to be able to build things using a stack I was mostly familiar with.
But not properly knowing the development and build tools for Android/iOS made me extremely uncomfortable. And if I'd bother mastering those, I might as well go for native.
Having to jump through various hoops to get something that felt as native as possible was difficult too.
And finally so many things were not part of my 'web developer toolset' anyways that I might as well have learned the native approach (notifications, any other integrations with the OS that web doesn't offer or doesn't offer on the major platforms).
I mostly came away from that experience wondering if the main reason why we do these things is a (somewhat) unreasonable fear of learning a new tech stack.
I can totally see the use case for Electron and Cordova and RubyMotion and so on. But for a sufficiently experienced developer it might already be preferable to just learn iOS and/or Android development, and for a company that can afford a handful of developers getting one of each, at first, should be doable.
But again, I could be wrong and it's just a growing feeling. Maybe I'm underestimating the amount of work needed to do native development. I haven't had the time to properly do so yet...
I've done both React Native / Cordova apps, and native iOS apps. To be honest, in terms of development, they both felt the same to me (ignoring language), as in, I was able to build both apps roughly at the same speed. However with one, I also had an Android app with minimal efforts, with the other, I had to start from scratch again.
I agree with you on the tool set tho, I also felt quite uncomfortable not knowing how exactly React Native was doing all the things to make it work for Android / iOS, and sometimes it was extremely difficult to access native functionality.
At the end of the day, I don't know what the correct use case is, I see advantages to both.
I am actually quite annoyed by this specific points, because I am sure users would certainly mind if someone told them that Slack and Spotify were taking two hours off of their battery life, and they'd certainly want something better than that if possible. The developers of Electron apps are largely shielded from outrage by user ignorance, and users blame their computer or themselves instead.
Would they really? Or would it be the same outrage as when people realised Google is selling their data, or when Facebook is monitoring every move they make?
What I'm getting to is; if people wanted something better, something better would've come along already.
Most developers are shielded by user ignorance, if users knew what happens behind the scenes at most banks, they wouldn't want to bank with them anymore. Same goes for almost every software system.
>I wonder if most end users just don’t care about resource usage, as long as they can comfortably run all their apps, why should they?
It's death by a thousand cuts. You're probably not going to switch your MBP from 8GB to 16GB because of spotify/slack alone, but if you have four electron apps using 500MB each, you're missing a quarter of your memory. That may very well push you to get the option 16GB (+$100).
For the user a unified implementation means that you receive across all platforms the same features in the same quality at the same time. Which means a big win for linux and macos. Without electron it usually means there is no app at all, or just some cripled half-assed version which is constantly different and bug-ridden.
Even for big companies it's hard to organize multiple projects to be on the same level, especially if we are talking about some more arcane platforms where you have a hard time to find people with enough experience.
For the ten millionth time: the desktop Spotify client is NOT an Electron app, it's a CEF (Chromium Embedded Framework) app, which is kind of the same, but in the end not the same. Get your facts straight please.
Are there any projects concerning providing an OS bundled electron that apps can use instead of each app having to run its own? It would be nice in reducing the overhead but I don't know if something like that could even be implemented, or that devs would even use it.
People have tried, but the devs don't use it, because when you use an OS-provided WebView, you have to support way more browsers (and substantially older browsers) than you do if you just ship your own browser runtime.
On Windows, if you use an OS WebView, you'll have to support IE11 on Windows 7. On Windows 10, you'll get whatever random version of Edge was installed, or the new Chromium-based Edge.
On macOS, you'll have to support whatever version of Safari was installed on the user's Mac, which is better than IE11, but it could still be years out of date.
You might say, "Who cares? I have to support old browsers on my website, too" but this is way worse, forcing you to support browser versions you rarely see on the web. Windows 7 users typically just install the latest Chrome/Firefox and run that rather than surfing the web in IE11, but when you rely on the OS-bundled browser, all of your Win7 users will be on IE11. Your IE11 support can't be an "acceptable fallback"; it's the only/primary experience.
With Electron, you can ensure that your app will use Chromium; the exact version of Chromium you provided in your installer.
FWIW, Microsoft plans to ship a new "WebView 2" that will let you provide your own Chromium or depend on the latest Edge Chromium, with support all the way back to Windows 7. https://docs.microsoft.com/en-us/microsoft-edge/webview2/
That's cool for Windows, but macOS is still just gonna give you whatever version of Safari the user has installed, and if you want Linux support, you really have no better option than to ship a browser runtime like Electron.
But, at that point, if you've shipped an Electron app for macOS and Linux, maybe you just wanna ship an Electron app for Windows and call it a day?
AFAICT, This has been discussed in the past [0] and Electron doesn't have a stable runtime for developers to program against unlike the JRE, etc. You could try to do that at least on macOS, by moving the Electron.framework library in /Library/Frameworks and see if it will run. Some will, some won't. I won't be surprised if it doesn't work.
The problem is that the Electron API changes rapidly, such that you'd really want to run each app against the Electron release it was developed against, and Electron releases so often that you're not going to actually save any disk space this way -- you'll just have N "system" Electron versions per N apps.
From a developer-perspective this would be a big problem, because you are now depending on an external process outside your control, which in worst case can force you to become active on short notice.
Electron at the moment is just not stable enough for this IMHO. You need to have at least a certainty of that your app would be runnnable for 5-10 years without demand for updates from you, before a developer should seriously consider this.
Though, from a user-perspective this of course is desirable. Thouhg, how big is the overhead even that could be reduced that way?
Actually, I read a rumor somewhere that was planned for Windows 10 as part of UWP, which already supports JS apps.
They've already gone fairly far in integrating PWAs with the new Edgeium, so we'll see where this goes. (Your installed PWAs appear in the control panel for uninstallation, for example, which even Chrome doesn't do yet.)
I wouldn’t be super surprised if this was on the Chromium / Chrome OS roadmap. I might vaguely remember hear something about this a year or two ago in a podcast with a chromium developer, but I could be wrong :P
I would love to have framework de-duplication work this way:
- Each app ships with its own copy of the framework at a particular version. This ensures that apps can be installed offline, just as before.
- When running the app for the first time, the OS moves the framework to a centrally-managed location. The new paths are assigned in a way that both preserves both the version names and prevents collisions of frameworks with the same name but that actually have different contents. For example, a version of Electron could be moved to /Library/SharedFrameworks/Electron/9.0.0-1234abc. This change alone makes it such that two apps using identical versions of a framework can share resources.
- Each time the app runs, it tells the OS which version of the framework it's using. For apps that don't want to do anything fancy, this will simply be the version of the framework it shipped with, and the OS should take this to be the default for legacy apps. The key here is to be conservative -- the default setting should absolutely not cause more points of failure than if we didn't have this system.
- But if apps want to do more deduplication and take advantage of extra features of newer versions of the framework that other apps might have installed on the system, they can do that.
- Note: I think it's preferable to have an API that allows the app to request other versions of the framework, rather having the app specify a static dependency range. You don't know how apps might go about checking whether a newer version of a framework is safe to use. For example, maybe the developer wants the app to potentially check the newer framework version's hash against an online whitelist. This flexible solution allows for that.
- The OS keeps track of the frameworks that the app last used. Once no app has last used a version of a framework, that version can be discarded.
- Caveat: If an app allows the user to switch between multiple versions of a framework for some reason (e.g., LaTEX), it will tell the OS that it is using all of those versions. This will ensure that the version that isn't currently being used doesn't get discarded by the OS.
- Bonus points: Apps can also use an OS-provided API to install new versions of a framework. But the API doesn't allow for explicit removal, since other apps might be using it. This also allows apps that always want to use the latest version of a framework to ship with a much smaller app bundle, and download the framework on first launch. (Chrome could probably benefit from this!)
I wanted to write this out to (1) put together learnings I've gleaned from every previous time I've seen this problem brought up and (2) to point out how complex of a solution it would take to get this right. I think this would be way out of the scope of any framework and would be much better suited to be handled at the OS-level. This "framework-managing framework" could also potentially be a third-party library, but its functionality would probably trip up macOS's app checksumming, since frameworks would be removed from the app bundle.
> Electron 9 stable will target Chromium M83 and be released on May 19, 2020, in response to Chromium's announcement of skipping the M82 stable date and adjusting the M83 stable date.
This is turning out to be a bad decision because there's been 5 major version bumps in the past year, yet the functionality in Electron hasn't materially changed very much, mostly bug fixes and minor changes.
Interested in why you think this was a bad decision. For a multitude of reasons surrounding security, performance and wanting the Latest And Greatest JS features we want to stay as close to upstream Chromium as possible. Curious what you feel the negative impact of major-versioning is?
The Electron version numbers are essentially meaningless now. I have no idea what even changed between Electron 4 and 8, the changelogs are all just bug fixes that didn't necessitate so many major version releases.
Also there are some NPM packages that have to create builds for specific versions of Electron, and those builds come out after Electron does, so I'm always 1 or 2 versions behind on Electron which leads into dependency hell situations.
If you sniff the network traffic you’ll find why: it essentially is a hybrid html and native app. All pages of the App Store are set up in XML and loaded server side, hardly ever cached. Just like <select> in HTML iTunes uses similar structure to instruct and deliver native or semi-native components.
It’s a big web page. And it’s slower than Safari. That’s why.
I remember reading speculation about that as well. After some googling, it appears only speculation that the Music app would be built using Marzipan/Catalyst.
9to5mac writes in a correcting update that “We’ve now learned that the code for the new Music app for macOS will be based on iTunes, not iOS”.
So far I really like using Electron. Granted I am not developing anything extreme but it's really cool, I build my reactjs project then package my electron app and boom it works. Recently tried the transparent/frameless window that was pretty cool.
I have a strong suspicion that this is going to be related to an announcement of some kind from Microsoft tomorrow during Build. I anticipate further definition of their cross platform Blazor/Electron roadmap.
It’s perhaps due to my subconscious dislike of Electron that I read the title as “Electron 0.9” and for a brief moment wondered what a 1.0 release would look like.
On performance, the release notes state that there’s an improvement on Linux (I don’t understand the nuances of that). Are there any contenders to Electron (upcoming or available) that focus on better power consumption and lower memory usage?
If there was a A/B test, I am pretty sure I can nail almost 100% of the Electron-based apps. Same thing with MacOS vs Windows apps - Windows is a lot "snappy" and MacOS is very "rounded and smooth" when it comes to the UI feel (not looks).
For those curious about why we describe non-visual things in terms of visual metaphors (sharp, smooth, etc) is because of adjacency of brain structures and cross-wiring between them . It is called the Bouba/Kiki effect, "Bouba" is round shape, and "Kiki" is a sharp shape, in almost every culture and it's universal: https://en.wikipedia.org/wiki/Bouba/kiki_effect
Edit: It feels like it is impossible to talk about opinions without getting shafted by the "Electron lovers/haters" crowd. Wtf. I am not saying one is better than the other. Even if I did, why can't we talk about it if it is substantiated? A lot of this stuff is subjective and experiential.
Edit2: Stop upvoting you people! There is nothing to see here and I don't know anything about the original topic, i.e. 9.0 release. Dump this thread please.