Wails – Electron Alternative Powered by Go | Hacker News Reader

Wails – Electron Alternative Powered by Go

github.com

394 pointswener93 comments

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.

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.

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.

Today must be "Electron Alternative Day" on HN:

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

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 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.

Ease up on the high expectations. It's just a fun project on github, not a publication in an academic journal.

People love shitting on OSS projects. Tech choices, docs, tooling, testing, number of contributors (both "Too many!" and "Bus factor!"), choice of license, there is already X, why not use Y, we already did that in the 80's... Basically anything.

As if other people writing and sharing code freely is a huge problem.

I think it is different when a project is part of a commercial offering, or funded by something you participate in.

> People love shitting on OSS projects

People love shitting on closed source projects too, but the circle of people you can reasonably do that in is fairly limited.

Everyone can see this code, so you can shout it to the world.

Why does being closed source limit anything? People on hear openly shit on Apple, Google, M$, blah blah without limitations. Sure, with OSS you can leave shit comments directly on the project page, it's not like people are not screaming on Twitter or other socials about closed source stuff which I'd imagine has a lot larger of an audience than the smaller tech people looking at OSS project pages

Not only that, but it comes at a personal cost. Few OSS project maintainers will tell you this but time spent on the project is time not spent with family and friends. They invest in these projects too.

They did put it at the bottom of the README. I would understand your frustration if it was at the top or in-between important content.

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.

Maybe in addition to README, LICENSE, CONTRIBUTING, and so on, MUSIC should be standard practice for repositories. :)

Of course, I do all my serious coding while listening to the fine music of MASTER BOOT RECORD.

.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 using codespaces for development

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.

Sufficiently complex projects are going to need some IDE config to get everything running and integrated with IDE tooling.

No, they don't. At least nothing IDE specific. Most languages come with a way to configure dependencies and build configuration independently from IDEs. If your IDE is incapable of picking those up, your IDE is crap. If you want to keep your developers from having to muck about with IDE settings, put those settings into an independent repo. If your IDE is incapable of picking up configuration from a specific directory, again, your IDE is crap.

Does your CI read IDE settings or language specific settings? If you're depending on IDE specific settings in your pipeline, your entire pipeline is brittle.

So, no "sufficiently complex project" should need any IDE specific config in the project repo.

Did you actually read the files? It’s launch configs and an eslint config. So you’re saying an IDE is crap if it can’t discover all of the commands of your project? Your saying it’s crap because in a split go and typescript codebase it’s supposed to know you want eslint triggered on JS code only during save?

Using your logic, any IDE with a settings dialog is crap…

See how ridiculous this sounds? It sounds more so like you hate VSCode

> Using your logic, any IDE with a settings dialog is crap…

You are reading things into my comment that aren't there. Maybe you should reread it. Especially the part where I talk about the separation of project specific configs and general IDE configs. Or how your CI should be able to pick these things up.

> It sounds more so like you hate VSCode

What else are you seeing down there in the tea leaves? Did I say anything about VSCode?

Perhaps you misread mine. What common structure exists to define what commands, sub commands, and tests exist in a project? If I were to write a CLI app, can any of the jetbrains or other IDEs automatically detect what the sub commands are within my CLI? What structure would it read this from?

Golang certainly has no such file, so you’d have to read from the main package and understand every CLI framework out there to parse out the sub commands to build your launch configuration. Sounds real easy right?

Now if we’re talking about nodejs, where the package.json can hold your run configurations within the script section, then ok. But we’re talking about golang.

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.

I don't think there are any red flags there IMHO.

Nope. Just an old directory that made it in there at some point.

That was probably from back in the day. Hardcore Goland user now! The music was more to promote bands that some people would never have heard of.

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?

I think you're looking for https://www.areweguiyet.com/ click "webrenderer"

I hope not. HTML/CSS were supposed to be used for "hyper text" and "magazine-like" content

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?

bad comparison. HTML encoding inherently is incompatible with dynamic presentation of data.

Not true considering how you don't need JavaScript to display several dynamic elements such as forms, checkboxes, details boxes, or videos. Also proven to be compatible through schemes like QML. It's kind of like saying a soft, meatlike human body is inherently incompatible with hard, metal electronics. True, it wasn't invented to do that, and problems arise from that interaction, but it doesn't mean they are incompatible.

Could you elaborate on what you mean by "without a browser layer"? Would there still be a webview / blink etc. implementation?

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.

Take that concept a bit further and you’ve basically gone down the same path as Flutter.

isn't that what chrome is? either way QML is kind of what most people seem to be looking for and it's widely used

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.

This existed, it was called XUL, and it was glorious

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)

Unsure if joking. XUL was awful.

Are you kidding? I loved working with it.

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.

Asked for the same thing, but it's impossible or too hard to do it.

- https://github.com/wailsapp/wails/discussions/1452

- https://github.com/tauri-apps/tauri/issues/2709

These days any apps or framework written rust seems exotic.

Atleast both are better than electron.

Huh? Per the wails thread:

> No multi window currently but planned after v2 release

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 actual windows, Each window on a different monitor.

NeutralinoJS supports this, apparently: https://github.com/neutralinojs/neutralinojs/issues/249

Still JS.

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.

Oh I don't doubt that one bit. Thank you for your hard work on it.

Are tabs an option?

Nope, content needs to be on multiple monitors at once.

I meant are tabbed views possible with wails?

Not to mention a treeview !

Love the logo, and quite appropriate given the name and the lead is obviously Welsh!

https://github.com/leaanthony

Cymru am byth!

  > Cymru am byth!

Plzeh nz olgu!

Welsh sounds like something Cthulhu worshippers would use.

That's not Welsh. It's the rot13 of the Welsh phrase in the comment replied to.

That's pretty much the point that I was making. When I see text that looks like a rot13 encoded string, it's usually Welsh. Other than one unlucky vowelless word, neither the original Welsh nor my reply look more plausibly real than the other.

Aeolun phrased it well!

Interesting fact: despite the common jibes about lack of vowels, Welsh has 7 vowels whilst English has 5! Like WiFi, just because you can't see it doesn't mean it doesn't exist.

I don't speak any Welsh. I've never even been to Wales. I still knew what that phrase meant and was able to identify you had rot13d it.

Failing to understand languages isn't as impressive as you think.

I'm sorry, I thought that we were involved in friendly discussion. I did not realize that this discourse is antagonistic for you. You are 100% correct and you win the argument that I did not realize you had.

Syt mae? Qatar amdani! :-)

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.

Electron has a reputation for poor performance and slurping RAM...

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?

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.

Seems 1.0 was released a good while ago (and currently under a feature/patch freeze) and 2.0 is soon to be released. Not sure the version should be in the submission title.

because it seems go and rust are in a competition, and a rust library of similar fashion just made it to front page. takes off tinfoil hat

And it mysteriously dropped off the front page pretty quickly; tauri's 1.0 was just released which should make the post more attention-worthy in my mind.

sorry, copied from `Tauri 1.0 – Electron Alternative Powered by Rust`, I'm a gopher, so I prefer wails. 2.0 is about to release, but beta works as promised.

No harm done :) The "1.0" was in that title because Tauri just released 1.0, not because it just happened to be 1.0 when submitted.

went to github link to be amazed, but felt almost like a clickbait

This is basically the same thing as Tauri but once again, the difference is the language used. I don't know what the selling point is other than it is using Go FFI to talk to the Desktop APIs.

The reason why Electron exists is that it is able to directly turn existing web apps or anything using the Chrome APIs into desktop apps and being compatible with the wider Javascript ecosystem as well with little effort other than adapting to the desktop. I don't think that it is possible with this or Tauri unless you want to rewrite the whole thing and not depend on Chromium APIs.

A great alternative would be compatible with these Chromium APIs and allow an easy migration off of Electron but that is not going to happen anytime soon.

Either way, I'd rather see Flutter Desktop as a suitable competitor and a possible alternative to Electron desktop apps rather than these webview-based alternatives.

Here you are: https://flet.dev - Electron alternative with Flutter-powered UI. We decided to focus on Python first to polish the idea, but Go and C# support are coming!

This is fantastic, been meaning to learn Flutter for a long time (and probably still should), but having it in a language I already know and use is a whole other level

Nice! How does the packaging works ? Is it through pyinstaller ?

PyInstaller should work. Will look into that and write a guide.

Many web apps do not use node.js on the backend, so I don't really think that's the point of electron. It's more that it's a way to develop a cross platform application without having to deal too much with native differences. Being able to leverage web tech for the UI also means you can reuse your companies existing expertise.

In that sense, these alternatives all meet the requirement, as on the UI side they all use standard web technology. The difference is 1) they don't package the entire chrome runtime which saves a lot of memory and 2) they use different backend languages, some of which may match a given companies expertise better. E.g. if you already have a lot of Go or Rust developers, these alternatives might allow you to reuse existing backend code in these languages.

Finally, the experience of developing with the alternatives is often superior to electron. Every time I've setup electron for a new project I've spent days messing with complex tooling. In contrast, at least with wails, I've spent close to zero time on tooling. Ironically, the time I have spent on tooling has been on the javascript side.

Might be worth having a look at this as well: https://github.com/fyne-io/fyne

    is an easy-to-use UI toolkit and app API written in Go. It is designed to build applications that run on desktop and mobile devices with a single codebase.

I was excited to prototype a HTML-template driven application using Wails, but found out that you're basically forced into making a SPA i.e. URL routing doesn't exist, you have to handle page transitions using JavaScript. Also there's no native back button, so one more thing to reimplement using JavaScript.

Related: https://github.com/fyne-io/fyne - Cross platform GUI in Go

Named after the wails of developers maintaining Electron code bases?

Tenth circle of Hell?

Judging from the logo, it's named after both the country Wales and the application framework Rails.

Awesome logo.

This is 100% accurate!

Would be good to add screenshots to README

Reply on news.ycombinator.com