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.
Electron 11.0 released with support for Apple Silicon
191–200 of 224 posts
Re: Electron 11.0 released with support for Apple Silicon
#192From 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…
Re: Electron 11.0 released with support for Apple Silicon
#193Earlier 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.
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
#194I 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?
Re: Electron 11.0 released with support for Apple Silicon
#195I 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…
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
#196Earlier 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...
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
#197Earlier 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...
Re: Electron 11.0 released with support for Apple Silicon
#198Re: Electron 11.0 released with support for Apple Silicon
#199Earlier 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.
Re: Electron 11.0 released with support for Apple Silicon
#200Earlier 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.