> 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.
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.
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.
> 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.
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.
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.
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).
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.
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.
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.
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 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.
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.
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.
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.)
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.
> 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.
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 :).
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.
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.
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).
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.
> 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).
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).
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...
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.
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.)
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.
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.
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.
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.
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!
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.
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.
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.
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.
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.
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?
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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)
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.
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!)
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.
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.
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.
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.
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.
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
~/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 millis
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).
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).
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.
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.
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.
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?
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?
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.
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...)
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).
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?
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?
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.
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.
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.
> 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