Is your feature request related to a problem? Please describe.
Currently, Wails v3 uses eval to directly send event data from Go to the frontend. This approach can lead to memory leaks or excessive memory usage in the WebView, especially when dealing with frequent or large event payloads. The eval call not only notifies the frontend but also carries the entire data, which increases the chance of hitting WebView memory limits.
Describe the solution you'd like
I propose decoupling the event notification mechanism from the event data transmission. Instead of pushing the entire event payload via eval, Wails should only use eval as a lightweight signal to notify the frontend that a new event is available. The frontend would then actively fetch the event data from the Go backend using the existing JS-Go bridge. Once retrieved, the frontend can publish the event through a subscription mechanism (e.g., an internal event bus).
This approach would minimize memory pressure on the WebView by avoiding large eval payloads, provide clearer separation of concerns (notification vs. data transfer), and make the event system more reliable and extensible.
Describe alternatives you've considered
Using eval for event delivery seems to inherently cause memory growth inside the WebView runtime. Even when the payload is not very large, continuous eval calls accumulate memory usage over time. In scenarios involving large event payloads or high-frequency updates, this issue becomes much more severe, and OOM errors are almost inevitable.
This indicates that relying on eval as the core transport mechanism is not sustainable for applications that need to handle large datasets or long-running sessions. A redesigned mechanism that decouples event notification (via eval) from event data transfer (via explicit frontend fetch) could significantly reduce the risk of memory leaks and improve long-term stability.
Additional context
Currently, Wails uses eval as the primary way to push event payloads from Go to the frontend. However, eval calls inherently increase memory usage inside the WebView runtime. Even when payloads are relatively small, repeated eval invocations accumulate memory over time. In cases with large data transfers or high-frequency events, this behavior often leads to out-of-memory (OOM) errors, which cannot be easily avoided.
By decoupling event notification (using eval) from event data transfer (via frontend-initiated fetch), Wails could significantly reduce memory overhead, improve long-term stability, and provide a more scalable event mechanism for real-world applications.
Is your feature request related to a problem? Please describe.
Currently, Wails v3 uses eval to directly send event data from Go to the frontend. This approach can lead to memory leaks or excessive memory usage in the WebView, especially when dealing with frequent or large event payloads. The eval call not only notifies the frontend but also carries the entire data, which increases the chance of hitting WebView memory limits.
Describe the solution you'd like
I propose decoupling the event notification mechanism from the event data transmission. Instead of pushing the entire event payload via eval, Wails should only use eval as a lightweight signal to notify the frontend that a new event is available. The frontend would then actively fetch the event data from the Go backend using the existing JS-Go bridge. Once retrieved, the frontend can publish the event through a subscription mechanism (e.g., an internal event bus).
This approach would minimize memory pressure on the WebView by avoiding large eval payloads, provide clearer separation of concerns (notification vs. data transfer), and make the event system more reliable and extensible.
Describe alternatives you've considered
Using eval for event delivery seems to inherently cause memory growth inside the WebView runtime. Even when the payload is not very large, continuous eval calls accumulate memory usage over time. In scenarios involving large event payloads or high-frequency updates, this issue becomes much more severe, and OOM errors are almost inevitable.
This indicates that relying on eval as the core transport mechanism is not sustainable for applications that need to handle large datasets or long-running sessions. A redesigned mechanism that decouples event notification (via eval) from event data transfer (via explicit frontend fetch) could significantly reduce the risk of memory leaks and improve long-term stability.
Additional context
Currently, Wails uses eval as the primary way to push event payloads from Go to the frontend. However, eval calls inherently increase memory usage inside the WebView runtime. Even when payloads are relatively small, repeated eval invocations accumulate memory over time. In cases with large data transfers or high-frequency events, this behavior often leads to out-of-memory (OOM) errors, which cannot be easily avoided.
By decoupling event notification (using eval) from event data transfer (via frontend-initiated fetch), Wails could significantly reduce memory overhead, improve long-term stability, and provide a more scalable event mechanism for real-world applications.