Summary: In certain circumstances webview rendering is slow because it has to integrate with the android rendering API incase an app wishes to synchronize some App UI with web UI.
This isn't a limitation in chrome itself, which means chrome rendering has better performance for these specific operations (animations mostly).
Personally I think the chrome rendering path should always be used, and apps which want to draw under/over web content will have to deal with a frame or two of delay.
It's amazing bugs like this persist, even with the significant resources of several megacorps allocating legions of full-time developers to the codebase.
Their incentive is to keep the browsers good enough to not lose market share. Other than that, the incentive is to either close the web down, or to make the experience as shitty as possible without leading users to switch away, so they can steer users towards the more closed-down native apps.
Unfortunately, companies have an incentive to put us into walled gardens, so the only company that actually cares about the web is the company whose only business model is selling a browser.
My understanding of the system webview is that applications can share the resource instead of each using their own copy, reducing memory usage and improving multi-tasking. Facebook's solution seems to side step that benefit. I use the fb browser much less frequently than my normal browser, and id rather not use the fb browser at all. I imagine this is true for most users, so the security benefit seems overstated.
This is my actual complain with Electron. And with modern programming languages like Go and Rust. Static compilation is such a grevious waste of memory & caches.
There's Tauri, which does use a dynamic loading approach. But the various browsers it uses are nowhere near as capable and featureful as chrome, which is so sad. I don't know when it got started but there is https://github.com/tauri-apps/cef-rs now, using Chromium Embedded Framework, which is pleasantly modern & can share a binary too; rad.
It's a real ding to Google that they had to do this very significant workaround to the janky issues with WebView. The amount of resources required to build a parallel custom Chromium with all the changes they listed is enormous and fraught with problems. Just to get around stuff that should have been baked in.
Yes, and I do. But Facebook doesn't use it even in that case. Even before they started shipping their own. If they used my Firefox setting as the Facebook browser then it wouldn't be a problem for me!
About a decade ago iOS only had UIWebView which was significantly worse than Safari. This affected all apps using a webview including competing browsers.
Summary: In certain circumstances webview rendering is slow because it has to integrate with the android rendering API incase an app wishes to synchronize some App UI with web UI.
This isn't a limitation in chrome itself, which means chrome rendering has better performance for these specific operations (animations mostly).
Personally I think the chrome rendering path should always be used, and apps which want to draw under/over web content will have to deal with a frame or two of delay.
It's amazing bugs like this persist, even with the significant resources of several megacorps allocating legions of full-time developers to the codebase.
Their incentive is to keep the browsers good enough to not lose market share. Other than that, the incentive is to either close the web down, or to make the experience as shitty as possible without leading users to switch away, so they can steer users towards the more closed-down native apps.
Unfortunately, companies have an incentive to put us into walled gardens, so the only company that actually cares about the web is the company whose only business model is selling a browser.
To save you having to read a really long comment thread: https://engineering.fb.com/2022/09/30/android/launching-a-ne...
Basically, FB's engineering replaced it with a full chromium based webview and explained the reasons android webview sucks ass.
My understanding of the system webview is that applications can share the resource instead of each using their own copy, reducing memory usage and improving multi-tasking. Facebook's solution seems to side step that benefit. I use the fb browser much less frequently than my normal browser, and id rather not use the fb browser at all. I imagine this is true for most users, so the security benefit seems overstated.
This is my actual complain with Electron. And with modern programming languages like Go and Rust. Static compilation is such a grevious waste of memory & caches.
There's Tauri, which does use a dynamic loading approach. But the various browsers it uses are nowhere near as capable and featureful as chrome, which is so sad. I don't know when it got started but there is https://github.com/tauri-apps/cef-rs now, using Chromium Embedded Framework, which is pleasantly modern & can share a binary too; rad.
It's a real ding to Google that they had to do this very significant workaround to the janky issues with WebView. The amount of resources required to build a parallel custom Chromium with all the changes they listed is enormous and fraught with problems. Just to get around stuff that should have been baked in.
Maybe I missed it but how much does that custom webview weight?
How about they let us opt out of using it at all and just let us use our own browser?
You can use Firefox as the system webview on Android
Yes, and I do. But Facebook doesn't use it even in that case. Even before they started shipping their own. If they used my Firefox setting as the Facebook browser then it wouldn't be a problem for me!
Reminds of the old iOS days before WKWebView.
About a decade ago iOS only had UIWebView which was significantly worse than Safari. This affected all apps using a webview including competing browsers.
unfortunately nobody cares :(