Hacker News Reader

Comment by jchw | Hacker News Reader

The lead Wails developer has contributed a good deal of functionality and improvements to go-webview2, a library I wrote for interfacing with Windows WebView2 without needing CGo. While not a whole lot of people use go-webview2 directly (indeed, most people use it via Wails 2,) I am still glad that so many improvements made it upstream for whoever just wants direct bindings rather than a cross platform framework.

View on HN

Hey there :-) Thanks for making both go-webview2 and winloader, and taking the time to review the PRs. That reminds me, I need to diff where we are at as I think we got out of sync.

No worries; It shouldn’t be too bad. I would like to make some improvements to upstream go-webview2 when I get a chance; thanks to GitHub Actions, I bet I could implement some proper testing, which would be nice.

What happened to go-webview1?

It's just called webview/webview[0]. The fact is a little obscured now because it's been used from so many other languages, but Go/C/C++ were the original targets.

[0]https://github.com/webview/webview

Webview2 is the name of the Windows component that go-webview2 wraps. It’s a little bit confusing, because go-webview2 also happens to export an interface compatible with webview/webview, which is another library (although not Go-specific.)

edit: if you’re wondering why Webview2 is webview2, the reason for that is because Webview2 is based off of Chromium Edge and webview from WinRT is based off of MSHTML Edge. And if you are wondering why not support that, I considered it, but it’s somewhat harder to do, because while Webview2 is mostly pure COM interfaces, WinRT Webview uses… WinRT. Which is a bit more complicated. Avoiding CGo for that would probably involve worse blackmagic, possibly requiring some assembler to mimic what’s going on in WinRT.

Reply on news.ycombinator.com