Electron 11.0 released with support for Apple Silicon
electronjs.org
electronjs.org
> In the future, we will release a package that allows you to "merge" your arm64 and x64 apps into a single universal binary, but it's worth noting that this binary would be huge and probably isn't ideal for shipping to users.
It seems like things are going to get a bit confusing with Electron apps, and with the number of Electron apps that exist, this transition might not be as transparent as Apple might have hoped.
Funny, because that's what I've always considered of Electron. I wonder where the breaking point for Electron is?
It's usually more along the lines of product owners preferring features over speed though
Especially if the product owner is the developer itself, as features are way more fun to produce then fighting through some native docs which sometimes don't even work anymore.
It’s also about being a able to ship a v1 product quickly and capture market share quickly. You can optimize speed and memory in future releases. Definitely not the best for the users.
Clearly. But I wonder: If electron didn't exist, would e.g.: Slack or Discord applications be native or wouldn't exist at all. I'm quite convinced that the latter is true.
You say it like it's a bad thing.
I'd also like to live in an alternative universe where all companies can pay more developers to develop native applications for all platforms, unfortunately that is not the case.
Electron has plenty of non-web APIs, plenty of non-web permissions, etc.
You could do exactly the same thing with webkit's APIs.
As a framework, webkit has a stable abi as well which means electron apps would just work with updated system webkit, rather than needing to be rebuilt. Similar for JavaScriptCore vs V8. Unfortunately JSC’s API isn’t nearly complete enough.
So by using electron you've made your life easier, but have produce an app that is much worse for the people actually using it.
It’s perf as a text editor compared to native text editors is abysmal, and if you compare to Xcode you have to include the many processes spawned for basic code support.
VSCode’s idea of a file that is too large to process is smaller than xcode’s which is itself pretty unresponsive for a while when loading files that textmate and other native editors handle without a problem.
Simply being able to run the iOS versions would be great.
It's fast, much faster than the web version. But otherwise pretty bad. I kept being frustrated with it too much and switched back to web.
And Catalyst is supposed to be "more native" than iOS apps running on macOS directly...
Not sure, but I thought i’ve seen a project where it was possible to render natively on deektop as well using react.
The iPad version just lists all accounts and all orgs in the sidebar, no trouble.
> Electron 11.0.0 est disponible ! It includes upgrades to Chromium 87, V8 8.7, and Node.js 12.18.3. We've added support for Apple silicon, and general improvements. Lisez la suite ci-dessous pour plus de détails !
> La team Electron est excitée d'annoncer la sortie de Electron 11.0.0 ! Vous pouvez l'installer avec npm via npm install electron@latest ou le télécharger sur notre site web. The release is packed with upgrades, fixes, and new support for Apple's M1 hardware.
I mean "changement de pile" for "stack changes", really? I had to pause to understand the sentence.
I'd prefer websites to stop pushing half assed translation and just serve English if they don't have the resources to translate properly.
I'd also prefer websites stop deciding to serve me a certain translation based on their often poorly-guessed geolocation rather than my browser language.
The fact that there won't be new x86 Macs in 5 years.
If Apple still made XServe I would agree but here I don't see why they would keep x86 in their lineup.
Microsoft’s balance sheet made little mention of windows phone or anything mobile/Zune/handheld. It was all enterprise sales, windows licensing, Xbox and entertainment division, services and M&A.
Contrast that with the commitment Apple made to the iPhone.
The Microsoft that was worried that ARM was the present/future and Windows needed to be front and center on it, had Windows Phone as a major cross-cutting concern touching every single piece of that balance sheet:
Microsoft made a big play for enterprise licensing of Windows Phone. The last Windows Phone 10 handsets on the market were enterprise sales only devices from vendors such as HP.
Microsoft saw Windows Phone first and foremost as Windows. When Microsoft made that commitment to have Windows 10 running on a billion devices in a short time frame, a lot of their hubris in setting that expectation of so many devices so fast was that they saw a huge growth in ARM devices, especially Windows Phone that never came.
Windows Phone had some of the first attempts at Xbox mobile efforts. The death of a lot of the entertainment division, specifically Microsoft's deeper plays into Music, eBooks, TV/Movies is often directly blamed on the death of Windows Phone leaving Apple too far ahead in pole position on those services.
Windows Phone had big plays from nearly every Service on Microsoft's books. Cortana was built for Windows Phone and the death of Cortana as a front-and-center Services play, too seems to rest on the Windows Phone's shoulder.
Windows Phone was also directly the driver of what most shareholders think to be Microsoft's greatest (ever), most expensive blunder in M&A: the Nokia acquisition.
I think it contrasts directly with the commitment Apple made to the iPhone; had the iPhone failed Apple would have been left with as many scars as Microsoft still seems to have. More than half the Entertainment Division doesn't exist today and Windows Phone is seen as a key reason. The Services team has seen almost exactly as much turnover, again due almost directly to Windows Phone scars. Almost none of the divisions exist in the same form they did today as they did when Windows Phone was the big existential play for the company, the big bet that failed. (If that doesn't show commitment, I don't know what shows commitment.)
It even left scars such that Apple, following in Microsoft's footsteps to ARM on laptop/desktop, years later, seems to get direct credit for things that were Microsoft's efforts. To the very point of the article here and other threads in this discussion, Electron on Apple Silicon would not have happened nearly as fast if it hadn't been for Microsoft's ARM focus/efforts directly forcing Chromium (via the Edge team) to support ARM. (Edge probably wouldn't have switched to Chromium as its renderer if Windows Phone hadn't failed, and if it hadn't needed to spend so much directly in the Chromium codebase in the effort of forcing Chromium to adopt open source ARM builds.)
Apple has made it clear that ARM is, in fact, not a companion product line but the product line. This creates a lot more motivation for developers to do what’s needed to target it because there’s a clear value (for themselves directly or indirectly for their customers).
Commitment. Confidence. Customers.
Apple has committed to Apple Silicon. Flagship products are switching. It isn’t an add-on or side project. That breeds confidence that Apple will stick with it.
That confidence and Apple’s track record make it likely there will be demand for software on Apple Silicon. This is compounded by Apple’s customers tending to be high-income and influential.
Good technical products can be tanked by bad business decisions.
Apple made the leap in architecture before (PPC -> Intel) and while painful, they were successful and showed benefits from the switch.
Apple Silicon does not make any of these tradeoffs. ARM code screams on the M1, and even emulated x86 code runs with comparable performance to the Intel Macbooks. Battery life is better across every workload. To the user, selecting the M1 over the Intel chip is a no-brainer (except for some edge cases like 32GB+ of RAM, where Apple has largely left the older products in place). This is the same playbook that made the PPC -> x86 transition successful as well.
Take Windows for IOT for example: if you read the presentation and the articles you would think it's a viable solution.
I tried to develop a really simple app on it for work. The thing was so slow that I couldn't even make some scrollable text without lag! The same raspberry with Linux is perfectly fine.
If you really want to "understand" Microsoft, just take a look at their UI frameworks: WinForms, WPF, UWP, the javascript one I forgot the name of, and now it's WinUI.
I'm half kidding here, especially when you know that there is a certification about MS certifications (and it's not a joke, the thing is quite complex to the point we don't do this in house).
The UI framework inside of UWP is just another name for first two versions of WinUI. That JS one you forget the name of was a version of WinUI in the early UWP era, that Microsoft stopped supporting because everyone told them the priority was Electron and React Native (and also because their browser team moved out of UWP/WinUI and over to Chromium). (Unless you are thinking of Silverlight, which was "WPF lite".) WPF itself can be considered a Version - 1 of UWP/WinUI, and today with WinUI 3 allowing you to use many of the controls directly in WPF (and WinForms), further blurring the lines between past/present/future versions of the same XAML-based rendering stacks that Microsoft has been trying to get right for many versions now.
It's fun that they never settle on a strong single brand name, of course, but from a technical perspective there's a definite through line (all the way back to Longhorn's "Avalon" dreams and the original invention of XAML).
Unless I misread your question, it is because the M1 is a vastly superior chip not just to the Microsoft ARM efforts, but also to all the Intel efforts.
The translation of x86_64 to aarch64 is key to making this work well.
No, but seriously. The ARM Surface costs $1500, _without a keyboard_, and it's worse than the Intel ones by most metrics. The ARM Macs start at $999 (ignoring the Mini, which has always been a niche product) and come with a keyboard, and they're faster any laptops Apple has released previously, and besides that replace existing popular models. The ARM Macs will shift _far_ more units, probably well over 10x (I don't think MS breaks out figures by unit, but the sales for the whole Surface line are not inspiring).
And besides that, your question gives another clue. Microsoft has actually had two lines of ARM Surfaces; the WinRT-ish ones, and the current ones. With about a five year gap between them. Why bother adding support for something that Microsoft will, based on past performance, probably just kill anyway? Very few shiny new platforms that MS introduces with great fanfare actually survive; see the various incompatible Windows Mobiles, the watch thing, and so on.
The people who build Electron apps are, for the most part, people who wouldn't build an app otherwise.
It’s not a bug, it’s a feature.
There was a little thing called Espresso 2, years ago. It was amazing.
The beautiful X-Ray view for CSS? Incompatible with SCSS.
It didn’t take long to reach the conclusion that my job changed enough that I could no longer use what made Espresso 2 great.
Would that be so terrible? I’m completely fine with having less software, if that means having better software.
> If you don't want Electron apps, don't use them. It's not like they would exist without Electron.
I don’t have a choice. I’m forced to use Teams for work. I need to restart my MacBook after every videocall.
But it doesn't work like that. Why would you suddenly have "better" software?
And thus people start to actually believe that a chat-application must be this bloated. And because of that any competition that actually is developed is also using electron...
And those who actually do care either goes insane or finds another hobby, at least feels that way sometimes.
What is the experience I'm missing?
As a not quite accurate example, think JS vs C++, there's no way you can hammer a bunch of C++ to get something working without not shooting yourself in the foot multiple times, so you have, to a certain extent, to properly develop it from the start. Whereas with JS, you can probably get something working quickly and prove your point. And it's very easy for this shitty JS solution to end up in production because it just works.
You can write very good JS code if you have the engineering culture for understanding it's importance, while with C++ it will be somewhat good from the start because it has to be. I think here is the same thing, for example what has been mentioned here, VSCode vs Slack.
Look at Teams for example. The Electron desktop app is a slow, buggy, resource sucking mess. A video call with one person reduces my laptop battery from 8 hours to 2, fans going at full tilt the entire time. It uses its own notification system that doesn't (or at least didn't) respect the system notification settings. Lots of small things you innately expect to work, like being able to right click a message to edit it, simply do nothing.
Of course, take this with a grain of salt, because I'm generally of the opinion that the DOM is a mediocre target for applications, and that we all put up with it because it's attached to the world's greatest distribution mechanism. So to me, the fact that we'd want to bring all that awkwardness to the desktop and divorce it of its killer feature seems insane.
That’s Windows :D
The hardware on offer currently is just as expensive as the x86 alternatives, has worse performance (unlike M1, which has excellent performance), and only offers marginal battery life benefits.
Microsoft is also not particularly committed to ARM or willing to competently execute that transition. For years they were trying to hobble their offerings (Windows RT, then later Windows 10S). In their first introduction of ARM, they didn't have optimized compilers, so performance was even worse than it should have been (Surface RT was a real disappointment).
Microsoft has also been jerking its development community around for the last 15 years in ways that make targeting Windows unpleasant. Half of Microsoft is trying to tell everyone that UWP is the future, the other half won't even bother supporting it. You might be surprised which half is bigger. The Windows group has spent a lot of time at war with the developer tools group, and it shows.
Basically it all sums up to: Apple is a serious trustworthy partner, Microsoft is not. Apple's ARM offering is actually better in several ways than the x86 alternative; Microsoft's ARM offerings offer noticeably less value. M1 is genuinely exciting, Windows on ARM is not.
The idea before that we'd immediately switch over seemed mad, but based on what I'm seeing there is a good chance that's what's going to happen.
Really, I'm not surprised that people are holding off until they show some sign that they mean it this time.
Correct.
Rosetta is a transitional technology to allow x86 apps to run on M-series Macs while their developers work on Universal versions that will run natively on M-series Macs in addition to Intel ones.
Apple has been clear that they expect the transition to M series chips to take about 2 years… a couple of years after that, they'll stop including Rosetta with macOS and will require developers to ship native apps.
The removal of Rosetta 1 is widely believed to have been rushed because it depended upon licensed technology. Since Rosetta 2 was an in-house design, I wouldn't be surprised at all if Apple kept it around considerably longer.
Turns out this isn't true.
They showed Debian running in a VM on a prototype Apple Silicon Mac hardware in June at WWDC. My guess is that Apple will provide access to enough hardware features of the M1 Macs via their hypervisor framework, to enable alternative operating systems to run ok. Docker for M1 Macs is going to use Apple's hypervisor as well.
Apple supports disabling their security that would allow a different operating system to be installed but there would be no driver support, so there's that.
Is there such a thing?
Honest question, not snark - I've never heard of them doing any. Where/who?
Of course. Who do you think runs the beta program, seeds developers with prerelease hardware so they can port their apps and all the rest?
For a transition like this, you need good products, you need good emulation, and you double-plus-emphasis need to commit. Windows cannot do that.
On issue 2, well the Windows App store has never been an attractive platform. MS tried multiple times to shove it down users throat, which build some antagonism. Moreover, it’s actually MS’ second iteration on this principle (Arm+forced store usage), where the first one failed spectacularly (Windows RT tablets). So, it’s crazy to expect a different results when the same parameters (store locking) are used again, and no sane company or individual would bet on this.
Windows 10 ARM64 laptops went on sale in February 2018, but Microsoft didn't release an official toolchain with ARM64 support (VS 15.9) until November 2018! Even an "early preview" didn't come out until May 2018.
Combine that with the lack of 64-bit Intel emulation support (which is coming out...any day now), and it's clear this is just a hobby for Microsoft. And Qualcomm too, since they have nothing to offer besides phone SoCs that are barely competitive even in phones.
Oh, you want a desktop machine to develop on, or use for CI or tests? Sorry, only laptops.
Also Apple did a fantastic job with early engagement for Apple silicon development, even going as far as to assist with code changes / patches early on.
If you do that and open slack immediately afterwards it feels painful instantly. The difference in how it feels is quite scary.
There is NO "mandatory" electron apps... But there is some great software made with electron that has become very popular.
I am confident if something has been made with electron, there is native alternatives out there. Don't like slack? Then use IRC.
Don't like my joystick to keyboard/mouse remapper with an electron frontend? Then don't, use one of the many alternatives (Too bad if they don't provide what you are looking for and no one of them seems to be able to modulate output in order to emulate analog controls. But at least it was written by a pro!)
I do not use Slack. I use self-hosted Mattermost as a replacement of Slack, I use IRC, and I use Element (formerly known as Riot.im).
That only works if you can control what others use (maybe not in the case of Slack, but that's the exception as messengers go).
What people don't understand is that it's not a "mentality", it's an economic imperative.
It makes sense, business wise, to "throw more hardware at it", and "lowering the barrier to entry" obviously also means that somebody can develop something with lower costs/faster time to market.
It's not a question of spoiled devs.
It's a question of savvy business people.
People not understanding this don't understand how economics works.
Native does basically nothing for me that matters when it comes to accomplishing things. Just OS lock-in. Loading a little faster or being a little snappier is a small consolation.
Some people don’t care about coffee, caffeine and brown slop is good enough.
Some people do care. I feel the difference in native and it’s worth it for apps you spend lots of time in.
Electron and Qt are not in the same league.
No, they're certainly not. Qt takes a lot of effort to produce apps that look like garbage on every OS while Electron takes no effort to produce apps that look great everywhere. VLC Media Player - arguably the most popular Qt app - looks like dog shit.
Qt will have you coding in an old shitty programming language or using duct-tape and glue to bind it to a more popular language while Electron will have you coding in the most popular programming language and getting things done in a fraction of the time.
Qt is register-ware that is moving closer to being closed-source while Electron is 100% open source.
This is why, the devs who settle for Electron more often than not are not interested in doing cross browser support either.
This! The old joke of Eight Megabytes And Constantly Swapping for Emacs is not relevant today any more. Same will happen with Electron, developer productivity will trump anything.
Especially the fact that the “hardware resources” isn’t even your cost it’s your customers cost.
Doesn't it kinda make you think, just a little?
The hubris is frightening.
What I don't get is why they don't want to make a native macOS client, or Windows client. For Linux I get that they don't necessarily know if it should be GTK, QT, should they adopt KDE standards or Gnome, something else maybe? I can see why they would like Electron in that case.
For something like the Mac... They could do a fantastic client, it would use very little memory, play nice with the OS and be fast. Their users would notice and love it.
The file search uses `ripgrep` which is written in Rust. But that is it as far as I know.
I'm not surprised that Slack's memory use tends to explode.
Here's a naive comparison
~/workspace/iOS Project(develop)
time subl .
________________________________________________________
Executed in 75.46 millis fish external
usr time 21.45 millis 106.00 micros 21.34 millis
sys time 14.84 millis 659.00 micros 14.18 millis
~/workspace/iOS Project(develop)
time code .
________________________________________________________
Executed in 4.18 secs fish external
usr time 123.39 millis 99.00 micros 123.29 millis
sys time 175.07 millis 585.00 micros 174.49 millisCloser to IntelliJ than to Sublime, in my experience.
Is there something remotely comparable to VSCode's debugger view on Sublime for instance?
With the C/C++ and CMake Tools extensions installed, VSCode is an IDE that provides pretty much the same features as Xcode (for some features Xcode is ahead, and for others VSCode).
XCode needs about 12 seconds to start into a C/C++ project (on my mid-2014 13"MBP), while VSCode needs 3 (and yes I start into both fairly frequently from the command line). When actually working in the IDEs, for some things XCode feels slicker, for others VSCode. All in all, XCode really isn't a good argument in the whole "Electron vs Native debate" (and the same is true for VSCode vs Visual Studio btw).
VSCode itself doesn't fall over, but code completion and error highlighting are painfully slow to catch up and several of the extensions that provide that functionality regularly crash out.
It LAGS a lot. I work on Xcode Swift projects and the difference is amazing (and Xcode is quite crap). Auto-complete or sometimes just opening a file takes seconds. (I know my project has a bit more complexity that a normal react/node app, but still...)
Yes, but doesn't this also mean that an Apple Silicon-native Electron instantly makes all Electron apps that much faster on that architecture, as opposed to having individual authors update (or not) their apps?
Electron doesn't work on Android either and AFAIK there are no plans to make it work there.
The processor architecture is less of a barrier than the application framework it’s built on (i.e. Cocoa)
(I haven’t used this, but I have used React Native on mobile and web)
So yes, rosetta performance loss on electron apps would be significantly larger than on native x86 apps.
(I'm probably going to find out since I don't plan to ship ARM build of my electron app)
I don't think this will be possible with ARM build - cross compilation probably won't be supported for ARM, I can't run ARM VM on my x86 dev machine, there's the new requirement for mandatory notarization (possible only on mac) ... maybe more but that's enough anyway.
* Your app's performance will be significantly degraded. Electron / V8 uses JIT compilation for JavaScript, and due to how Rosetta works, you will effectively be running JIT twice (once in V8 and once in Rosetta).
* You lose the benefit of new technology in Apple Silicon, such as the increased memory page size.
* Did we mention that the performance will be significantly degraded?
https://www.electronjs.org/blog/apple-silicon#what-about-ros...