You nailed it. Every time I see a new Electron replacement pop up that uses less resources, less disk space, etc., it's using the OS webview. I would argue that

You nailed it. Every time I see a new Electron replacement pop up that uses less resources, less disk space, etc., it's using the OS webview. I would argue that it's almost impossible to ship a reliable version of the app without resorting to polyfills and using only a fraction of the Web APIs available today. I tried Tauri out for a time tracking app that has a week input, and I ended up going back to Electron because the macOS webview (Safari) doesn't support it. If I use a framework that leverages the OS webview, can I use SharedWorkers? Nope. Atomics? Nope. WebGPU? Nope. You're kneecapped by the lowest common denominator (which is pretty much impossible to determine because there's no way to know the oldest version of the OS webview your users might have installed). Don't get me wrong, I applaud the efforts of the Photino devs, the Tauri devs, and the Wails devs. They're all very cool projects. But if you need to build something non-trivial with them, you're going to have a bad time. The resource usage and large binary size that comes with Electron is the price you pay for having a cross-platform app that doesn't break in weird and unexpected ways. I never see any kinds of warnings or caveats on these framework websites explaining the drawbacks of using the OS webview. Which means every time one of these comes out, I have to explain to the people that I work with why we can't just ditch Electron.