This isn't by any means a complete answer, but BrowserView
was created because of various issues encountered with webview
.
Here's a blog post by the people that created it:
- a new way to embed web apps with fewer bugs and improved performance
- webviews seemed to work well at first, but over time we ran into an ever growing list of issues. There were bugs in fundamental features like drag-and-drop and general performance was simply not on par with Chrome.
Electron's webview
documentation says:
Electron's webview tag is based on Chromium's webview, which is undergoing dramatic architectural changes. This impacts the stability of webviews, including rendering, navigation, and event routing.
There were a number of webview
bugs back in the day, though these particular ones appear to be fixed.
Here's an issue about the fate of BrowserView
where a maintainer says:
<webview>
still has a number of bugs. There are also architectural issues like slow auto-resizing that are unlikely to be fixed in Chromium any time soon
Here are a number of webview
bugs (though you can certainly find bugs with BrowserView
as well)
Also, you say:
the BrowserView does not use another renderer process
I believe I saw a reference to that somewhere as well, but I don't think that's true.
The moment you navigate the BrowserView
to a page, a new renderer process is created for it.
Update: Oh, I think what's meant here is that the webview == 1 process and a BrowserView == 1 process, but you create the webview inside of another Renderer process, whereas you create the BrowserView inside of the main process. So there will be an extra process with webview.