I'm doing something similar (Go-based desktop app) with Aether (<a href="https://getaether.net" rel="nofollow">https://getaether.net</a>), without requiring any additional tools.<p>The short version is, I have an Electron app, but the extent of my JS is just skin — the UI. The JS talks to two Go daemons which do the 99% of the work. It's also much more memory efficient than doing it in JS, and allows for massive parallelism. So you get best of both worlds, speed / clarity of Go, and well-developed JS UI patterns (Vue). It works well, with the caveat being a tradeoff in complexity in incorporating gRPC to let daemons talk to each other.<p>Here's the source code: <a href="https://github.com/nehbit/aether" rel="nofollow">https://github.com/nehbit/aether</a>
Electron is too bloated and heavy, and doesn't meld with the desktop... hey, lets create a new system that uses the same bloated/heavy bits as electron and also the UI that doesn't blend well.<p>edit: okay, so it doesn't have to download as much since it uses the already installed chrome, meaning you have to conform to ??? from an app perspective to your JS... you may as well just use electron or carlo
Well, on one hand it will certainly lighten the ressources needed.<p>On the other hand, you don’t know on what version of Chrome/Chromium you’ll land so you won’t be able to use specific API for sure.<p>But for having developed in the end of the 90’s a web kiosk software, based on Internet Explorer (I think it was IE5 back then), software that still have last versions running (no one, including myself, would thought it’ll survive that long), I will sure have a look closer on the project if you can intercept the before navigate event (or whatever the name is with Chrome)
Man, that slidedeck is frightening for someone who wants functional applications:<p><pre><code> Well-designed and attractive typographymakes content meaningful.
Animation makes important parts standout and helps with micro-interactions.
Onboarding, common for web andmobile apps, helps more than traditional"F1" button.
Visual trends may change and it shouldnot be hard to update the UI withoutrewriting it all.
</code></pre>
The result is what used to be described as "flash websites": everyone has their own UI, with custom animations that mean something entirely unique to that application which may or may not make sense to you.<p>But I could not explain this half as well as these articles about Flash. They also apply to HTML5.<p><a href="https://www.nngroup.com/articles/flash-99-percent-bad/" rel="nofollow">https://www.nngroup.com/articles/flash-99-percent-bad/</a>
Every time I see these things I just sit in relative disbelief trying to figure out how PWAs have somehow not taken off yet.<p>Perhaps this year when they finally come to Mac too (they already work on Windows and Linux) it will finally happen. then again with the Mac App store I'm not sure that fits the Apple "vision" (if you can call it that anymore) either.<p>Either way its sort of maddening to see this as I think PWAs are the right answer for these questions and yet people keep bringing new and unnecessary solutions to the table
I fail to see how this is any resource-lighter than Electron. It still uses a browser. It might or it might not be Chrome, but it's still a browser, so it will certainly use, give or take, the same amount of resources the average browser takes.<p>The only thing I do see as an advantage is the reduced size in the distributable. But, imho, size really doesn't matter these days.
In case you are interested, there is a flutter based GUI framework for Go, which looks promising. <a href="https://github.com/Drakirus/go-flutter-desktop-embedder/blob/master/README.md" rel="nofollow">https://github.com/Drakirus/go-flutter-desktop-embedder/blob...</a>
Can anyone tell me what mechanism would prevent any other software on the same system from intercepting the connection to Chrome? This isn't really an issue when running with X11 on Linux as any app can grab text from another window but e.g. Wayland provides much better barriers between apps.
This looks really interesting! I actually love browser/html/javaScript as a UI significantly over "native" but creating Electron based stuff always has me worried shipping a gigantic bloat and keeping it updated.
Alternative that uses the system webview rather than requiring Chrome: <a href="https://github.com/zserge/webview" rel="nofollow">https://github.com/zserge/webview</a>
the weakest point in systems like this is usually the mechanism by which the local process communicates with the browser. it's very hard to secure such a mechanism properly as there's no official API for it<p>this claims to use the chrome devtools debug protocol, which I believe is usually entirely unauthenticated. i would not be surprised if someone can compromise this system via this protocol<p>edit: this happened already with node in the case of CVE-2018-7160
HTML is really bad to create GUI applications, and it uses javascript. It's not a pure Go desktop application.<p>A Qt equivalent in go would be worth considering.
There is also <a href="https://sciter.com/" rel="nofollow">https://sciter.com/</a><p>It's non-free but you can "Use Sciter in binary form as it is published on the site" so cgo with bindings and the downloaded binary.<p><a href="https://github.com/sciter-sdk/go-sciter" rel="nofollow">https://github.com/sciter-sdk/go-sciter</a>
An alternative is this:<p><a href="https://github.com/andlabs/libui" rel="nofollow">https://github.com/andlabs/libui</a><p>There are Go bindings here:<p><a href="https://github.com/andlabs/ui" rel="nofollow">https://github.com/andlabs/ui</a>