WinUI 3 Performance: A Leap Forward

Original Article ↗ Hacker News Discussion ↗

Overall reaction to WinUI 3 performance work

  • Some welcome that Microsoft appears to care about performance and quality again.
  • Others see the blog as mostly marketing, expecting that once usage rebounds, bloat and “experience-killing” features (ads, etc.) will return.
  • Several note a long-running “good/bad” oscillation in Windows releases and doubt that 11 is in the “good” category.

Trust in Microsoft UI frameworks

  • Many Windows devs say they’ve been burned repeatedly (Silverlight, UWP, WinRT, MAUI, etc.) and now avoid new frameworks.
  • WPF and even WinForms/Win32 are still preferred by several participants for reliability and tooling.
  • WinUI/WinRT is often described as something to avoid unless no alternative exists.

WinUI 3 developer and user experience

  • Developer experience is widely criticized: poor docs, missing designer, hacks required for basic behavior, laggy controls and resizing.
  • C++/WinRT and the surrounding tooling are called out as especially painful.
  • Some say WinUI 3 is measurably slower than WPF and UWP in community benchmarks.

Cross‑platform vs Windows‑specific UI

  • Multiple commenters argue there’s little reason to pick WinUI over cross‑platform options (Avalonia, egui, Flutter, MAUI, etc.), except possibly for native integration and accessibility.
  • Others stress trade‑offs: immediate vs retained mode, startup time, memory usage, “native feel,” accessibility, and scroll behavior.
  • Avalonia is frequently mentioned as a “spiritual successor” to WPF; some already use it but still find it laggy.

Explorer, system apps, and OS performance

  • People hope WinUI improvements will benefit Explorer, Photos, and other system apps; this is stated as an explicit goal in the linked content.
  • Several complain that Explorer and basic apps (Calculator, image viewer) are noticeably slow on modern hardware.
  • Some contrast this with memories of Windows 7/8/early‑10 and Windows Phone being extremely fast and efficient on low‑end devices.

Technical causes of slowness (debated)

  • One view blames pervasive COM/WinRT reference counting and abstraction layers for overhead.
  • Others counter that ref‑counting is rarely the main bottleneck in UI; they blame layout algorithms, blocking the UI thread, and excessive object churn instead.
  • There is agreement that newer frameworks are significantly heavier than older ones built for more constrained machines.

Broader design and business concerns

  • Commenters lament loss of clear Windows design guidelines and cohesive UI.
  • Accessibility and traditional desktop affordances (keyboard accelerators, clear focus/edges) are seen as regressing.
  • Several argue that corporate/VP priorities and ad/telemetry monetization drive decisions more than technical excellence.