What even is "native" on Windows? Is it Win32? WinForms? WPF? UWP? WinUI? Windows App SDK? There's so many to choose from and they all look and behave differently.
Win32, WinForms, WPF are as good as it gets, and really the only ones that matter.
UWP is deprecated, althought it keeps being the one mostly used on Windows 11, as WinUI still isn't up to its game and keeps collecting issues across all their repos.
Windows App SDK is not a GUI framework, rather the new marketing name for Project Reunion, the porting of UWP runtime infrastructure on top of standard COM without sandoxing and application identity.
Do you know which of those toolkits is used for the new Windows 11 Notepad? It's quite a bit more "laggy" to scroll in than the old Notepad that's still on the Server edition.
Pax composites a layer of native text and form elements on top of a canvas drawing layer. This solves accessibility across platforms, as well SEO on the Web.
This approach also enables a lean runtime footprint (<100Kb, particularly useful when targeting Web) because the runtime doesn't need to reinvent text rendering, selection, input, etc.
Pax does solve this, but we're now discussing a different problem than element-level look-and-feel or accessibility. Three ways you can slice this with Pax, ft. pseudocode:
1. Conditional templating, like:
<SomeLayout>
if $is_android {
//Only render the back button for Android
<BackButton />
}
/* ... */
</SomeLayout>
2. Dynamic properties where Rust logic checks for the target platform, like:
Does this actually render a native Android back button to the canvas or are you simply saying Pax solves this by not restricting the user from making their own solution to the problem?
Pax's Android chassis isn't built yet — but a Pax `<Button>` will render an actual native Android button to a layer on top of a separate canvas layer where vector drawing occurs.
That native Android button will be affine-transformed, clipped, and occluded so that the two layers together act as a single coherent screen, and the developer can simply position / transform / layout that `<Button>` alongside, on top of, or underneath virtual / drawn elements as if they were on the same canvas.
This "dual layer" approach is already implemented for Pax's `<Text>` element on macOS (native SwiftUI `Text`) and Web (native `<div>` + HTML text) — see: https://docs.pax-lang.org/intro-example.html
The native bindings are the first section on the list, and they work well. If you're concerned about looking and behaving native just use those native bindings.
