To Revive the Mac, Apple Wants to Kill Electron(onezero.medium.com)
onezero.medium.com
To Revive the Mac, Apple Wants to Kill Electron
https://onezero.medium.com/to-revive-the-mac-apple-wants-to-kill-electron-154873336e78
107 comments
> yeah, no. Netflix makes “native” apps for a mind-boggling number of platforms, including set-top boxes and game consoles.
I think all of the STB platforms (at least in the UK) are HTML & JS now. I think they used to be flash.
I think all of the STB platforms (at least in the UK) are HTML & JS now. I think they used to be flash.
He's not plain wrong. Your replies are totally off the mark.
> Most Mac apps are distributed outside of the Mac App Store.
How does that make the author's statement wrong?
> Nobody seems to have really been clamoring for native apps for these…
"Nobody seems". Subjective. Also sounds wrong to me since it goes against my personal experience.
> Yeah, no. Netflix makes “native” apps for a mind-boggling number of platforms, including set-top boxes and game consoles.
How does that make the author's statement wrong?
> No, it doesn’t: have you tried to scroll in one of those apps? That’s right, most of the time you have to drag your cursor across the screen.
Not my experience.
> No, because Slack already has an iPad app.
Irrelevant. How does that make the author's statement wrong?
> Most Mac apps are distributed outside of the Mac App Store.
How does that make the author's statement wrong?
> Nobody seems to have really been clamoring for native apps for these…
"Nobody seems". Subjective. Also sounds wrong to me since it goes against my personal experience.
> Yeah, no. Netflix makes “native” apps for a mind-boggling number of platforms, including set-top boxes and game consoles.
How does that make the author's statement wrong?
> No, it doesn’t: have you tried to scroll in one of those apps? That’s right, most of the time you have to drag your cursor across the screen.
Not my experience.
> No, because Slack already has an iPad app.
Irrelevant. How does that make the author's statement wrong?
> How does that make the author's statement wrong?
The author's point is not relevant: the App Store is not the preferred distribution method for most Mac apps.
> "Nobody seems". Subjective. Also sounds wrong to me since it goes against my personal experience.
Subjective…except you replied with your own subjective opinion? Video streaming apps don't really need a native UI: they don't run constantly, and they don't really need access to platform features. Sure, it's nice to sometimes have them be so, but the real focus tends to be on social media apps and productivity tools.
> How does that make the author's statement wrong?
Because the author claims that Netflix will "keep using Electron", but they won't.
> Not my experience.
I mean, this depends on the apps you're using, but I don't think a lot of them will work well without work put into them to make them adapt to Chrome OS.
> Irrelevant. How does that make the author's statement wrong?
Because they can check a box in Xcode to make a Catalyst app out of their iPad app? It's not as hard as the article is trying to make it seem.
The author's point is not relevant: the App Store is not the preferred distribution method for most Mac apps.
> "Nobody seems". Subjective. Also sounds wrong to me since it goes against my personal experience.
Subjective…except you replied with your own subjective opinion? Video streaming apps don't really need a native UI: they don't run constantly, and they don't really need access to platform features. Sure, it's nice to sometimes have them be so, but the real focus tends to be on social media apps and productivity tools.
> How does that make the author's statement wrong?
Because the author claims that Netflix will "keep using Electron", but they won't.
> Not my experience.
I mean, this depends on the apps you're using, but I don't think a lot of them will work well without work put into them to make them adapt to Chrome OS.
> Irrelevant. How does that make the author's statement wrong?
Because they can check a box in Xcode to make a Catalyst app out of their iPad app? It's not as hard as the article is trying to make it seem.
https://imgur.com/a/gaNGqMQ
49% of the page is non-scrollable on an iPad (811 of 1668 vertical pixels). Unreadable.
49% of the page is non-scrollable on an iPad (811 of 1668 vertical pixels). Unreadable.
Christ, that's horrifying
Isn't there a reading mode? Even Chrome is rolling one out (desktop with reader mode flag set).
Have a look at this HN story from the other day. 2280 vertical pixels and zero article content.
https://i.imgur.com/PO3z3ST.jpg
https://i.imgur.com/PO3z3ST.jpg
Every medium article I go to I turn on reader/distill mode. Much easier than fighting with the website
I use "Reader View" in Firefox and everything smells of roses again.
Didn't know about it. Thanks, it rocks.
> Building them is also an expensive, slow job that requires a team of developers and designers — particularly if they’re building for multiple platforms, like Windows, macOS, and Linux, at the same time.
That is just blatantly wrong. There's cross platform toolkits like Gtk/Qt/Swing/others that I'd say are still easier to build apps with than electron. There's RAD tools like WinForms and VB that let you drag'n'drop most of the UI if you're happy targeting a single platform.
Electron is still not as good as these options were 20 years ago, the only thing it has going for it are a legion of web developers that are seemingly incapable of learning something different.
That is just blatantly wrong. There's cross platform toolkits like Gtk/Qt/Swing/others that I'd say are still easier to build apps with than electron. There's RAD tools like WinForms and VB that let you drag'n'drop most of the UI if you're happy targeting a single platform.
Electron is still not as good as these options were 20 years ago, the only thing it has going for it are a legion of web developers that are seemingly incapable of learning something different.
You have to support web too. Are you going to build app in Qt for web too?
Maybe the answer is Flutter.
What? No, in general you don't.
> There's RAD tools like WinForms and VB that let you drag'n'drop most of the UI if you're happy targeting a single platform.
Even if you want cross-platform native RAD development, there's options like Xojo / REALbasic [1], at least for Windows / Mac / Linux / RaspberryPi development. I'd bet that most of the Xojo developers are single-person coding shops, and certainly don't have big teams of developers & designers behind them.
Electron is definitely not the only option out there. Anecdata, but most of the people I know personally making money from single-developer cross-platform apps are using Qt, not Electron.
[1] https://www.xojo.com/
Even if you want cross-platform native RAD development, there's options like Xojo / REALbasic [1], at least for Windows / Mac / Linux / RaspberryPi development. I'd bet that most of the Xojo developers are single-person coding shops, and certainly don't have big teams of developers & designers behind them.
Electron is definitely not the only option out there. Anecdata, but most of the people I know personally making money from single-developer cross-platform apps are using Qt, not Electron.
[1] https://www.xojo.com/
A mac only framework doesn't sound like an election killer at all considering windows still has a huge user base.
further ignoring mac in favor of an ipad framework that ALSO works on mac along with mac hardware refresh essentially ignoring heat issues(and keyboard issues) leads me to think apple is going to evolve past the mac completely. They just don't want users to use web apps on macs and lose their stranglehold on the app store.
Things like flutter/react are completely going to devour the platform specific space for everything except usecases that require specific hardware(which apple is also losing because they're ignoring scientific/gaming marketshare by cold-shouldering nvidia,ML and AAA game devs in general).
i think apple is trying to "hunker down" until internet speeds improve enough that everyone is using a streaming service for all the hardware intensive stuff and they can continue selling pretty thin clients like ipads/iphones/iARGlasses
Things like flutter/react are completely going to devour the platform specific space for everything except usecases that require specific hardware(which apple is also losing because they're ignoring scientific/gaming marketshare by cold-shouldering nvidia,ML and AAA game devs in general).
i think apple is trying to "hunker down" until internet speeds improve enough that everyone is using a streaming service for all the hardware intensive stuff and they can continue selling pretty thin clients like ipads/iphones/iARGlasses
> Its goal is to make building a native app as easy as building with Electron.
1. Building with Electron is not easy 2. Building native apps is easy (at least was the last time I checked on Windows some decades ago, I guess it's not harder now)
1. Building with Electron is not easy 2. Building native apps is easy (at least was the last time I checked on Windows some decades ago, I guess it's not harder now)
Depends on where you come from. If you're already accustomed to the web stack you'll love Electron. If you come from a .NET background or something similar, you'll prefer native.
It's the easiest way to get all platforms (Windows, Mac, Linux) if you're already comfortable with web dev.
Where do I start if I want to build a native app for Windows, in terms of language, frameworks and UI kits?
Download the Universal app SDK package in Visual Studio 2019(on windows 10 post anniversary update only afaik) and you're off. Language can be c# or js,framework is .net framework and UI is modernized XAML or html/cordova
however the js/html/cordova support is a second class citizen and you'll have an easier time just using c#/XAML
however the js/html/cordova support is a second class citizen and you'll have an easier time just using c#/XAML
Either I, or apple, don't get the benefit of electron.
If I only want to target one OS, I already know better options they electron. What electron gets you is Linux, Windows and mac support with less work than any other platform (in my experience)
If I only want to target one OS, I already know better options they electron. What electron gets you is Linux, Windows and mac support with less work than any other platform (in my experience)
Electron is easier to use/develop on, is cross-platform, uses the most popular APIs/technologies(DOM, CSS, HTML). What not to like?
Huge performance regression compared to native, memory bloat, non-native UI, battery abuse, lack of access to tons of native controls, minimum common denominator UI, and several other things besides...
We cheered for ever more powerful CPUs all those years, then we lamented the end of that period and Moore's law, and now we voluntarily give up tons of power by turning every app into a bloated 3-4 layers abstracted browser+DOM rendering pane.
We cheered for ever more powerful CPUs all those years, then we lamented the end of that period and Moore's law, and now we voluntarily give up tons of power by turning every app into a bloated 3-4 layers abstracted browser+DOM rendering pane.
Yeah but as developer your priority #1 is to deliver ASAP and Electron is great for that. After version 1,2,3 you may start developing native apps but Electron is really great for rapid development/productivity. Performance is/should be your last thing to worry about.
As a developer, your priority should be the utmost satisfaction of your users, not your convenience. The biggest lie one can tell themselves is "After version '1,2,3', I will make a good app". That's not how development works. Once you start something, you are most likely stuck with it. So start well and don't rely on the magic rewrite that will never come.
The question often isn't electron vs native, it's electron vs nothing. In particular, I find electron has been a great source of quality Linux ports, compared to what we used to get.
I don't work on Linux, so that is not a relevant question for me. Also, I often find Electron apps to be way more terrible than their website counterparts, so I just use those. That would still be true on Linux.
The fact that if there’s a bug in the chrome codebase it affects so many apps. For two years this has been the bane of my existence: https://github.com/electron/electron/issues/9413.
When I switched from dual 1440p monitors to dual 4K monitors, all the sudden chrome and every electron app started to just randomly not draw parts of itself. Fixed in chrome ages ago, but electron still hasn’t taken the patch. For awhile if you didn’t have windows scaled up to 4K it was mostly fine, now it does it all the time for me. Spotify, VS Code, etc. are all unusable unless you disable GPU acceleration which makes them run very slow and hog your CPU. And then the memory consumption! VS Code eats more ram than visual studio proper. What’s up with that?
When I switched from dual 1440p monitors to dual 4K monitors, all the sudden chrome and every electron app started to just randomly not draw parts of itself. Fixed in chrome ages ago, but electron still hasn’t taken the patch. For awhile if you didn’t have windows scaled up to 4K it was mostly fine, now it does it all the time for me. Spotify, VS Code, etc. are all unusable unless you disable GPU acceleration which makes them run very slow and hog your CPU. And then the memory consumption! VS Code eats more ram than visual studio proper. What’s up with that?
It's slow, it's bloated, and it is so incredibly memory hungry.
Cross-platform is really so over-rated. The Linux diehards aren't that numerous, and if you're down to just Windows and Mac, there are better options. I personally think it's idiotic to try to reuse the same UI across real computers and phones/tablets, so there goes the other leg of the cross-platform story.
Cross-platform is really so over-rated. The Linux diehards aren't that numerous, and if you're down to just Windows and Mac, there are better options. I personally think it's idiotic to try to reuse the same UI across real computers and phones/tablets, so there goes the other leg of the cross-platform story.
Bloat?
the bloat, the UI look & feel, ...?
I have MS Teams and VS Code, both Electron apps, open and they seem perfectly OK to me - in fact I am surprised by how little memory they use.
That's because Electron has conditioned you to enormous waste of memory, and cpu, bigger latencies, and so on.
The "[surprising] little memory they use" is huge for what they do.
The "[surprising] little memory they use" is huge for what they do.
Well, Teams is using less memory than Skype for Business that I also have running and compared to Visual Studio and multiple browsers windows I have open they are hardly using anything.
Edit: Yes, I think Electron/nodejs are "bloated" too if I look in node_modules - but once I stopped worrying about that I got over the whole "bloated" perception.
Edit: Yes, I think Electron/nodejs are "bloated" too if I look in node_modules - but once I stopped worrying about that I got over the whole "bloated" perception.
Ive never had the experience of teams feeling like it was performing well or felt fast. It's probably the laggiest apps in the Office suite.
You've never experienced Skype for Business, it's awfully slow when doing simple things (resizing the window, opening a new conversation, sending a message, etc.)
oh i have. im not saying skype was better, but parts of its UI were absolutely more responsive.
it wasnt slow scrolling up the conversation to see what someone said 10 minutes ago. try scrolling up a teams conversation to find a recent message.
it wasnt slow scrolling up the conversation to see what someone said 10 minutes ago. try scrolling up a teams conversation to find a recent message.
I have a directory open and edit a 260 line file.
roughly 750MB RAM...
roughly 750MB RAM...
People used to fret about emacs being "Eight Megabytes And Constantly Swapping"
I'm running all this stuff on a beefy desktop - I don't really care if it takes 200MB RAM to open a file as VC Code has lots of features I really like.
I'm running all this stuff on a beefy desktop - I don't really care if it takes 200MB RAM to open a file as VC Code has lots of features I really like.
> People used to fret about emacs being "Eight Megabytes And Constantly Swapping"
People used to edit code on a 1 MIPS 8MB 32BIT DEC VAX 11/780.
With 30 people doing the same, concurrently.
> I'm running all this stuff on a beefy desktop - I don't really care if it takes 200MB RAM to open a file as VC Code has lots of features I really like.
I have a bunch of machines. From ARM boards, ARM-based gadgets, Intel-based ultra-light laptop to a beefy Intel-based desktop.
If a tool runs a text editor editing a small file in 3/4 GB RAM, what will it do if the technology is used to develop some actually demanding things?
People used to edit code on a 1 MIPS 8MB 32BIT DEC VAX 11/780.
With 30 people doing the same, concurrently.
> I'm running all this stuff on a beefy desktop - I don't really care if it takes 200MB RAM to open a file as VC Code has lots of features I really like.
I have a bunch of machines. From ARM boards, ARM-based gadgets, Intel-based ultra-light laptop to a beefy Intel-based desktop.
If a tool runs a text editor editing a small file in 3/4 GB RAM, what will it do if the technology is used to develop some actually demanding things?
That's a narrow view point. You as a developer have a "beefy" desktop. What about your users? Most people in the world don't have "beefy" desktops. These days, 2GB and 4GB machines are still the norm.
I don't expect end users to have VS Code or VS Studio and things are tested in end-user appropriate environments? I don't see what development tools and target environments have to do with each other - 'bloat' in the latter does not necessarily mean bloat in the deliverable?
Edit: I've worked with people in my career who complained about 'bloat' in C (vs assember), C++ (vs C), Unix, Emacs (vs vi), Java (vs C++)
Complaining about the latest round of tools being bloated is just what a subset of the developer community does at any moment in time (and this is not necessarily a bad thing).
Edit: I've worked with people in my career who complained about 'bloat' in C (vs assember), C++ (vs C), Unix, Emacs (vs vi), Java (vs C++)
Complaining about the latest round of tools being bloated is just what a subset of the developer community does at any moment in time (and this is not necessarily a bad thing).
But developers do expect them to run the crapware that they "develop", such as Slack, Spotify, etc., which are often worse than VSCode. Neither should be acceptable.
> I've worked with people in my career who complained about 'bloat' in C (vs assember), C++ (vs C), Unix, Emacs (vs vi), Java (vs C++)
That's a big hyperbole.
> I've worked with people in my career who complained about 'bloat' in C (vs assember), C++ (vs C), Unix, Emacs (vs vi), Java (vs C++)
That's a big hyperbole.
I don't find that VS Code does much out of the box that I couldn't do with Geany or Notepad++. It's all in the plugins for any of these text editors. VS Code is probably the most performant Electron app I've ever seen, but it's floor is about 10x the native apps, because it has a whole damned sand-boxed browser running in it.
[deleted]
Maybe I wouldn’t hate electron as much as I do if they’d get around to fixing https://github.com/electron/electron/issues/9413.
Run dual 4K monitors on a Linux box on both nvidia and AMD GPU and all my electron apps turn into a flickery, randomly not rendering mess. Currently running what I can in Firefox, but VS Code still needs to me on my desktop and is still a mess unless I disable GPU acceleration.
Two years guys, please...
Run dual 4K monitors on a Linux box on both nvidia and AMD GPU and all my electron apps turn into a flickery, randomly not rendering mess. Currently running what I can in Firefox, but VS Code still needs to me on my desktop and is still a mess unless I disable GPU acceleration.
Two years guys, please...
Anyone with experience developing cross-platform native code, what's your take on the state of native cross-platform? Comment on GTK, qt?
Extending this question a bit, a framework I'm curious about is JavaFX. A modern GUI toolkit targeting the JVM sounds like something that could rival Electron, especially if they manage to get installation right (would probably involve embedding the JVM). One would be able to write cross-platform desktop apps in Kotlin or Clojure for example. But I don't see a lot of people using it, or even mentioning it at all...
The JVM is a heavy runtime, though lighter than Chromium. On second thought, apart from the slow startup, I don't really have experience with JVM desktop-side.
I'm wondering if we might see more of JVM on desktops when the new low-latency GC engines become usable.
I'm wondering if we might see more of JVM on desktops when the new low-latency GC engines become usable.
I'm partial to GTK (it's just C and doesn't need a special pre-processor) but Qt does a much better job of looking decent on non-linux computers. There's probably some other options worth considering like libUI and Tk.
As long as you target desktop class apps, Qt is more than enough. For native mobile the offer is weaker (in Qt land, is QML) but possible. For web development Qt is not an option.
Electron can target web/desktop/mobile but the results are far from optimal (RAM, CPU cycles... JS!).
Electron can target web/desktop/mobile but the results are far from optimal (RAM, CPU cycles... JS!).
Qt, wxWidgets, Gtk(mm) - I'll take such framework even if I want to develop for a single platform - the sane APIs and you can always fallback to '#ifdef platform' as needed (rare).
Qt is ok. Not great, but serviceable.
Everything else is worse.
Everything else is worse.
People forget that most apps start off as a dozen lines to solve someone's individual problem.
Qt is nice. GTK is... ok. But to get a cross-platform build with either of them requires a couple of hours' fiddling around. The later you wait to go cross-platform, the more platform-specific assumptions creep into your code and the longer it'll take. But no-one wants to spend that couple of hours fiddling around right at the start of their project, when it's just a dozen lines to fix their own problem.
With electron you write that dozen line helper utility and you're automatically cross-platform from day 1. And not just in the kind of theoretical way you get with say PyQt where your application could be made to build on another platform if you spent a couple of hours fiddling with the build; the alternate-platform binaries are just there. That's powerful.
Qt is nice. GTK is... ok. But to get a cross-platform build with either of them requires a couple of hours' fiddling around. The later you wait to go cross-platform, the more platform-specific assumptions creep into your code and the longer it'll take. But no-one wants to spend that couple of hours fiddling around right at the start of their project, when it's just a dozen lines to fix their own problem.
With electron you write that dozen line helper utility and you're automatically cross-platform from day 1. And not just in the kind of theoretical way you get with say PyQt where your application could be made to build on another platform if you spent a couple of hours fiddling with the build; the alternate-platform binaries are just there. That's powerful.
I'm not a big fan of the Web stack, but I think if for whatever reason I had to write an offline app with a web-ish frontend, I'd write a cross-platform HTTP local-server and use the regular browser. I'm biased towards Electron, because I use underpowered systems and just one modern browser is a big resource hog, but one per application is nuts on a low-power system.
> I'd write a cross-platform HTTP local-server and use the regular browser.
That doesn't actually solve the biggest problem. How do you package up that server? Can you make it something people can run like a regular executable on that platform? How do you distribute it?
That doesn't actually solve the biggest problem. How do you package up that server? Can you make it something people can run like a regular executable on that platform? How do you distribute it?
Right, it doesn't address that at all. Browser's have minimal support for local cross-browser apps.
The fact that you can't easily piggyback on the local browser irks me somewhat. If it's inherently a behemoth, maybe have it be reusable, i.e. piggyback friendly. You wouldn't want a per-app installation of Qt, for example, but even that would be less stressful on the system.
I have a lot of fantasies about how the web stack could be different. I guess that's reflective of some kind of frustration.
The fact that you can't easily piggyback on the local browser irks me somewhat. If it's inherently a behemoth, maybe have it be reusable, i.e. piggyback friendly. You wouldn't want a per-app installation of Qt, for example, but even that would be less stressful on the system.
I have a lot of fantasies about how the web stack could be different. I guess that's reflective of some kind of frustration.
For many apps I'd ask if it really needs to be local. I've had some success with compiling my application to a pile of javascript and then it's possible to go from there to "works offline" functionality, at which point you have a de facto local application that just happens to be opened by putting a particular URL in the browser.
I wasn't aware that that kind of offline web app was possible. I'm surprised there aren't more of them.
My impression was that with an offline capable web app you need CDNs et al to be reachable to load the web app, and then if connection was lost the app could handle it, but if you were to close and reopen the app, it would again need an internet connection to load.
My impression was that with an offline capable web app you need CDNs et al to be reachable to load the web app, and then if connection was lost the app could handle it, but if you were to close and reopen the app, it would again need an internet connection to load.
as Microsoft moves to embed blink into windows, wouldnt it make sense for a stripped down version of Electron that calls the OS libraries, instead of embedding their own. I can see Microsoft moving that way for its apps.
This is a very weak argument. If it was the case catalyst would be windows as well. Then it would actually be very interesting.
Solving the “apple” side of the equasion is no solution at all.
Solving the “apple” side of the equasion is no solution at all.
I don't think this is the right solution. Something like React Native where the core logic is shared but the UI/Views can be tailored to each environment is ideal.
I believe Microsoft released some React Native stuff for desktop and hopefully, there is some work going on for MacOS.
I believe Microsoft released some React Native stuff for desktop and hopefully, there is some work going on for MacOS.
Yea, Microsoft seems to maintain react-native windows and they've officially announced their support.
Doesn't project Catalyst mean that we'd be able to build react-native iOS apps on macOS? :D That would be great, cause with MS support you can build react-native apps on Windows and even Xbox already, just Linux is still out of reach.
This is a very good point that I hadn't thought of, that is, is react-native adds support for it. I imagine Catalyst would make things easier though.
From what I understand (although I didn't do much research) all you have to do is to use a new enough version of Xcode and that's it, so React Native doesn't really have to add any support. Ultimately, you build native apps anyway, all JS things are hidden inside.
I did more research and it seems that they indeed have to add some kind of support.
Comment about Jira is awful. Jira is perfect example. Because it sucks on web, but perfect on mobile. They almost convinced to come back to Jira instead of notion.
[deleted]
But how Apple building Catalyst is going to killing Electron? Electron is cross-platform. So, for many companies, it will be still the first choice unless they are only building for Apple only ecosystem.
You can't expect Apple to not invest on the tooling for its own platform even if cross-platform solutions are great.
You can't expect Apple to not invest on the tooling for its own platform even if cross-platform solutions are great.
I have recently tried to launch our iOS app via catalyst runtime and compare it to an electron app. Memory and CPU usage was only %10% less.
I am not convinced that v8 itself have something wrong with memory usage. Same app without electron will take same amount of memory.
I am not convinced that v8 itself have something wrong with memory usage. Same app without electron will take same amount of memory.
If your iOS software uses as much memory as Electron apps on PC, there is something really wrong with your software, and you should profile it to see where that memory goes.
Project Catalyst has no competition with Electron. It is a smart move from Apple to fill the void in Mac App Store with minimum cost to developers.
I doubt any Electron user will jump the Catalyst wagon. Catalyst is not portable/is Mac only. Electron is easier to use/uses well known APIs/tech stack
It might make sense for any company that already has an iPad app. They can still use Electron for Windows/Linux.
People use electron because it's (1) platform Independent and (2) based on web technologies.
If i want to write apple only code, I code in swift.
If i want to write apple only code, I code in swift.
Do. It.
It's embarrassing when the industry sacrifices speed and quality for the sake of dev convenience.
Even if it appears as a technical article, it's actually fake news one. Technically, the facts contradict the claims from the title and the article.
I flag seldom, but this one really deserves it.
I flag seldom, but this one really deserves it.
The problem is, Macs are too expensive and underpowered these days. More important than developers are users. Right now the Mac is sort of a tax levied on iOS developers
Such a hack of an article...
Is electron currently still the bloated beast it was a few years ago? Has it gotten cleaner and slicker ? How are libraries shared now, if any?
> Is electron currently still the bloated beast it was a few years ago?
yes
yes
Yes it is. Whenever you open a common app whose interface is janky, uses a ton of memory, doesn't load all views as instantly as you expect a desktop app to and needs to frequently refresh itself you know you're using electron. Think slack and spotify, the article doesn't mention it but I'm sure Tidal is too because it behaves in exactly the same way.
I don’t understand how billion dollar companies can’t pony up for a few native app devs lol
The absurd is that lone developers (or small teams) manage to out do in quality apps from large companies. Nowadays, most software by a large company is terrible, even if native. Take a look at Apple's software going downhill, Microsoft software going downhill, etc.
Because it’s much faster and easier to deploy new features when you have one app for three platforms. They’d be crazy to spend resources on native apps for those.
The only program that seems to be doing rather well seems to be Visual Code. It's fast and responsive, and one of the main advantages of it using Electron is that it got a fully cross-platform plugin system almost for free. Given the importance of that application in my daily work, I don't mind it using a few hundred MB ram. I have other critical tools running that consume way more than that.
But that's about the only electron app I really like to use that I use on a daily basis. Many of the other things like slack, discord, spotify, ... are more of a nuisance, and are more 'background' applications for me. Justifying blowing a Gb or 2 of ram on these is hard. I currently already use Franz (also electron) to replace all the "chat" applications, which is tolerable given that it replaces a few things, but still not a huge fan.
But that's about the only electron app I really like to use that I use on a daily basis. Many of the other things like slack, discord, spotify, ... are more of a nuisance, and are more 'background' applications for me. Justifying blowing a Gb or 2 of ram on these is hard. I currently already use Franz (also electron) to replace all the "chat" applications, which is tolerable given that it replaces a few things, but still not a huge fan.
VSCode is bad too. Compare it to Notepad++ or BB Edit, it's no competition. VSCode looks out of place on any platform it runs on, is slow when compared to native editors, takes up a lot of RAM, practically useless when opening large log files, etc. People keep bringing that as a shining example, but it's bad on its own right. It's just less bad than the other Electron "software".
It's snappy compared to IDEs like Visual Studio or IntelliJ IDEA, slow compared to native editors like Sublime Text. I think it's unbeatable as a TypeScript IDE and that's what I use it for most of the time. When I need to open a large file, I use Sublime Text.
medium. paywalled.
nice. someone downvotes me for pointing out a fact.
I'll go further. I'm of the opinion that paywalled articles don't belong here on HN, as it limits the public discourse possible, and as HN should not serve as a funnel for peoples paywalled web sites.
Downvote me for stating this opinion, rather than the factually factual fact I got downvoted for stating.
I was just thinking to revive HN I want to kill Medium.
To revive something, it has to be dead first.
I’m out of the loop - why is medium suddenly out of favor these days
People expected it to be completely free and ad-free forever, for some reason.
> Electron represents something of an existential crisis for Apple. If developers can build with web-based frameworks, they’re less likely to use Apple’s tools, services, and ultimately, its App Store.
Most Mac apps are distributed outside of the Mac App Store.
> To demo such an exciting framework, you’d expect big names like Netflix or Amazon Prime Video, which could theoretically bring off-line video playback to the Mac for the first time
Nobody seems to have really been clamoring for native apps for these…
> developers like Netflix, which need to build for other platforms anyway, will keep using Electron for other apps
Yeah, no. Netflix makes “native” apps for a mind-boggling number of platforms, including set-top boxes and game consoles.
> A better example of this idea can be found in Chromebooks, where Google allows almost any Android app to be used without modification. Want to run Instagram or stream with Spotify’s mobile app? It works as you’d expect, with all of the benefits from the mobile app in tow.
No, it doesn’t: have you tried to scroll in one of those apps? That’s right, most of the time you have to drag your cursor across the screen.
> If you’re a company like Slack, it’s cheaper and easier for you to target every desktop platform with Electron
No, because Slack already has an iPad app.