Writing GUI apps for Windows is painful

Original Article ↗ Hacker News Discussion ↗

Writing modern GUI apps for Windows is portrayed as surprisingly hard, especially under constraints like a single portable executable, full custom theming, native C++ and tight size limits. Commenters trace the pain less to Windows itself and more to shifting Microsoft UI stacks, heavy frameworks, licensing and packaging trade‑offs, and the complexity of GUI work in general. Many argue that if you relax requirements—accepting installers, .NET, Qt’s licensing, or web-based shells like Electron or WebView2—Windows GUI development becomes much more practical, though at the cost of either bloat or strict “native look and feel.”

Overall sentiment

  • Many agree that writing GUI apps is painful, especially on Windows, but differ on whether this is worse than other platforms.
  • Some argue Windows desktop dev is actually “better than ever” if you choose the right tools; others say the platform is a mess of abandoned toolkits and half-finished ideas.

Legacy vs. modern Windows GUIs

  • Old tools (VB6, WinForms, MFC, Delphi) are remembered as fast to use and producing consistent UIs, albeit limited.
  • Modern stacks (WPF, UWP, WinUI 2/3, MAUI, React Native for Windows) are seen as fragmented, unstable, and frequently reset by Microsoft.
  • Several people still recommend WinForms or WPF on .NET Framework 4.8 for practicality, noting it’s preinstalled on recent Windows.

Microsoft stack fragmentation

  • Strong criticism that Microsoft repeatedly replaces UI frameworks (WPF → UWP → WinUI → MAUI/Blazor/WinAppSDK), often without clear migration paths.
  • Disagreement whether WinUI 3 is “abandoned” or “the winner going forward”; even supporters admit tooling (designer, hot reload) is buggy.

Binary size & “single-EXE” constraint

  • Many consider the author’s constraints (single EXE, <40 MB, custom styling, native code, no LGPL, no installer) unrealistic or self-imposed.
  • Others defend size and portability constraints as valid for embedded devices, strict customers, or non-technical users.
  • Discussion on LGPL: static vs dynamic linking, shipping .o files to comply, and how this clashes with “single EXE” goals.

Native vs custom styling

  • Large camp: native Win32/OS controls should be used and not restyled; custom themes are seen as hostile, break accessibility and familiarity.
  • Counterpoint: branding and dense/specialized UIs (DAWs, graphics tools, games) often need custom widgets and theming.
  • Dark mode for classic Win32 is described as partial and hacky, pushing people to owner-draw controls.

Toolkit options mentioned

  • Qt widely praised as “only sane option” for serious C++ GUI, but licensing cost and size clash with the article’s constraints.
  • Alternatives cited: FLTK, wxWidgets, Lazarus/Delphi, JUCE, Dear ImGui/nuklear/egui, Slint, Avalonia, Uno, Tauri, Electron, Flutter, Tkinter, WebView2, C++Builder.
  • Dear ImGui is valued for development speed and small binaries, but criticized as unsuitable for end-user apps (accessibility, conventions, keyboard/IME, non-native look).

Cross‑platform vs Windows-only

  • Several argue the real hard problem is cross‑platform GUI, not Windows alone.
  • Electron’s popularity is seen as a rational response to native-UI chaos, despite size/performance concerns.