An alternative to WebView is WxWidgets, which also uses the "system" browser engine, but also has a menu API, which webview (currently) doesn't.
WebView development seems to go in spurts. Recently there has been a mini-spurt, after quiet for half a year. It could definitely do with more love.
It will give more burden to the platform developer and to the developer, having to work with less features and unable to follow more experimental technologies.
> it shares the system browser engine keeping memory usage down
The problem with high memory pressure have nothing to do with sharing a DSO or not, as this is a per process issue, the problem is that with the multi-process architecture, each renderer process have its own WebKit and V8+Node heap instances that need to deal with tons of javascript, resources and the bloat that comes with modern platforms like React, compiling Typescript on the fly or loading big WASM binaries.
I mean, the web standard is too complicated now, and theres a need for companies who can afford thousands (expensive) man-hour just to keep up.
Which leads to the reality of most browsers engines not being able to follow and becoming outdated in the near future.
Which means that shipping a "killer app" in such platform, like Visual Studio, will be harder than platforms like Electron, that giving its direct use of V8 can also have a "batteries included" platform by shipping together with NodeJs.