Web engine recommendation.

[ronnifadhlillah]

Any suggest web engine available in pywebview which is very light ? may running under old operating systems. I want my apps running in all version of operating systems.

Thanks

[KingEmma7]

There isn't one pywebview engine that guarantees support for every OS version. The engine, Python runtime and platform bindings each have their own minimum requirements.

For a small packaged app, I'd start with the platform's webview: WKWebView on macOS, WebKit2/GTK on Linux, and WebView2 on supported Windows versions. This avoids bundling a separate CEF browser with your app; it doesn't establish which engine uses the least RAM. The engine table lists the available backends, and the current installation source requires Python 3.10+.

For old Windows specifically, mshtml is the legacy IE backend and is deprecated. Modern JavaScript/CSS may not work there. WebView2 version 109 was the last to support Windows 7/8/8.1, according to Microsoft's announcement.

Which minimum Windows/macOS versions and Linux distributions do you need? Also, does “light” mean download size, RAM or startup time? Those details would let you choose and test a realistic backend set. I haven't benchmarked the engines or tested your target machines.

[ronnifadhlillah]

Hallo. thanks for the respond.

For now, I consider an application "lightweight" if it runs normally on 2010 and earlier version of operating systems.
I am particularly concerned about RAM usage, as there is a possibility the application will run for days or even months without being closed.

For information, I am using a web application converted into a desktop application, so pywebview seems to fit my needs well; however, I have encountered performance issues when the application runs continuously

Is it actually common practice to convert a web application into a desktop application?.

[saraeloop]

For memory that grows over days, I'd measure before changing anything. The growth could come from the frontend, your Python code, the bridge between them, or the webview runtime itself, so it's worth checking each one separately. A few ways to do that:

• Run with webview.start(debug=True) to get devtools, then take heap snapshots a few hours apart and compare what's accumulating. Common suspects include event listeners that never get removed, setInterval timers, and arrays or caches that keep growing, but the snapshots will confirm it.
• Track the Python process's memory separately from the webview processes, especially if you call Python from JS through js_api.
• If you're on WebView2, Microsoft's performance guide covers memory, and runtime updates have included leak fixes, so staying on a current runtime helps.

As a temporary mitigation while you track it down, reloading the page on a schedule can help long-running apps. That same guide suggests periodic refreshes where it fits. Make sure you save any unsaved work or session state first, and keep in mind a page reload won't clear memory held by the Python side.

On older systems, it helps to separate old hardware from an old OS. Old hardware with a supported OS is usually workable. An old OS is harder: Python 3.8 is the last version that runs on Windows 7, and it's end-of-life. WebView2 stopped supporting Windows 7/8 after version 109. pywebview's legacy MSHTML backend uses IE11 on Windows 7/8/10 (supported renderers), and modern web apps often don't run well on it. I'd pick an OS and renderer combination that still gets security updates and treat that as your minimum.

And yes, turning a web app into a desktop app is very common. VS Code, Slack, and Discord are all built this way with Electron. pywebview can use the system's own webview instead of bundling a whole browser, and it also supports Qt and CEF backends if you need them.

If you can share your exact OS versions, pywebview version, which renderer it's using, and how memory changes over time (e.g., after 1 hour vs. 1 day), it'll be much easier to pin down.

[ronnifadhlillah]

Hallo @saraeloop
I might run a few more tests to verify the performance and quality of the code I’ve written.
Thank you for the respond, input and advice.

[petrovicistefan]

Yes, packaging a web application as a desktop application is a common approach. For an app running for days or months, I’d investigate the memory growth before changing the web engine.

First, compare the same workload in a regular browser and in pywebview. Track the Python process and any renderer processes separately. This helps distinguish frontend memory retention from Python-side growth.

On the frontend, check for accumulating event listeners, timers, detached DOM nodes, unbounded caches, and unreleased object URLs. Compare heap snapshots after repeating the same operation several times. On the Python side, check growing collections, background tasks, and retained API results.

You can enable pywebview debugging with webview.start(debug=True), though the available inspection tools depend on the renderer.

Also, “2010 or earlier” needs exact OS versions: compatibility depends on Python, the web engine, and its platform dependencies.

Which OS, renderer, and pywebview version are you using? Does memory grow while the app is idle, or only after particular actions?