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.
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.
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.
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'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.
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.
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.
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.
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.
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.
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.
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.
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.
.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.
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.
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.
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 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
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.
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.
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?
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?
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.
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.
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.
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.
94 comments
[ 0.99 ms ] story [ 156 ms ] threadhttps://github.com/leaanthony
Cymru am byth!
Aeolun phrased it well!
Failing to understand languages isn't as impressive as you think.
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.
[0]https://github.com/webview/webview
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.
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.
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 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.
Of course, I do all my serious coding while listening to the fine music of MASTER BOOT RECORD.
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.
Using your logic, any IDE with a settings dialog is crap…
See how ridiculous this sounds? It sounds more so like you hate VSCode
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?
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.
I don't think there are any red flags there IMHO.
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.
- https://github.com/wailsapp/wails/discussions/1452
- https://github.com/tauri-apps/tauri/issues/2709
Atleast both are better than electron.
> No multi window currently but planned after v2 release
Are you talking about tabs? Or multiple windows (like finder/explorer)?
Awesome logo.
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.
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.
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.
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.
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)