Native Webview Implementations for Desktop Targets.

[Shabinder]

Rather than having a Bulky JCEF/KCEF Implementations we should have more native oriented approach by delegating to below:

Windows	✅	Webview2
Linux	✅	WebKitGTK-4.1 or WebKitGTK-4.0
macOS	✅	WKWebview

See: https://pub.dev/packages/desktop_webview_window | Github

Obviously this wont be a smaller task, and have breaking changes, but I believe this would be crucial in future since KCEF as the standalone option doesn't cut for many apps, Where we can't just ask and w8 for user to download a browser while to just open a simple webpage and do simple tasks in-app, we will have many other added benefits of going this route, to name one, would be in-app login support, since many socials dont allow login in JCEF/KCEF.

Also, since this is mostly a Dart Wrapper over C/C++, we should be able to port this to KMP with Cinterop/cklib, with not that great of an effort.

thoughts ?

[DatL4g]

KCEF already supports loading from the bundled binaries for a while and even autodetects this since https://github.com/DatL4g/KCEF/releases/tag/v2024.04.20.4

However everyone seems to ignore my comments (since I mentioned it multiple times to @KevinnZou for example and some issues/PRs).
That means no downloading required anymore, just build and bundle the app with the JetBrains JCEF SDK.

Of course you can switch to your mentioned alternatives however I can tell you already that the Linux version won't support all distros.

[Shabinder]

That means no downloading required anymore, just build and bundle the app with the JetBrains JCEF SDK.

@DatL4g was not aware about above, do you have any insights on how building with JetbrainsRuntime impacts binary size ?
Bundling in, would generally mean a version of JCEF is shipped within final installation package making it bloated, r8?, hence not actually addressing the size of it issue?

[DatL4g]

Yes the binary size grows of course, that's the price you have to pay if you want to support all platforms.

I can only speak of Linux here as I haven't used another OS for 5 years but using WebKitGTK would be nice of course but isn't available on all distros.

It would be possible to check if it's available and if not the jcef binaries could be downloaded.

[DatL4g]

Some more thoughts on this topic.

Availability

This section describes some availability issues depending on the platform and if it's nice to have (on a end-user perspective).

🍎 MacOS

Using WKWebview would be easy? and nice (isn't the same thing used for iOS already?)
No complaints on that.
Maybe @KevinnZou can elaborate on that as he uses MacOS if I remember correctly.

🪟 Windows

Using WebView2 would be nice here as well.
Is there any known Kotlin/Java implementation yet?

One important thing:

The documentation specifies that it's "powered by Microsoft Edge (Chromium)".
Some minimal Windows installations do not come with Microsoft Edge (or it got uninstalled), is that a problem then?
Does it fallback to the specified standard browser, e.g. Chrome or Firefox?

🐧 Linux

Using WebKitGTK would be nice as well as long as it's available on the system.
Some distros don't support it, but most do.

Outcomes

I can think of 3 possible outcomes for the library-user here (based on the above options got implemented):

• 1. They don't care if everyone can use it as long as most can

  • ✅ WebView2, WebKit, WKWebview
  • 🟥 KCEF not required/used at all

• 2. They want all benefits of the above options and want to address every user

  • ✅ WebView2, WebKit, WKWebview
  • ⚠️ KCEF gets downloaded if the above don't work/unavailable

• 3. They want all benefits of the above options, address every user and don't want to download KCEF

  • ✅ WebView2, WebKit, WKWebview
  • ✅ KCEF comes included/bundled OR secondary bundled package versions are available

Solutions

I am in fact a supporter of WebView2, WebKit and WKWebview but you can't just declare that as THE SOLUTION.
My products are required in the more niche section and therefore require the fallback to KCEF so everyone can use it.

The conclusion to the availability and outcomes is that splitted modules would be perfect.
However I am not sure if that is even possible with the current structure @KevinnZou?

• For outcome 1 they just have to add io.github.kevinnzou:compose-webview-multiplatform.
• For outcome 2 and 3 they have to use io.github.kevinnzou:compose-webview-multiplatform-kcef-fallback instead.
  • And in case of 3 they have to build and bundle with the according JetBrains SDK

Please let me know what your thoughts on this topic and explanations are and the technical possibility.

[Shabinder]

The documentation specifies that it's "powered by Microsoft Edge (Chromium)".
Some minimal Windows installations do not come with Microsoft Edge (or it got uninstalled), is that a problem then?
Does it fallback to the specified standard browser, e.g. Chrome or Firefox?

No fallback by default, we will have to either show the user an indication of the absence of that and request installation, or if we have JCEF fallback proceed with that.

I am in fact a supporter of WebView2, WebKit and WKWebview but you can't just declare that as THE SOLUTION.

for sure, thats the whole reason of creating this issue and discussing the pros/cons of it all, and decide on which way would we want this library to hopefully go.

[KevinnZou]

@DatL4g @Shabinder I greatly appreciate this issue and the solutions proposed above. However, I am currently fully committed to another project and may not have the time to develop new features for this library. But I believe the issue you’ve raised needs to be addressed, and I think the solution of splitted modules is a good idea. So please feel free to continue discussing the subsequent development plans and proposals here. Thanks for your contribution again!

[KevinnZou]

@Shabinder I have invited you as a collaborator, please feel free to submit PR for this issue!