Electron 11.0 released with support for Apple Silicon(electronjs.org)
electronjs.org
Electron 11.0 released with support for Apple Silicon
https://www.electronjs.org/blog/electron-11-0
223 comments
i don't recall such support when msft was launching arm based laptops. does anyone have insight to why this is so? is it a case of apple developer relations doing an outstanding job engaging with the community?
Electron maintainer here, although we _also_ support arm64 for Windows. Apple silicon support was driven from the beginning as a priority, it was obvious that it was the future of macOS and without direct support you'd be left behind. arm64 on Windows is barely supported by anything, let alone msft itself...
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.
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.
Because developers use Mac, and they’re doing a complete transition. Majority of Windows installations are still on x86.
It's mostly due to the fact that unlike Microsoft, Apple is doing a complete migration to ARM. The developers have to migrate to ARM because they cannot just tell users to buy x86 macs like they could do for windows
This sounds correct to my knowledge, but I can’t help but wonder if there’s a substantive difference between the Microsoft and Apple ARM transitions that’s not obvious to me.
Microsoft's offering on ARM is underwhelming to say the least. Or overwhelmingly bad, depending on your perspective.
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 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 difference in execution is palpable, like comparing an A student to a C-/D+ slacker. I suspect MS exec politics is the problem however, not their engineers.
I’d argue that it’s an culture problem. A complete architectural transition is fundamentally at odds with what MS stands for wrt a very long term backwards compatibility. This means that their ARM -> X86 translation should not just match Rosetta but actually exceed it by a large margin to maintain their compatibility.
Apple also already has had widely used ARM64 tooling since the iPhone 5S. Microsoft’s has only been used by people targeting Windows Phone & their half-hearted ARM laptops.
One more thing is that the Apple chips actually optimized for the mac and perform better or equivalent to their Intel counterparts. Microsoft just used the Snapdragon mobile chips that had bad performance even in their own categories, forget desktops
Microsoft has a tradition of backwards compatibility. It's entirely likely that ten years from now, you'll still be able to run x86 apps on your arm windows laptop. This is unlikely to be true for MacOSX - ten years ago, Macs ran PowerPC, and support for that got dropped within 2 years.
Yup, imagine a world where a Tesla would be so backwards-compatible you could shove coal into its furnace to power a steam turbine that charges its batteries to drive its motors.
That’s Windows :D
That’s Windows :D
From my perspective as I weigh up whether to stop buying my staff x86 Macs and get them these new M1s, it's this rosetta layer that really appeals to me. From what I can tell so far not only are they going to be able to run any software that isn't updated for apple silicon, which a lot seems to be, they're going to be able to run it just as fast as before.
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.
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.
Microsoft isn't, as far as anyone can see, transitioning to ARM. They've released one rather slow, very expensive device, plus an incremental update. And this has all happened before; they did the same in 2013 and then quietly killed it!
Really, I'm not surprised that people are holding off until they show some sign that they mean it this time.
Really, I'm not surprised that people are holding off until they show some sign that they mean it this time.
but the M1 can run x86 apps via rosseta 2.
https://en.wikipedia.org/wiki/Rosetta_(software)
https://en.wikipedia.org/wiki/Rosetta_(software)
Judging from history, that support will go away in a few years, like it did with PowerPC Rosetta after the switch to Intel.
Judging from history, that support will go away in a few years, like it did with PowerPC Rosetta after the switch to Intel.
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.
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.
On the other hand, Apple supported 68k emulation for roughly 13 years, from the introduction of PowerPC Macs in 1994 to the removal of Classic mode in 2007 (after the Intel transition had already begun).
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.
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.
[deleted]
I think the significant advent is the M1 chip itself. I was never interested in Win10 ARM edition until the prospect of running it on an M1 Mac. Unfortunately it looks like Apple have taken this opportunity to drop support for alternative OSes entirely.
Unfortunately it looks like Apple have taken this opportunity to drop support for alternative OSes entirely.
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.
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.
[deleted]
bootcamp is explicitly not supported on m1 macs - VMs and hypervisors are beside the point.
[1] https://discussions.apple.com/thread/252021896
[1] https://discussions.apple.com/thread/252021896
Turns out Microsoft could have Windows running on M1 Macs if it wanted to: "Craig Federighi: Native Windows on M1 Macs is 'Really up to Microsoft'": https://www.macrumors.com/2020/11/20/craig-federighi-on-wind...
Interesting. I was under the impression that M1 Macs had the OS completely locked down: http://www.rahulgaitonde.org/blog/2020/11/13/apple-m1-and-th...
Isn't windows for arm restricted to OEM on Microsoft's side?
> apple developer relations
Is there such a thing?
Honest question, not snark - I've never heard of them doing any. Where/who?
Is there such a thing?
Honest question, not snark - I've never heard of them doing any. Where/who?
Is there such a thing?
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?
https://developer.apple.com/support/
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?
https://developer.apple.com/support/
Does WWDC count? Does selling a ludicrous number of devices to consumers which create a humongous market for developers count?
[deleted]
Nobody wanted Arm-based Windows devices. The early RT devices had terrible performance and failed to compete in any meaningful way, had terrible compatibility and no (?) emulation, and since the products were mostly terrible, Microsoft never supported them well, nor pushed for a developer transition, and consequently they got abandoned quickly. The few newer devices out there, like the Surface Pro X, still don't perform competitively, cost way too much for what they are, often aren't straightforward, standard laptops, have emulation issues, and have Intel alternatives.
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.
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.
Oddly enough I think it might be possible now that Apple has shown the way. They'll need a good chip though.
The ARM machines launched by MS were (1) lacking in power and (2) tied to the Windows Store as a distribution mechanism. Issue 1 is not affected M1 machine, in fact they’re blowing current machine, which is in itself a reason for adopting.
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.
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.
64-bit Arm Windows devices are not tied to the Microsoft Store. Secure Boot can be turned off too.
Its also been 5-6 years since. Arm support in the toolchains and libs are much better, and the chips are powerful enough to do testing on them.
Microsoft isn’t deprecating Intel support; Apple will. That alone is cause enough to port apps, but there’s also Apple’s history of warning users about end of life for their apps using OS dialogs that shame the apps that refuse to comply with ecosystem advancement.
To Microsoft, ARM64 is a hobby.
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.
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.
Heck, Microsoft themselves didn't release a native VSCode for those machines until May... 2020. https://twitter.com/joaomoreno/status/1266005299661545474
I hope the new M1 Macs stay cool to the touch when running electron apps still. They should now that this runs natively.
Why would Electron run anymore or less natively with this change?
Without this (assuming Rosetta 2 support was ironed out), the code generated by JITing JavaScript would also need to go through translation from x86 to ARM64.
I’m guessing Electron apps worked without explicit support via Rosetta 2, but with explicit support the performance should be better. And - speculating - I’d guess that there’s quite a lot of code in Electron apps that isn’t AOTed by Rosetta, and that it would have more performance implications there than a native x86 Mac App would just because it has a lot of ongoing transpilation to do. With this change they can cut out Rosetta 2, and run direct on ARM.
The problem is that Electron is essentially 2 big VMs - you can AOT the VM code, but not the code VMs produce.
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)
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)
Out of interest how come you don't plan to ship an ARM build? I naively didn't really realise there were any tradeoffs for the developer here.
I'm not a mac user so I don't own one. Currently I cross compile Mac (and Windows) build on a linux machine and from time to time test those builds in a VM (not sure about the legality).
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.
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.
Rosetta 2 is Apple's latest iteration of their Rosetta technology, which allows you to run x64 Intel applications on their new arm64 Apple Silicon hardware. Although we believe that x64 Electron apps will run under Rosetta 2, there are some important things to note (and reasons why you should ship a native arm64 binary).
* 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...
* 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...
Not having to run via Rosetta. Aka natively like the announcement implies.
Couldn't the new Macs run React Native ... natively, by the way of Xcode, instead of running React inside an electron housing?
Yes, but so could x86 Macs: https://github.com/microsoft/react-native-macos
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)
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)
Using Catalyst is another option: https://github.com/react-native-community/discussions-and-pr...
From their blog post about Apple Silicon[1]
> 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.
[1] https://www.electronjs.org/blog/apple-silicon
> 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.
[1] https://www.electronjs.org/blog/apple-silicon
how much of storage on macs is actually used up by code though?
>it's worth noting that this binary would be huge and probably isn't ideal for shipping to users
Funny, because that's what I've always considered of Electron. I wonder where the breaking point for Electron is?
Funny, because that's what I've always considered of Electron. I wonder where the breaking point for Electron is?
Given that a run of the mill game weights north of 50 gigs, I don't think an additional 100 or so megs per app would be noticeable.
It's a difference if I have a 50GB game with high res textures or a simple app with 100MB which as a native app would only need less than 1MB.
Web technologies are more and more about developer convenience instead of user convenience.
Feel free not to use them then.
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 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 usually more along the lines of product owners preferring features over speed though
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.
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.
> Web technologies are more and more about developer convenience instead of user convenience.
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.
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.
>Slack or Discord applications [..] wouldn't exist at all
You say it like it's a bad thing.
You say it like it's a bad thing.
Nobody is forced to use them, if you like having the chat in a browser fine, more power to you. People who prefer clients can install those, also good.
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.
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.
Chat applications existed long before Electron.
That wasn't my point, just examples. Chat apps did exist but Slack, Discord, VS Code, Obsidian, GitKraken and so on and so forth did not. Personally I prefer a native app. But I'd rather have an electron app with real notifications, dock icon, and isolation over a browser tab.
It seems to me that having a dozen redundant copies of the same core libraries isn’t the best design, and doubling that may be the breaking point where they consider separating the runtime from the app. I mean, I’d prefer more native apps but it seems like that ship has sailed for a lot of desktop use cases, but at least it could be made more efficient.
That's what your platform gets when its web engine refuses to be fully compatible with others, especially the major one.
I’m not sure I follow. There’s no reason Electron can’t use the platform’s ample facilities for shared libraries, and distribute one copy per Electron version rather than per app product. It would possibly be a slightly different startup experience (eg download the components on app launch; even that I think could be solved by detecting their presence with URL protocols, a fairly common practice, to determine which bundle to download).
I'm not sure how that applies to electron beyond electron bundling an entire copy of chrome in every app.
Electron has plenty of non-web APIs, plenty of non-web permissions, etc.
You could do exactly the same thing with webkit's APIs.
Electron has plenty of non-web APIs, plenty of non-web permissions, etc.
You could do exactly the same thing with webkit's APIs.
The comment I replied to wasn't about bundling webkit instead, it was dynamic linking of what's available in the system. That's not possible because each web engine behaves differently, even if somebody reimplemented the non-web apis as a portable native library (actually, these ARE implemented like that). We're bundling whole chrome because it's a reliable abstraction that works the same on all systems.
Your complaint was about WebKit’s “refusal” to implement standards, where standards generally is whatever chrome announces and then throws onto the web with little to no thought about how the impacts users or user privacy.
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.
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.
Sure, and then you run your app and find out that the app displays differently in each engine, so not only you need portable system lib, now you also need portable UI code. That's what we avoid with bundling the web engine.
Yes, what you also get is terrible battery life, terrible performance, and terrible UI. It is immediately obvious any time you use an electron app on osx because you immediately hit non-standard UI behavior, and basic errors with hotkeys.
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.
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.
VSCode is Electron app, running nonstop on my Macbook, it's very fast and doesn't seem to be much more (or at all) power hungry than Xcode. Thanks to Electron it works everywhere and is the same on all platforms, that's a feature.
The first time I used vscode it was obvious that it wasn’t a native app. Basic things like the search hot keys were broken.
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.
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.
electron apps work on the M1 Macs under rosetta. The problem appears to be purely that electron apps are incredibly bloated and this merely makes that more obvious, and they want to shift blame away from their runtime.
I hope applications like Teams, Discord, and others that have iOS / iPadOS apps allow users to use those rather than electron versions.
I hope so too. I tried their Electron apps and they start on Apple Silicon but no window ever opens.
Simply being able to run the iOS versions would be great.
Simply being able to run the iOS versions would be great.
I tried to use the JIRA "Catalyst" app (what is JIRA app in the Mac App store) and... it's bad.
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...
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...
I think Catalyst is basically positioned as a stopgap for iOS developers to get something running on macOS, you can optimise it from there and later split out some code for a specific macOS target.
There is also an additional challenge for apps like Jira or GitHub where the iOS app lags behind the web app in functionality.
Yes, and this was my experience with the JIRA Catalyst app too. It's harder to implement new features in native apps, and it's a lower priority (on desktop) because it only affects one platform. So the project is deprioritized and never gets any updates.
Afaik, Discord on iOS is also written in react but with a native renderer (react-native) instead of the web/desktop that uses react-dom.
Not sure, but I thought i’ve seen a project where it was possible to render natively on deektop as well using react.
Not sure, but I thought i’ve seen a project where it was possible to render natively on deektop as well using react.
I believe React native is already there for windows 10, not sure how mature it is however.
It's both rather mature and completely immature to my understanding. There's a C#-based React Native codebase that's been mature for a while but practically no one uses today unless they have to. There's a brand spanking new, mostly finished C++/WinRT codebase that Microsoft took on building themselves (from scratch). It still has the Beta tag on it the last I checked, many C#-era plugins need extensive rewrites to support it, and it doesn't look like Facebook and the React Native core teams entirely trust it just yet for production development. (On the other hand, it looks like the implication is that the Office team has been dogfooding it from day one, it's roadmap is driven by whatever the Office team needs to ship to production today, and if there is a confidence bar for Microsoft dev tools "the Office team depends on it" has always been an interesting maturity bar.)
The iPad version of Teams is so much better than the Electron version. If you're a member of Teams across multiple organisations or, god forbid, multiple accounts, the Electron version is basically useless. You only get notifications from the org you're actively using, and you can't switch accounts without completely signing out of one and into the other.
The iPad version just lists all accounts and all orgs in the sidebar, no trouble.
The iPad version just lists all accounts and all orgs in the sidebar, no trouble.
I hate Teams with a burning passion. It’s 2020, there’s no excuse for a 2-second lag when I click a button.
Same on android. Teams is one of the slowest electron apps I've ever used
Wondering if we see a few less major electron apps on Apple silicon as companies can share their swift codebases a few different ways.
What M1 giveth, Electron taketh away. Sigh.
If only the issue was limited to Electron... I often feel like Electron is more a declaration of defeat, like: hey no matter where you look at, software bloat keeps eating the precious advances in power provided by hardware. So let's at least get some comfort and value out of that. (Electron does put multiplatform desktop development within reach of 100x more developers than Qt/etc)
I installed windows NT in a virtual machine for kicks a few months back. Then installed office 97 on it.
If you do that and open slack immediately afterwards it feels painful instantly. The difference in how it feels is quite scary.
If you do that and open slack immediately afterwards it feels painful instantly. The difference in how it feels is quite scary.
Partly we can thank this to the "throw more hardware at it" mentality and "lowering the barrier to entry" where noobs create the stuff a lot of us use. People can say all they want that it is good to lower the barrier entry, but that comes with a price. The price that others have to pay when we use their crapware. As long as it is not mandatory though, it is fine, but when it becomes mandatory, it becomes an issue.
>Partly we can thank this to the "throw more hardware at it" mentality and "lowering the barrier to entry" where noobs create the stuff a lot of us use.
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.
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.
Its your choice to use others "crapware". The price it comes with is all the abuse "noobs" have to take for offering their solutions for free. You don't like HTML frontends, thats sweet, then make your own alternative with Qt or winforms.
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!)
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 mentioned in my last sentence that as long as it is not mandatory, it is OK, but there are cases where it is mandatory, e.g. at the workplace.
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).
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).
Well, you will never get around being forced to use something in your workplace. I would never use Cisco VPNs but I had to install their shitty client in every workplace I ever been on.
> I am confident if something has been made with electron, there is native alternatives out there. Don't like slack? Then use IRC.
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).
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).
As someone who switches between Windows and macOS, I'd rather every app I use be Electron and available on both OS than native and only available on one.
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.
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.
As much as the community like to complain about it, I find that the popularity of Electron has been a real saver for Linux on the desktop. It finally has all the major applications available, often officially supported. Yes it's slow, but at least it's there.
Wel native is important for me.
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.
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.
> 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.
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.
" (Electron does put multiplatform desktop development within reach of 100x more developers than Qt/etc)"
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.
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.
s/productivity/laziness/
I think it just comes down to economics. For the cost of a developer day-rate you can buy extremely powerful hardware. So which resource do you want to conserve - your developer time or your hardware resources?
Especially the fact that the “hardware resources” isn’t even your cost it’s your customers cost.
Especially the fact that the “hardware resources” isn’t even your cost it’s your customers cost.
I'm excited about Tauri: https://github.com/tauri-apps/tauri
There are tons of supposedly lighter weight electron alternatives. Why are they not more popular?
>Tauri apps currently leverages Cocoa/WebKit on macOS, gtk-webkit2 on Linux and MSHTML (IE10/11) or Webkit via Edge on Windows
This is why, the devs who settle for Electron more often than not are not interested in doing cross browser support either.
This is why, the devs who settle for Electron more often than not are not interested in doing cross browser support either.
Corporate backed marketing and geographically centralized mindshare.
Hang on, I use Visual Studio Code daily and it’s really fast? Certainly compared to XCode or Jet Brains IDEs.
Apples to oranges comparison. VS Code is a text editor whereas Xcode and Jetbrains are IDEs. The real comparison should be with Sublime Text vs VS Code. Sublime Text blows VSCode out of water while opening the same project folder.
Here's a naive comparison
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 millisThat's not a fair comparison either. VSCode does way more than Sublime Text. I actually found VSCode closer to Intellij than to Sublime Text.
How is VSCode anything similar to IntelliJ other than they both can edit text and has plugins?
VSCode language plugins allow you to get autocomplete, go to definition, refactor support, debugging tools, etc.
Closer to IntelliJ than to Sublime, in my experience.
Closer to IntelliJ than to Sublime, in my experience.
But such plugins exist for Sublime, too. Especially since the Language Server Protocol has been implemented.
Plugins on VSCode are a whole order of magnitude better than on Sublime, mainly because Sublime's Python API is not great.
Is there something remotely comparable to VSCode's debugger view on Sublime for instance?
Is there something remotely comparable to VSCode's debugger view on Sublime for instance?
I cannot tell if this comment is sarcasm or not.
Which features of IntelliJ is VSCode lacking?
IntelliJ is very slow so that's no surprise.
It's not really and apples to oranges comparison.
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).
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).
That's something I wonder too. What VS Code does right that, let's say Slack, fails on?
Slack allows my colleagues to chock it full of multi-megabyte animated gifs and cat images, but VSCode so far doesn't.
I'm not surprised that Slack's memory use tends to explode.
I'm not surprised that Slack's memory use tends to explode.
Yeah I've also tried to understand this. Tried looking for blog posts on what VS Code is doing but couldn't find one. Can someone point out if there's any?
One thing is that they rely on DOM reflow - the automatic, dynamic sizing of elements - as little as possible: nearly everything in the VSCode UI has a fixed size and position. Reflow is arguably the most costly feature of the web when it comes to dynamic apps (though also one of its most valuable features).
Delay loading everything until needed
Parts are written in C/++ no?
Nope.
The file search uses `ripgrep` which is written in Rust. But that is it as far as I know.
The file search uses `ripgrep` which is written in Rust. But that is it as far as I know.
Slack is a messy one page app developed by PHP programmers and vscode is open source and actually made by competent people.
Slack is really weird. It seems like they would have the resources to do native applications. I can't fault anyone for doing an Electron app as a demo, prototype, MVP, that's seems completely reasonable.
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.
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.
They have to build and maintain the web version regardless. Why also write individual clients for Windows, Mac and Linux when they can simply wrap the website in a thin desktop wrapper and call it a day?
Maybe it's easy to sell the "One codebase on all platform" idea to the managers and hard to justify the need for high quality app? People are using it anyway.
And I suppose Facebook is therefore also developed by incompetent PHP programmers despite being one of the largest technology companies in the world?
Yes. I am not even joking. Facebook was so terrible that they had to literally reinvent their wheels (hiphop). Its not hard to become a large company when you have black budget backing as confirmed by Snowden.
Your own sentence argues against itself: the team that built HHVM certainly are not "terrible PHP developers"...
You don't think its strange that facebook hired PHP programmers to create the product and then have to hire competent people to fix that shit as far removed from company logic as possible?
Doesn't it kinda make you think, just a little?
Doesn't it kinda make you think, just a little?
I hope you are joking. Those people you call incompetent built arguably the best web application in the world propelling itself into a global corporate juggernaut and that qualifies as built by incompetent people?
The hubris is frightening.
The hubris is frightening.
Visual Studio Code is fast on startup and that's it. It chokes on million LOC project while Eclipse and Intellij work fine.
I use it daily on multi-million LOC projects and it's just fine...
Out of interest, what language are your projects written in? I've had to work on C# .NET codebases of that size and have had the same issues as the previous response.
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.
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.
Python — sad to hear that the C# tooling isn't great on large codebases though :(
I work in multi-thousand LOC projects in TS in vscode. It lags.
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...)
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...)
Add some extensions to VSCode to get the same functionality you have in JetBrains, and open a workspace with dozens of repos. I'll wait while you reboot because you went OoM (I'm only being half obtuse here).
Indeed, can’t decide if I’m happy or sad to see this news.
The alternative is Rosetta mode. It's not like Slack is going to write a native app all of a sudden.
But you can use the iOS Slack app, which is native!
Maybe iOS Slack is available on M1? It is native.
Maybe use an alternative that is native?
[deleted]
While electron isn't exactly slow, you just said electron is now fast enough for you.
>What M1 giveth, Electron taketh away. Sigh.
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?
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?
Mostly I would just want Electron to disappear overnight.
I'm both sad and confused about why there are so many negative comments about Electron, when I happily use Electron apps every day of my life and have no complaints at all about them. In fact, I'd like to start building Electron apps of my own, it actually looks like a ton of fun!
What is the experience I'm missing?
What is the experience I'm missing?
I think any technology where you can get something done quickly, and blurs the line between production and prototyping, gets a bad reputation because a lot of people misuse it. Essentially, I think you need to be able to have a strong engineering culture that takes the time to actually optimize things as the scale/scope changes.
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.
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.
It is certainly possible to make high quality, well behaved software with Electron (VS Code is great), but it takes a hell of a lot of work, and seems to be the exception rather than the rule.
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.
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.
I love comments like this. Ideas that I've had for a long time articulated in a way I never could.
Maybe they use computers from 10+ years ago, otherwise the complaint is weird.
Compare an electron app to a well written desktop app There is a
difference in responsiveness.
And installing a new browser instance for every app is a waste of disk space.
If you don't want Electron apps, don't use them. It's not like they would exist without Electron.
The people who build Electron apps are, for the most part, people who wouldn't build an app otherwise.
The people who build Electron apps are, for the most part, people who wouldn't build an app otherwise.
> The people who build Electron apps are, for the most part, people who wouldn't build an app otherwise.
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.
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.
> I’m completely fine with having less software, if that means having better software.
But it doesn't work like that. Why would you suddenly have "better" software?
But it doesn't work like that. Why would you suddenly have "better" software?
The need for software doesn't go away, but bad programmers cannot fill it anymore. So the software is made by competent programmers instead.
I need to use zoom now but would rather not install it. I put it on an old tablet and every one is happy.
Say what you want about Zoom, but performance-wise their app is absolutely amazing compared to Teams. I’m sure that the fact they choose to develop native apps instead of Electron crap has a lot to do with their success.
That would have been fine if one had a choice. If the rest of the team uses slack then well, you are also using slack.
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.
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.
> 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.
It’s not a bug, it’s a feature.
Remember to stop using VSCode, since it's based on Electron
I did, moved to Nova.
Enjoy your amazing but unsupported piece of software.
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.
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.
I guess e.g. MS Teams would exist, but in general I agree with you
No one who uses Slack chose to use Slack.
So ignore they exist & live the future you want. Any resurgence in Desktop Apps was because of Electron, many of which would not have been created otherwise.
Can confirm. Without electron my app would stay web app forever, without e.g. offline capabilities ...
Well, there is some chance you can just run iOS/iPadOS forms of the apps (e.g, Slack) rather than Electron apps on M1. 's not as bleak.
I'm glad that you and your cohort are not more than a very tiny minority.
I am really curious why the response to Apple Silicon is so prompt vs when Microsoft did WinRT or ARM versions nobody really cared. What is the difference? Was there some problem in compilation tool-chain or what?
> Microsoft did WinRT or ARM versions nobody really cared. What is the difference?
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.
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.
I'd also add history to that list.
Apple made the leap in architecture before (PPC -> Intel) and while painful, they were successful and showed benefits from the switch.
Apple made the leap in architecture before (PPC -> Intel) and while painful, they were successful and showed benefits from the switch.
All of the reasons you said are correct, but I want to point out that Windows on ARM is also a bad technical product. The Qualcomm SoCs in devices like the Surface Pro X are more efficient than Intel chips, but they are much slower for everyday tasks even on native ARM-compiled code. Emulated x86 code is even worse, as the slow cores are further held back by Microsoft's emulator implementation. Users may like better battery life, but they also despise waiting for their computer.
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.
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.
I think it also must help that a lot of these developers already have a bunch of ARM code running on iOS, so along with Catalyst and I’m sure shared libraries between their existing iOS/Mac apps it was probably easier to get builds out than it could have been.
MS only half-sold their ARM version. It was a clear second-tier product and that x86/x64 was where their heart and customers were.
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).
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).
Because MS always do half the job and call it done (I'm a C# dev btw).
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.
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.
> 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.
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).
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).
Man, what is it with Microsoft and acronyms?
It's so that you need to pay an expensive consultant with the right certifications to explain you all of that ;)
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).
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).
M1 is the clear future for macOS, whilst WinRT/ARM was a non-committal side-hussle that may or may not have a niche future.
Side hustle is spot on. They didn’t fully commit because they were afraid to cannibalize x86 market support. Unlike Microsoft, Apple made the chip. Microsoft only worked with 3rd parties and nobody would touch Intel/AMD. Well, until now...
It wasn't a side hustle when Microsoft was deep in trying to keep Windows Phone alive.
Yeah it was. They never fully committed the marketing resources and strategy to win in the mobile market. The iPhone simply destroyed them, then android handsets.
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.
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.
It's pretty easy to disagree with this. There are shareholders that are still upset at the hundreds of millions spent on marketing and strategy in mobile.
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.)
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.)
Neither of the people who have an ARM Surface must have complained.
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.
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.
>What is the difference?
The fact that there won't be new x86 Macs in 5 years.
The fact that there won't be new x86 Macs in 5 years.
I say 2... future us will have to track this bet.
The difference between Apple and Microsoft is that I can make a claim that Apple will stop selling something they deem legacy technology in five years and people will mostly push back against me by saying that five years is too long. If I claimed that Microsoft would stop supporting something in Windows in five years, I'd mostly get jeers.
No need for a bet, Apple said so at WWDC. They started a transition period that will last 2 years.
What makes you think there still will be x86 Macs in 5 years? (we're speaking about new Macs right?)
If Apple still made XServe I would agree but here I don't see why they would keep x86 in their lineup.
If Apple still made XServe I would agree but here I don't see why they would keep x86 in their lineup.
A difference is Google versus Microsoft because Microsoft finally built it for themselves and is more generous (at least in this instance) in sharing the wealth back to the open source community? Chromium has had open source ARM builds, build pipelines, and CI/CD for a while now since the Edge team made it a priority. Google had no interest in proper ARM builds for desktop Chromium because they didn't want competitors for ChromeOS, so almost all of that has been Microsoft engineers (or so the GitHub statistics indicate). Electron can just reuse all the work that the Edge team already did for ARM on Windows, as opposed to building Chromium entirely from scratch as they would have had to for the original WinRT era.
> I am really curious why the response to Apple Silicon is so prompt vs when Microsoft did WinRT or ARM versions nobody really cared.
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.
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.
Microsoft didn't throw x86 out so there was no immediate need for ports.
I suspect the two major differences are that vendors have confidence that 1) Apple will stick by this decision for quite a long time and 2) Apple will sell a significant number of units with this new architecture.
Is this means that VS code can be running on an iPad ?
I don't think so, you still need macOS for electron.
Electron doesn't work on Android either and AFAIK there are no plans to make it work there.
Electron doesn't work on Android either and AFAIK there are no plans to make it work there.
For some reason this announcement gets displayed to me in a unholy mix of French and English:
> 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.
> 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.
It's mix, and the parts written in French are atrocious. Is that an automatically generated translation?
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 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 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.
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.
It does the same for me, but for Polish. I think those posts somehow use per-sentence i18n strings, so if a generic sentence sentence was already translated they will use it. I agree it looks a bit weird, though :).
There's a language switcher in the upper right. If you set it to French, it does that. Maybe just switch it back to English?
Now if we could have Node.js for ARM separately, that would be nice.
Electron is a cancer.
My thoughts? Fire at all arm electron as hard as possible forever and for always.