Live data from Hacker News

Electron 11.0 released with support for Apple Silicon

electronjs.org

191–200 of 224 posts

Re: Electron 11.0 released with support for Apple Silicon

#191

Earlier quoted context omitted.

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.

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.)

Re: Electron 11.0 released with support for Apple Silicon

#192

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…

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.

Re: Electron 11.0 released with support for Apple Silicon

#193

Earlier quoted context omitted.

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 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.

Re: Electron 11.0 released with support for Apple Silicon

#194
post #31

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?

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.

Re: Electron 11.0 released with support for Apple Silicon

#195
post #31

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?

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" Microsof…

> 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).

Re: Electron 11.0 released with support for Apple Silicon

#196

Earlier quoted context omitted.

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...

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...)

Re: Electron 11.0 released with support for Apple Silicon

#197
post #35

Earlier quoted context omitted.

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.

Re: Electron 11.0 released with support for Apple Silicon

#199
post #193

Earlier quoted context omitted.

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 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.

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.

Re: Electron 11.0 released with support for Apple Silicon

#200

Earlier quoted context omitted.

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).
Post reply on HN