Proposal: Explore GPUI/GPUIX as an Optional Cross-Platform Renderer for Wails v3

[MikeLINGxZ]

Background

In [#4952](#4952), the possibility of supporting an embedded Chromium renderer was discussed.

The maintainer mentioned:

That said, a common cross-platform renderer is something we're interested in exploring, but bundling a browser engine isn't the direction we'd take to get there.

I completely understand and agree with Wails' goal of remaining lightweight and avoiding bundled browser engines.

However, this made me wonder whether GPUI/GPUIX could be a potential alternative for achieving consistent cross-platform rendering without bundling Chromium or CEF.

Proposal

Would it be possible to explore an optional GPU-based rendering backend for Wails v3, using [GPUI](https://github.com/zed-industries/zed/tree/main/crates/gpui) and [GPUIX](https://github.com/remorses/gpuix)?

GPUI is a GPU-accelerated UI framework written in Rust and used by Zed. GPUIX provides a React/Solid integration layer for building native interfaces on top of GPUI.

Unlike Chromium or WebKit, GPUI does not rely on a traditional browser engine for rendering.

Conceptually, Wails could support multiple rendering backends:

Wails v3
│
├── Go Backend
│   ├── Services
│   ├── Bindings
│   ├── Events
│   └── Plugins
│
└── Renderer Backend
    │
    ├── Native WebView (default)
    │   ├── Windows → WebView2
    │   ├── macOS   → WKWebView
    │   └── Linux   → WebKitGTK
    │
    └── GPUI/GPUIX (optional)
        ├── Windows
        ├── macOS
        └── Linux

The goal would not be to replace the existing WebView implementation, but to explore whether Wails could provide a sufficiently abstract interface for alternative renderers.

Potential Benefits

1. Consistent cross-platform rendering — Reduce differences caused by platform-specific WebView implementations
2. No bundled browser engine — Preserve Wails' philosophy of avoiding Chromium/CEF
3. GPU-accelerated native UI — Enable applications that benefit from GPUI's rendering architecture
4. Reuse the Go backend — Ideally retain Wails' services, bindings, events, and plugin ecosystem
5. Optional integration — Keep the existing WebView as the default, with GPUIX maintained as an independent community backend if feasible

Technical Challenges

I understand this would not be a simple renderer swap.

Some challenges would likely include:

• Window ownership and native event-loop integration
• JavaScript runtime integration for GPUIX
• Go-to-JavaScript IPC without relying on a WebView
• Native window lifecycle and GPU surface management
• Build tooling, packaging, and cross-platform maintenance
• Differences between DOM-based UI and GPUIX components

Also, GPUIX is still evolving, so this is more of an architectural exploration than a request for immediate implementation.

Questions

I'd love to hear the maintainers' thoughts on a few questions:

1. Does Wails v3 have any plans to support pluggable rendering backends, or is the WebView intended to remain a fundamental part of its architecture?

2. When mentioning an interest in a common cross-platform renderer in About embedding chromium #4952, were non-browser rendering frameworks such as GPUI or Skia part of the possibilities being considered?

3. Would it be technically feasible to reuse Wails' Go backend, services, bindings, and event system with an alternative renderer?

4. If the community wanted to experiment with a GPUIX backend, would it be possible to implement it as an external integration, or would it require significant changes to Wails' core architecture?

5. Would the maintainers be open to discussing a minimal renderer abstraction that could enable community-maintained backends without introducing additional dependencies into Wails itself?

Closing Thoughts

I'm not suggesting that Wails should officially adopt or maintain GPUIX.

Rather, I'm interested in whether Wails could eventually support a renderer-independent architecture, allowing the community to experiment with alternatives while keeping the existing lightweight WebView approach unchanged.

I think this could be an interesting direction for Wails v3, especially for developers who want to combine Go's backend capabilities with consistent, GPU-accelerated cross-platform interfaces.

I'd be interested to hear whether this aligns with the maintainers' long-term vision for Wails.

Thanks for all the work on Wails!