PerryTS/perry

Summary Add an opt-in WinUI 3 / Fluent rendering backend for Windows, selectable via --target windows-winui, alongside the existing Win32/GDI backend (crates/perry-ui-windows). Motivation from discussion #3486: the current Win32/GDI output looks dated (boxy, flat, no animation, Win7-era controls). WinUI 3 brings Fluent Design — rounded corners, Mica/Acrylic materials, smooth animations, modern typography, crisp auto-DPI — and is the closest Windows analog to our iOS/Android look-and-feel. Scope / decisions Opt-in, not the default. WinUI 3 requires the WinAppSDK runtime + an MSIX/bootstrapper packaging story, which conflicts with Perry's single-native-.exe model. Keep Win32 as the default target; expose WinUI via --target windows-winui. Mirrors how we ship multiple Apple targets. No new "UI framework" dependency confusion: microsoft/windows-rs (already a dep, windows = "0.58") is the WinRT projection crate, not a UI lib. WinUI from Rust = driving WinAppSDK + XAML through the WinRT

The problem Some developers prefer to use signals for UI updates rather than React with its heavy-handed virtual DOM / diff algorithm. SolidJS is the fastest renderer out there -- a nice fit with perry/ui on mobile devices where speed and small memory footprint are desired. Proposed solution The SolidJS package is not tied to a web DOM renderer and is used by other non-web frameworks to generate a native UI. To implement this, you can use SolidJS with a universal renderer and only have to implement the following: createElement(string) { return document.createElement(string); }, createTextNode(value) { return document.createTextNode(value); }, replaceText(textNode, value) { textNode.data = value; }, setProperty(node, name, value) { if (name === "style") Object.assign(node.style, value); else if (name.startsWith("on")) node[name.toLowerCase()] = value; else if (PROPERTIES.has(name)) node[name] = value; else node.setAttribute(name, value); }, insertNode(parent, node, anchor)