Hacker News new | ask | show | jobs
by meindnoch 87 days ago
>It’s React Native for Windows which is a flavor of React Native that directly calls Windows APIs including, you guessed it, WinUI 3.

>So that’s it. Windows Start has a very small section (that can be disabled) that’s written in a framework that follows React principles and compiles down to native code.

False. React Native doesn't "compile down to native code". It runs actual JavaScript, just not inside a browser, but a standalone JS runtime.

3 comments

On slow enough Azure VDI host you could briefly see no-css language string when the start menu was still preparing for actual usage
lol
I wonder what engine they are using with ReactNative on Windows. Is it Hermes like with regular RN projects targeting iOS/Android? Or do they run on some system installation of a more traditional engine like V8/JavaScriptCore?
https://github.com/microsoft/react-native-windows/discussion... https://github.com/microsoft/react-native-windows/pull/15371 https://github.com/search?q=repo%3Amicrosoft%2Freact-native-...

It looks like they were originally on Chakra (the JS engine used by IE9+ and pre-Chromium Edge) but added support for Hermes in 2021 or so and removed support for Chakra last year, so Hermes is now the only option. Edge moved to Chromium in 2019, so this means they actually kept Chakra around for a few years just? for React Native on Windows.

Yep, oversimplification on my part. I'll make some edits.
I see your edits:

> This was an oversimplification bordering on being misleading. It’s a lighter JS runtime that’s calling native code for rendering controls. The argument still has merit. Just because something in JS doesn’t make it slow or bloated. Interpreted languages will almost always be slower than their native compiled counterparts, but it’s negligble [sic] for these purposes.

Isn't it a full JS runtime? I think by "a lighter JS runtime that's calling native code" you mean it doesn't deal with HTML/CSS rendering, but that's not what JS runtime means. These are separate parts of the browser architecture.

I don't agree it's negligible for this purpose. Core OS functionality should run well on old/cheap machines, and throwing in unnecessary interpreters/JITs for trivial stuff is inconsistent with their recently announced commitment to "faster and more responsive Windows experiences" and "improved memory efficiency".