"Native" is actually overloaded in the era of hybrid web apps - there are two pivots:

- Native code - does the GUI framework compile to machine code?

- Native widgets - does the GUI framework use platform widgets, or a platform agnostic layer?

In the context of Revery, we used "native" to mean "native code", ie, "compiles to machine code" - and further clarify in the README. It's important for us to make this differentiation - because often people look at the framework and assume its JavaScript.

Do you have a suggestion on how to clarify this?

Note that, if you're interested in using the platform UI - there's a project called Brisk (https://github.com/briskml/brisk) that is very similar to Revery, but uses platform UI frameworks (Cocoa/Win32/etc).

I dunno. Compiled -vs- Interpreted, and Desktop -vs- Browser seem like classic terms that gives 4 quadrants.

It's probably just Mac-heads that are particularly bothered by this topic, given that MS seems to create and sunset their native GUI frameworks fairly regular, and Linux has no single officially blessed one that everyone is attached to.

For native, there is Brisk[0], "A cross-platform set of tools for building native UIs with Reason/OCaml.

The goal of the project is to allow developers efficiently create fast, native apps for all major platforms. It's the best of both worlds: speed and portability, simplicity and great APIs."

[0] https://github.com/briskml/brisk

If Revery makes use of react-native-macos like ReactXP does, it does infact use Cocoa controls, unlike Flutter.

> Revery is like flutter in that it does not use native widgets. This means more work for us, but also that we have more predictable functionality cross-platform!

That's a bad thing.

Your apps are more predictable to developers between platforms, but less predictable to users.

A user expects all apps on their computer to behave the same. If you bring your own widgets, you violate that convention.