4 ms·

I just recently tried webview/webview in Go and was a little fed up with the fact that it could not be a single-binary plug & play experience on Windows. To tha

by jchw 6y ago

I just recently tried webview/webview in Go and was a little fed up with the fact that it could not be a single-binary plug & play experience on Windows. To that end, I am working on an experimental alternative that uses Webview2 directly without CGo: https://github.com/jchv/go-webview2 https://github.com/jchv/go-webview2 It still requires WebView2Loader.dll, but I am working on another library so I can just embed it directly into the application, and that work is happening over here: https://github.com/jchv/go-winloader https://github.com/jchv/go-winloader Sorry for the blatant self promotion, but I thought fellow stubborn people might have a desire to drop to as few dependencies as possible. I prefer building without CGo. The only downside is there’s not really a great way to fall back to EdgeHTML so users will need a Webview2 install, and right now Windows isn’t shipping it, but I think going forward it will be reasonable to just link users to the webview2 runtime page to go install it. (Also, it should go without saying, but this approach only improves things on Windows. You will still need other bindings for other platforms.)

fileeditview 6y ago
Is this a Windows-only solution or does this also work on Linux/Mac somehow?
- jchw 6y ago
  Windows-only; Windows is really the only platform where I am concerned about making the binary very self-contained anyways. On Linux/BSD package management makes the GTK-based solution pretty reasonable. On macOS I think the webview/webview solution is already self-contained. What I'd like is to help make upstream webview/webview more self-contained somehow, but for now a possible approach is to just use go-webview2 for Windows and then webview/webview for everything else. My approaches to lower dependencies may not be accepted upstream webview/webview: direct bindings to Webview2 mean no EdgeHTML fallback + code duplication from the C bindings, and go-winloader is (WIP, it doesn't even work yet) a fairly complex piece of code that would be an additional dependency. (Just so it's clear, I do actually want to make a concerted effort to try to support an EdgeHTML fallback, but it will effectively be based on directly binding to MSVC ABI from Go, and therefore will be a lot uglier than the current Webview2 code that just deals with COM interfaces directly.)
  - mmargerum 6y ago
    Why don't you just use walk if you only need windows. https://github.com/lxn/walk https://github.com/lxn/walk
    - jchw 6y ago
      I do want all platforms. I just made a solution that can be used on one of the platforms as an alternative.
zserge 6y ago
I like the approach of go-winloader, I'd be happy to include an example of using it with webview into the readme. I agree, including 2 DLLs on Windows is ugly, however I believe that using CGo for webview would be a long-term win, because new features of webview may emerge in webview.h and they will be available in all language bindings immediately, including Go. I might be wrong, but I think if there is a solution to include both DLLs (webview.dll and WebView2Loader.dll) into a single executable in Go - that could simplify life for everyone.
- jchw 6y ago
  Honestly, if you embed both DLLs, the only thing preventing you from being able to build with CGo off is the bindings implementation since it relies on CGo features. However, it might be possible to have one’s cake and eat it too here, if there is one implementation using Windows-specific Go features that embeds the DLLs and one implementation that uses the existing CGo approach on other platforms. Essentially, the binding to webview.h would be abstracted away from the Webview Go interface implementation. I will continue to work on go-winloader in my spare time, and hopefully will have an interesting webview pull request in the near-ish future.

by jchw 6y ago

fileeditview 6y ago

Is this a Windows-only solution or does this also work on Linux/Mac somehow?

jchw 6y ago
Windows-only; Windows is really the only platform where I am concerned about making the binary very self-contained anyways. On Linux/BSD package management makes the GTK-based solution pretty reasonable. On macOS I think the webview/webview solution is already self-contained. What I'd like is to help make upstream webview/webview more self-contained somehow, but for now a possible approach is to just use go-webview2 for Windows and then webview/webview for everything else. My approaches to lower dependencies may not be accepted upstream webview/webview: direct bindings to Webview2 mean no EdgeHTML fallback + code duplication from the C bindings, and go-winloader is (WIP, it doesn't even work yet) a fairly complex piece of code that would be an additional dependency. (Just so it's clear, I do actually want to make a concerted effort to try to support an EdgeHTML fallback, but it will effectively be based on directly binding to MSVC ABI from Go, and therefore will be a lot uglier than the current Webview2 code that just deals with COM interfaces directly.)
- mmargerum 6y ago
  Why don't you just use walk if you only need windows. https://github.com/lxn/walk https://github.com/lxn/walk
  - jchw 6y ago
    I do want all platforms. I just made a solution that can be used on one of the platforms as an alternative.

zserge 6y ago

I like the approach of go-winloader, I'd be happy to include an example of using it with webview into the readme. I agree, including 2 DLLs on Windows is ugly, however I believe that using CGo for webview would be a long-term win, because new features of webview may emerge in webview.h and they will be available in all language bindings immediately, including Go. I might be wrong, but I think if there is a solution to include both DLLs (webview.dll and WebView2Loader.dll) into a single executable in Go - that could simplify life for everyone.

jchw 6y ago
Honestly, if you embed both DLLs, the only thing preventing you from being able to build with CGo off is the bindings implementation since it relies on CGo features. However, it might be possible to have one’s cake and eat it too here, if there is one implementation using Windows-specific Go features that embeds the DLLs and one implementation that uses the existing CGo approach on other platforms. Essentially, the binding to webview.h would be abstracted away from the Webview Go interface implementation. I will continue to work on go-winloader in my spare time, and hopefully will have an interesting webview pull request in the near-ish future.