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.
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.
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.
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.
This and Sciter were clearly posted in response to (or to ride on the coattails of) Tauri's 1.0.
Sciter was specifically mentioned in tauri's thread, it's the subject of the top comment. Wener both mentioned wails in response to tauri's announcement, and posted this.
Interesting that the authors chose to commit their .vscode directory... given that this project was donated licenses by JetBrains. Maybe it's just a convenience thing.
On another tangent, I love seeing what music the authors were listening to while coding. Some might argue that it has no place in a README but... it's a nice touch.
I thought the music was cool too. I'd kinda like to see it in more project READMEs. Obviously not half the page, but a nice little section of mentions. Could be a cool way to find new music.
Years ago when I worked on a team of folks with similar music tastes, I'd put the album link in PRs for feature branches. Just a way of saying, "this week, while working on this feature, I was listening to this". It was just a fun thing to do.
I disagree and maybe I'm not 'fun', but to me there's a lot of garbage in this README. Scrolling through the plaintext document with lists of badges, manually managed table of contents, photos of contributors, miscellaneous HTML, you can see that there's so much content that isn't helping you understand the project—things that should be I a homepage or separate dedicated file. I can't read this without rendering it. The music while somewhat interesting, I don't think has a place in this document—especially linking out a proprietary music streaming platform.
.vscode committed to a repository is a bit of a warning flag to me. It tells me this repo is doing some non-standard stuff that needs special IDE configuration to account for.
Or it just includes some conveniences. A lot of my projects include a .vscode folder so that anyone who uses VS Code can debug the application right away. If you want to use your own IDE or even just run everything from the terminal, it all still works.
You can open the files in it and see what it does. It's absolutely nothing standard that you couldn't do without it. But having it committed will help others to use the same workflows more easily.
It contains some useful debug launch configs that would take time to work out otherwise, and also some settings that appear to make the Node part and Go part work it bit more nicely together.
Would there be interest in a cross-platform GUI written in C++ or Rust that uses HTML/CSS/JS as its layout and animation language, but runs natively on CPU/GPU without a browser layer?
That would be cool, but wouldn't any (full) implementation of the HTML/CSS/JS spec end up as a browser anyways? Unless you narrow the scope and only support a subset of HTML.
The thing is, HTML/CSS/JS is good as a layout paradigm but garbage as an actual GUI layout and language, because they were intended for hypertext documents, not applications.
If you're going to do that, maybe consider versions of those intended to work as a native GUI layer, but which are as easy to develop as the web.
> intended for hypertext documents, not applications
They’ve been evolving for so many years that the initial intent behind their design isn’t very relevant. Especially if you consider modern tooling, language versions, webgl, svg, canvas, and so much more.
Computers were supposed to be used for computing and printing solutions to polynomial equations. Is that really relevant to what computers are needed for anymore?
Spent some time learning this and playing with this till I ran into a roadblock that it doesn't support multiple windows which was a deal breaker for my idea. Wish I had the time to learn and contribute a PR. It was a great tool otherwise. I needed to do electron without the bloat and backend JS. There are no good solutions from what I researched, things like QT are still king in this area it seems.
When you say multiple windows, what do you mean? Both GH links mention using iframes. So do you mean multiple “windows” within the primary application window? Or do you mean multiple primary windows?
Are you talking about tabs? Or multiple windows (like finder/explorer)?
Multiple windows has some interesting nuances but we do aim to tackle that post v2. You would be surprised at just how much is involved in refining something like this, even with just a single window to worry about.
This looks interesting. I'ma fan of Go for backend and command line tool dev but haven't been able to find good front-end solutions. I'll have to keep an eye out for v2 of this since it is supposedly nearing release.
In a similar vein: I've been experimenting a lot with Flutter and while I don't like Dart that much, the tooling around it (being able to use the IDE and quickly test my apps in different mobile devices and desktop for instance) is really good.
You must break down the part that led to that reputation.
Electron uses its own renderer (chrome). Meaning it can't share memory with the os browser and make download size way bigger.
It bundles nodejs. Again make download size bigger
Nodejs needs to create multiple processes which each of them can use a lot of memory.
It use a bridge between the UI and backend (to do os stuff)
while JS is nowaday fast, Go/Java/C#/etc are still faster
Wails on the other hand.
Uses the os browser. (Download size is reduce and can share memory)
Go is compiled to native, no runtime needed. (Download size is reduce, lower on memory, run faster)
Same bridge performance bottleneck, but you can perform critical stuff in Go and get an advantage.
HTML renderers are fast. Code your UI with performance in mind, use a library like svelte or solidjs combine with something like wails (or anything that will do the same thing in java/c#/swift) and you won't see a difference between any native apps in most cases.
Also you gain the ability to share your UI code with the web.
Readit News
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.
[0]https://github.com/webview/webview
Tauri 1.0 – Electron Alternative Powered by Rust[0]
Sciter – Multiplatform HTML/CSS/JavaScript UI Engine for Applications[1]
[0]https://news.ycombinator.com/item?shownew&id=31764015
[1]https://news.ycombinator.com/item?shownew&id=31765566
Sciter was specifically mentioned in tauri's thread, it's the subject of the top comment. Wener both mentioned wails in response to tauri's announcement, and posted this.
On another tangent, I love seeing what music the authors were listening to while coding. Some might argue that it has no place in a README but... it's a nice touch.
Of course, I do all my serious coding while listening to the fine music of MASTER BOOT RECORD.
I don't think there are any red flags there IMHO.
If you're going to do that, maybe consider versions of those intended to work as a native GUI layer, but which are as easy to develop as the web.
They’ve been evolving for so many years that the initial intent behind their design isn’t very relevant. Especially if you consider modern tooling, language versions, webgl, svg, canvas, and so much more.
Deleted Comment
If there is one tech that we need to bring back from the dead, it is XUL
(XUL is the GUI toolkit powering Firefox, or at least was until they ripped almost all of it out and replaced it with "modern" (gag) HTML+CSS UI)
Are you talking about tabs? Or multiple windows (like finder/explorer)?
- https://github.com/wailsapp/wails/discussions/1452
- https://github.com/tauri-apps/tauri/issues/2709
> No multi window currently but planned after v2 release
Atleast both are better than electron.
https://github.com/leaanthony
Cymru am byth!
In a similar vein: I've been experimenting a lot with Flutter and while I don't like Dart that much, the tooling around it (being able to use the IDE and quickly test my apps in different mobile devices and desktop for instance) is really good.
But most of that is down to the architecture choice (using an HTML renderer) rather than the implementation.
I assume that means Wails has the same disadvantage?
Electron uses its own renderer (chrome). Meaning it can't share memory with the os browser and make download size way bigger. It bundles nodejs. Again make download size bigger Nodejs needs to create multiple processes which each of them can use a lot of memory. It use a bridge between the UI and backend (to do os stuff) while JS is nowaday fast, Go/Java/C#/etc are still faster
Wails on the other hand. Uses the os browser. (Download size is reduce and can share memory) Go is compiled to native, no runtime needed. (Download size is reduce, lower on memory, run faster) Same bridge performance bottleneck, but you can perform critical stuff in Go and get an advantage.
HTML renderers are fast. Code your UI with performance in mind, use a library like svelte or solidjs combine with something like wails (or anything that will do the same thing in java/c#/swift) and you won't see a difference between any native apps in most cases. Also you gain the ability to share your UI code with the web.