12 ms·

Golang Desktop App with Webview/Lorca, WASM and Bazel

154 points by grahar64 6y ago

rwitoff 6y ago
Does this lead to a significantly smaller memory footprint than otherwise running .js in electron or a full browser? I see you've become a big fan of bazel :)
- akrymski 6y ago
  It's the difference between a new tab vs a new browser instance - every electron app is a new browser instance with fixed overhead of 100mb or so. A new browser tab is closer to 10mb overhead.
Jolter 6y ago
Knowing next to nothing about Golang: Is it unlikely that someone would ever develop an actual desktop toolkit for Golang? If so, how come? From a naïve point of view, it would seem like overkill to run a whole web browser when a few kilobytes of memory is all it really takes to draw a widget on screen.
- dmitriid 6y ago
  "all it takes to draw a widget on the screen" is not enough to create "an actual desktop toolkit". If you need to draw a widget on the screen, there's Dear ImGui [1] that you can use from Go [2] If you're looking for a desktop toolkit, there's a reason why things like Qt are multidecade endeavours. [1] https://github.com/ocornut/imgui https://github.com/ocornut/imgui [2] https://github.com/inkyblackness/imgui-go https://github.com/inkyblackness/imgui-go
- grey-area 6y ago
  Cross platform UI toolkits are a sisyphean task that everyone wants someone else to work on. Platform vendors like Apple, Google, MS don't want to let developers target multiple ecosystems - they want a monopoly on devs and users, hence the endless churn of languages, frameworks and SDKs, making it difficult to keep up. It's much easier and more reliable to use HTML, even if the experience isn't as slick for users.
  - viraptor 6y ago
    > Platform vendors like Apple, Google, MS don't want to let developers target multiple ecosystems Is this actually true? As in, I see how we may arrive at the same outcome anyway, but at this point, do those companies actually care about aggressive lock-in? - Apple seems to be more ignoring the possibility of SwiftUI on other platforms rather than actively preventing it since https://github.com/Cosmo/OpenSwiftUI https://github.com/Cosmo/OpenSwiftUI (dead) exists. Sure, they will never help to make it happen, but "don't want"? - Google is pretty much cross-platform/-ecosystem with Flutter which explicitly supports iOS. - MS seems to have given up with Win Forms opensourced and working on .NET Core / Mono.
    - fsloth 6y ago
      "MS seems to have given up with Win Forms opensourced and working on .NET Core / Mono." MS does not care what OS you use anymore. They want users of all operating systems to order their Office 365 license and run all their cloud compute loads in Azure.
    - dvfjsdhgfv 6y ago
      You won' probably catch any exec from MS and Apple admitting the obvious, but it's really against their best interest to encourage multi-platform apps as this would give users a choice between operating systems. It's not something that is discussed a lot these days because modern web apps are quite powerful, yet it's clear a good quality multi-platform toolkit would be a boon to users and developers alike. As for MS open sourcing .NET Core it's all good and nice, but WinForms and WPF are still Windows-only, and according to MS they will remain this way. And Apple has no intentions of doing the same with SwiftUI.
      - viraptor 6y ago
        I haven't tried to use it in anger, but https://www.mono-project.com/docs/gui/winforms/ https://www.mono-project.com/docs/gui/winforms/ "Support for Winforms 1.1 and 2.0 has been completed, and is now in a maintenance/bug fixing state." "System.Windows.Forms implements its own driver interface to communicate with the host OS windowing system. Currently, we have drivers for X11, Win32, and macOS. These drivers translate the native window messages into WndProc compatible messages, to provide as much compatibility with native .Net as possible." WPF is windows-only though.
pjmlp 6y ago
The workarounds one goes through to avoid native frameworks. "Hands-On GUI Application Development in Go: Build responsive, cross-platform, graphical applications with the Go programming language" https://www.amazon.de/-/en/Andrew-Williams-ebook/dp/B07GYLYSCT https://www.amazon.de/-/en/Andrew-Williams-ebook/dp/B07GYLYS...
- jmnicolas 6y ago
  If you want to have a multi platform (desktop) app, the only decent (imo) framework is QT. So now your app is either GPL or you fork something like 5 grands ...
  - pjmlp 6y ago
    Yeah, lets not pay the others for the fruits of their labour.
    - beojan 6y ago
      It would be misleading to call Qt the fruits of the labour of (the current) Qt Company. It is licensed under the LGPL though (however much its current owners may want to change this, they can't because of the KDE Free Qt agreement), which means you don't have to pay. All you have to do is dynamically link to the library instead of statically linking.
      - pjmlp 6y ago
        It is surely more than those leeching Qt for their own projects. The major contributors for Qt have always been the same regardless of the legal name of Qt owner. It is quite easy decision process, don't want to pay for Qt's development, use LGPL and GPL variants earn as much money as one is willing to give upstream. Decide to go commercial, then pay accordingly upstream.
        beojan 6y ago
        I think you misunderstand me, I think the LGPL is a perfectly good license for Qt and I have little sympathy for those who aren't willing to abide by it (not least because Qt is a rather large library, and there's no excuse for every application to load its own copy). > Decide to go commercial, then pay accordingly upstream. Hmm. The commercial license actually prohibits starting development under one of the open source licenses then switching to commercial. If you start under an open source license, you'll need to abide by the LGPL if you decide to go closed source (and of course what you've already released remains open source).
deleted 6y ago
[deleted]
eivarv 6y ago
In general, why would one take this approach of embedding a browser, compiling to WASM, etc. over a native UI? I'm genuinely curious why/when this is a better solution.
- krageon 6y ago
  Building native UIs cross-platform is a huge PITA and frequently the frameworks are also very annoying to use. I don't condone the use of browsers for desktop software because it is a travesty, but it is very understandable when you look at how we got here.
  - techntoke 6y ago
    Ad companies insistent on spying while funding JS development schools?
  - Gibbon1 6y ago
    You watch .Net core is going to curb stomp all that kind of crap.
    - sime2009 6y ago
      Can you explain how for those of us who don't follow .Net very closely?
      - krageon 6y ago
        It doesn't, because .net core doesn't ship with cross-platform GUI toolkits. You have the usual options, which are all bad.
        fassssst 6y ago
        https://devblogs.microsoft.com/dotnet/introducing-net-multi-platform-app-ui/ https://devblogs.microsoft.com/dotnet/introducing-net-multi-...
deleted 6y ago
[deleted]
AnonsLadder 6y ago
Well done, I too am building a desktop app in Go, I couldn't find a decent GUI library and just resorted to packing a webserver & static files into my program instead. For the time being anyway, still looking for Gui options. Figured I could make a creative html/css UI instead of figuring out how to create a GUI. I'd like to mess with Qt but the GUI builder is with their paid licensing iirc i think, but it seems to be the only cross-platform solution afaik
- justinclift 6y ago
  > I'd like to mess with Qt but the GUI builder is with their paid licensing iirc i think, Are you meaning the UI designer built into Qt Creator?
- jcelerier 6y ago
  > I'd like to mess with Qt but the GUI builder is with their paid licensing iirc i think, but it seems to be the only cross-platform solution afaik {apt, brew cask, choco} install qtcreator it's entirely free & open-source. there is Qt Designer Studio which adds a couple of convenience functionalities if you are making e.g. embedded appliance dashboards but for 100% of desktop UIs you have everything needed in the LGPL qtcreator
  - AnonsLadder 6y ago
    Thanks for mentioning, absolute game changer for me. I'm now using qtcreator with Go bindings: https://github.com/therecipe/qt https://github.com/therecipe/qt The multi-arch & especially Android deployment feature is exactly what I needed, I can skip using Android-Studio/HTML as UI now
zachrip 6y ago
But I don’t want to write JavaScript(!) and deal with all the complexities that comes with it like npm, webpack, typescript… Fortunately, I can just compile GoLang to WebAssembly (WASM) Okay... Large WASM binaries (especially from GoLang): these take a long time to send over the network increasing loading times. In a desktop app the binary isn’t transferred over the network, so less overhead. I forgot that you don't have to download desktop apps, they just appear! Browser incompatibility: Some WebAssembly methods are unavailable in browsers and older browsers are not supported at all. In a desktop app the “browser” is controlled (Chrome for Lorca and Safari for webview), so no compatibility issues. Electron??? This just seems like you built a less easy to use bundling/development platform than js/webpack/etc and claimed it was better when I'd argue it's way less mainstream and thus less accessible. Not to mention you could've just used native ui like others are talking about. Seems like the worst of both worlds to me.
- rkwz 6y ago
  I wrote a simple webapp using Rust (Wasm, Yew) and the payload is 130KB gzipped - https://rustmart-yew.netlify.app/ https://rustmart-yew.netlify.app/ Repo: https://github.com/sheshbabu/rustmart-yew-example https://github.com/sheshbabu/rustmart-yew-example
- abhink 6y ago
  > I forgot that you don't have to download desktop apps, they just appear! This seems disingenuous, given how clear the difference of bandwidth utilization between a web app and a desktop app is during setup.
Philip-J-Fry 6y ago
Personally I'm a big fan of https://github.com/wailsapp/wails/ https://github.com/wailsapp/wails/ It uses native webview so no electron. Let's you effortlessly bind JS functions to those in Go. V2 is in the works and will effectively bring the best features of electron window management (menus, frameless windows, drag regions etc) over to native webview. Currently uses IE11 on Win 10 but V2 will only support Edge so you get WebKit across the board.
- FeistyOtter 6y ago
  I am only familiar with Electron (due to its hype), what is native webview, is it like a browser? If yes why is it better? Asking as someone who has never developed any desktop apps.
  - Philip-J-Fry 6y ago
    It uses what is built into the OS, the native UI control which renders web pages. It doesn't need to download a whole 200mb Chromium or anything like that. So your binaries can be really small too. Seems like faster start up times also.
  - flohofwoe 6y ago
    It's a minimal native application which creates a window with an HTML widget in it, essentially a mini-browser wrapped in a native application. The difference to Electron is that this browser isn't a bundled Chromium, but the browser engine that's integrated with the operating system (Edge on Windows, WebKit on macOS and Linux), so the application installer is much, much smaller. When I tinkered with https://github.com/webview/webview https://github.com/webview/webview on macOS a minimal Hello World application was around 26 kBytes (kilo, not mega), which is about 7000x smaller than a default macOS Electron instance (173 MBytes).
    - philsnow 6y ago
      > this browser isn't a bundled Chromium, but the browser engine that's integrated with the operating system so I wouldn't have to worry about various electron app packages shipping with versions of Chromium from three years ago?
deleted 6y ago
[deleted]
jchw 6y ago
I just recently tried webview/webview in Go and was a little fed up with the fact that it could not be a single-binary plug & play experience on Windows. To that end, I am working on an experimental alternative that uses Webview2 directly without CGo: https://github.com/jchv/go-webview2 https://github.com/jchv/go-webview2 It still requires WebView2Loader.dll, but I am working on another library so I can just embed it directly into the application, and that work is happening over here: https://github.com/jchv/go-winloader https://github.com/jchv/go-winloader Sorry for the blatant self promotion, but I thought fellow stubborn people might have a desire to drop to as few dependencies as possible. I prefer building without CGo. The only downside is there’s not really a great way to fall back to EdgeHTML so users will need a Webview2 install, and right now Windows isn’t shipping it, but I think going forward it will be reasonable to just link users to the webview2 runtime page to go install it. (Also, it should go without saying, but this approach only improves things on Windows. You will still need other bindings for other platforms.)
- fileeditview 6y ago
  Is this a Windows-only solution or does this also work on Linux/Mac somehow?
  - jchw 6y ago
    Windows-only; Windows is really the only platform where I am concerned about making the binary very self-contained anyways. On Linux/BSD package management makes the GTK-based solution pretty reasonable. On macOS I think the webview/webview solution is already self-contained. What I'd like is to help make upstream webview/webview more self-contained somehow, but for now a possible approach is to just use go-webview2 for Windows and then webview/webview for everything else. My approaches to lower dependencies may not be accepted upstream webview/webview: direct bindings to Webview2 mean no EdgeHTML fallback + code duplication from the C bindings, and go-winloader is (WIP, it doesn't even work yet) a fairly complex piece of code that would be an additional dependency. (Just so it's clear, I do actually want to make a concerted effort to try to support an EdgeHTML fallback, but it will effectively be based on directly binding to MSVC ABI from Go, and therefore will be a lot uglier than the current Webview2 code that just deals with COM interfaces directly.)
kgersen 6y ago
see https://www.vugu.org/ https://www.vugu.org/
- grahar64 6y ago
  This is cool, didn’t find this in my googling. Like with go-app (https://github.com/maxence-charriere/go-app https://github.com/maxence-charriere/go-app) though, it is a front and backend framework that seems closely tied together. I would like to see a front-end GoLang framework that can be reused easily. Still awesome, will take a look later
ptrik 6y ago
Carlo [1] was an exciting project to hear, sad that it's no longer maintained. Glad to see Lorca [2] as a spiritual successor. [1] https://github.com/GoogleChromeLabs/carlo/ https://github.com/GoogleChromeLabs/carlo/ [2] https://github.com/zserge/lorca https://github.com/zserge/lorca
rajveermalviya 6y ago
This is great but there many drawbacks. I tried Qt but needed something native-er. After much digging got to know about gioui[1] but it also has some issues. Also Flutter[2] seems to be better fit but binding to golang is a little tough. [1]: https://gioui.org/ https://gioui.org/ [2]: https://flutter.dev/ https://flutter.dev/
- beojan 6y ago
  Nativer than Qt? You could try WxWidgets, but really unless you use the native toolkits directly, Qt is as native as it gets.
  - rajveermalviya 6y ago
    Oh yes.. I meant, completely in Golang. And as far I know gioui tries to avoid Cgo where it can.
- mmargerum 6y ago
  How is flutter "nativer"? It literally draws all the controls itself and does not use native controls? I mean it looks nice but its not native.
_lobster 6y ago
I generally recommend Sciter for desktop apps; The programming model is extremely intuitive and straightforward, and in my experience, the performance is excellent. Besides that, I'd look at something like webview
- akrymski 6y ago
  I've considered using it, how has your experience been with regards to webkit compatibility and performance? Did it render correctly out of the box?
  - _lobster 6y ago
    Yup, it renders correctly out of the box. Occasionally some small odd quirks with more complex CSS styling though. I've done lots of development with Qt and webview but saw significantly better performance in Sciter.
steeve 6y ago
Cool article! Small note: you can use rules_go's builtin go_embed_data [1] rule instead of rolling out your own using genrule. 1. https://github.com/bazelbuild/rules_go/blob/master/go/extras.rst#go_embed_data https://github.com/bazelbuild/rules_go/blob/master/go/extras...
- grahar64 6y ago
  Oh, awesome. Didn’t know that was a thing will, look at that later. Cheers
WinstonSmith84 6y ago
People complains about this setup but WASM is optional. I've been using Golang with Lorca without WASM. I actually don't see the value of WASM here.. Anyway, I used Svelte on the frontend, pretty straightforward but any other lib would have been as easy to bind. And it just... works. The main advantage over Electron is the size of the bin (~20MB for a medium app vs. >100MB if it was Electron). If you know the people who are going to use your app have Chrome installed, it's definitely better than Electron and you get the best of both worlds - quick crafted & beautiful UI and performant backend
- fileeditview 6y ago
  Sure you have the smaller distribution size. However you also have drawbacks. As you mentioned Chrome must be installed. Then you can not guarantee the Chrome version like this.. maybe the version the user has breaks your app. Also you cannot use the "native" menu and other windowing features as you can with electron. I am not really convinced by the "Lorca concept".
snarfy 6y ago
My problem with these approaches, is what's the next step? Do you implement GUI buttons on top of canvas and push pixels in WASM? Do you try and do something like ImGui and use WebGL? None of these approaches are efficient. If you are making a native app because it would be more efficient, I'm not sure what the point of this approach is.
- tyingq 6y ago
  It seems like the WASM folks have a plan to address it in the future. https://github.com/WebAssembly/proposals/issues/16 https://github.com/WebAssembly/proposals/issues/16
- fulafel 6y ago
  In the their linked previous article, they also considered Electron. So the motivation is probably not efficiency. There are many other possible requirements that get you making native apps.
- city41 6y ago
  FWIW, this approach intrigues me as a decent way to bring a web based game I am creating to places like Steam. I like it when people explore different avenues like this. Often nothing really comes of them, but you never know.
LeoNatan25 6y ago
If one is using Go/C++/whatever WASM, why not go the extra step and use a binding framework for the OS's native UI toolkit, and just produce a native app? I don't understand with the fascination of bringing an entire OS (the browser) on top of an OS.
- deleted 6y ago
  [deleted]
deleted 6y ago
[deleted]
fmakunbound 6y ago
Err, what you have there is a web app.
Maxence 6y ago
Hello, I'm super happy to see that some folks are trying to make apps with Golang. I'm myself the author of a Go package to build GUI with WASM and Go => https://github.com/maxence-charriere/go-app https://github.com/maxence-charriere/go-app WASM give us an incredible amount of new possibilities and hopefully, we will get to a point where Go will be used in production also for GUI/apps purposes :) Congrats for this and good luck for the future.
- grahar64 6y ago
  Hey, I love your go-app library! I wrote a blog post using it here https://maori.geek.nz/a-web-app-using-bazel-golang-wasm-and-proto-c020914f4341 https://maori.geek.nz/a-web-app-using-bazel-golang-wasm-and-... and have used it on multiple small experimental projects. I have plans to use your code, either as inspiration or direct dependence, for many of my future projects! Cheers :)_

154 points by grahar64 6y ago

Does this lead to a significantly smaller memory footprint than otherwise running .js in electron or a full browser? I see you've become a big fan of bazel :)

akrymski 6y ago
It's the difference between a new tab vs a new browser instance - every electron app is a new browser instance with fixed overhead of 100mb or so. A new browser tab is closer to 10mb overhead.

Jolter 6y ago

Knowing next to nothing about Golang: Is it unlikely that someone would ever develop an actual desktop toolkit for Golang? If so, how come? From a naïve point of view, it would seem like overkill to run a whole web browser when a few kilobytes of memory is all it really takes to draw a widget on screen.

dmitriid 6y ago
"all it takes to draw a widget on the screen" is not enough to create "an actual desktop toolkit". If you need to draw a widget on the screen, there's Dear ImGui [1] that you can use from Go [2] If you're looking for a desktop toolkit, there's a reason why things like Qt are multidecade endeavours. [1] https://github.com/ocornut/imgui https://github.com/ocornut/imgui [2] https://github.com/inkyblackness/imgui-go https://github.com/inkyblackness/imgui-go
grey-area 6y ago
Cross platform UI toolkits are a sisyphean task that everyone wants someone else to work on. Platform vendors like Apple, Google, MS don't want to let developers target multiple ecosystems - they want a monopoly on devs and users, hence the endless churn of languages, frameworks and SDKs, making it difficult to keep up. It's much easier and more reliable to use HTML, even if the experience isn't as slick for users.
- viraptor 6y ago
  > Platform vendors like Apple, Google, MS don't want to let developers target multiple ecosystems Is this actually true? As in, I see how we may arrive at the same outcome anyway, but at this point, do those companies actually care about aggressive lock-in? - Apple seems to be more ignoring the possibility of SwiftUI on other platforms rather than actively preventing it since https://github.com/Cosmo/OpenSwiftUI https://github.com/Cosmo/OpenSwiftUI (dead) exists. Sure, they will never help to make it happen, but "don't want"? - Google is pretty much cross-platform/-ecosystem with Flutter which explicitly supports iOS. - MS seems to have given up with Win Forms opensourced and working on .NET Core / Mono.
  - fsloth 6y ago
    "MS seems to have given up with Win Forms opensourced and working on .NET Core / Mono." MS does not care what OS you use anymore. They want users of all operating systems to order their Office 365 license and run all their cloud compute loads in Azure.
  - dvfjsdhgfv 6y ago
    You won' probably catch any exec from MS and Apple admitting the obvious, but it's really against their best interest to encourage multi-platform apps as this would give users a choice between operating systems. It's not something that is discussed a lot these days because modern web apps are quite powerful, yet it's clear a good quality multi-platform toolkit would be a boon to users and developers alike. As for MS open sourcing .NET Core it's all good and nice, but WinForms and WPF are still Windows-only, and according to MS they will remain this way. And Apple has no intentions of doing the same with SwiftUI.
    - viraptor 6y ago
      I haven't tried to use it in anger, but https://www.mono-project.com/docs/gui/winforms/ https://www.mono-project.com/docs/gui/winforms/ "Support for Winforms 1.1 and 2.0 has been completed, and is now in a maintenance/bug fixing state." "System.Windows.Forms implements its own driver interface to communicate with the host OS windowing system. Currently, we have drivers for X11, Win32, and macOS. These drivers translate the native window messages into WndProc compatible messages, to provide as much compatibility with native .Net as possible." WPF is windows-only though.

pjmlp 6y ago

The workarounds one goes through to avoid native frameworks. "Hands-On GUI Application Development in Go: Build responsive, cross-platform, graphical applications with the Go programming language" https://www.amazon.de/-/en/Andrew-Williams-ebook/dp/B07GYLYSCT https://www.amazon.de/-/en/Andrew-Williams-ebook/dp/B07GYLYS...

jmnicolas 6y ago
If you want to have a multi platform (desktop) app, the only decent (imo) framework is QT. So now your app is either GPL or you fork something like 5 grands ...
- pjmlp 6y ago
  Yeah, lets not pay the others for the fruits of their labour.
  - beojan 6y ago
    It would be misleading to call Qt the fruits of the labour of (the current) Qt Company. It is licensed under the LGPL though (however much its current owners may want to change this, they can't because of the KDE Free Qt agreement), which means you don't have to pay. All you have to do is dynamically link to the library instead of statically linking.
    - pjmlp 6y ago
      It is surely more than those leeching Qt for their own projects. The major contributors for Qt have always been the same regardless of the legal name of Qt owner. It is quite easy decision process, don't want to pay for Qt's development, use LGPL and GPL variants earn as much money as one is willing to give upstream. Decide to go commercial, then pay accordingly upstream.
      - beojan 6y ago
        I think you misunderstand me, I think the LGPL is a perfectly good license for Qt and I have little sympathy for those who aren't willing to abide by it (not least because Qt is a rather large library, and there's no excuse for every application to load its own copy). > Decide to go commercial, then pay accordingly upstream. Hmm. The commercial license actually prohibits starting development under one of the open source licenses then switching to commercial. If you start under an open source license, you'll need to abide by the LGPL if you decide to go closed source (and of course what you've already released remains open source).

deleted 6y ago

[deleted]

eivarv 6y ago

In general, why would one take this approach of embedding a browser, compiling to WASM, etc. over a native UI? I'm genuinely curious why/when this is a better solution.

krageon 6y ago
Building native UIs cross-platform is a huge PITA and frequently the frameworks are also very annoying to use. I don't condone the use of browsers for desktop software because it is a travesty, but it is very understandable when you look at how we got here.
- techntoke 6y ago
  Ad companies insistent on spying while funding JS development schools?
- Gibbon1 6y ago
  You watch .Net core is going to curb stomp all that kind of crap.
  - sime2009 6y ago
    Can you explain how for those of us who don't follow .Net very closely?
    - krageon 6y ago
      It doesn't, because .net core doesn't ship with cross-platform GUI toolkits. You have the usual options, which are all bad.
      - fassssst 6y ago
        https://devblogs.microsoft.com/dotnet/introducing-net-multi-platform-app-ui/ https://devblogs.microsoft.com/dotnet/introducing-net-multi-...

deleted 6y ago

[deleted]

AnonsLadder 6y ago

Well done, I too am building a desktop app in Go, I couldn't find a decent GUI library and just resorted to packing a webserver & static files into my program instead. For the time being anyway, still looking for Gui options. Figured I could make a creative html/css UI instead of figuring out how to create a GUI. I'd like to mess with Qt but the GUI builder is with their paid licensing iirc i think, but it seems to be the only cross-platform solution afaik

justinclift 6y ago
> I'd like to mess with Qt but the GUI builder is with their paid licensing iirc i think, Are you meaning the UI designer built into Qt Creator?
jcelerier 6y ago
> I'd like to mess with Qt but the GUI builder is with their paid licensing iirc i think, but it seems to be the only cross-platform solution afaik {apt, brew cask, choco} install qtcreator it's entirely free & open-source. there is Qt Designer Studio which adds a couple of convenience functionalities if you are making e.g. embedded appliance dashboards but for 100% of desktop UIs you have everything needed in the LGPL qtcreator
- AnonsLadder 6y ago
  Thanks for mentioning, absolute game changer for me. I'm now using qtcreator with Go bindings: https://github.com/therecipe/qt https://github.com/therecipe/qt The multi-arch & especially Android deployment feature is exactly what I needed, I can skip using Android-Studio/HTML as UI now

zachrip 6y ago

But I don’t want to write JavaScript(!) and deal with all the complexities that comes with it like npm, webpack, typescript… Fortunately, I can just compile GoLang to WebAssembly (WASM) Okay... Large WASM binaries (especially from GoLang): these take a long time to send over the network increasing loading times. In a desktop app the binary isn’t transferred over the network, so less overhead. I forgot that you don't have to download desktop apps, they just appear! Browser incompatibility: Some WebAssembly methods are unavailable in browsers and older browsers are not supported at all. In a desktop app the “browser” is controlled (Chrome for Lorca and Safari for webview), so no compatibility issues. Electron??? This just seems like you built a less easy to use bundling/development platform than js/webpack/etc and claimed it was better when I'd argue it's way less mainstream and thus less accessible. Not to mention you could've just used native ui like others are talking about. Seems like the worst of both worlds to me.

rkwz 6y ago
I wrote a simple webapp using Rust (Wasm, Yew) and the payload is 130KB gzipped - https://rustmart-yew.netlify.app/ https://rustmart-yew.netlify.app/ Repo: https://github.com/sheshbabu/rustmart-yew-example https://github.com/sheshbabu/rustmart-yew-example
abhink 6y ago
> I forgot that you don't have to download desktop apps, they just appear! This seems disingenuous, given how clear the difference of bandwidth utilization between a web app and a desktop app is during setup.

Philip-J-Fry 6y ago

Personally I'm a big fan of https://github.com/wailsapp/wails/ https://github.com/wailsapp/wails/ It uses native webview so no electron. Let's you effortlessly bind JS functions to those in Go. V2 is in the works and will effectively bring the best features of electron window management (menus, frameless windows, drag regions etc) over to native webview. Currently uses IE11 on Win 10 but V2 will only support Edge so you get WebKit across the board.

FeistyOtter 6y ago
I am only familiar with Electron (due to its hype), what is native webview, is it like a browser? If yes why is it better? Asking as someone who has never developed any desktop apps.
- Philip-J-Fry 6y ago
  It uses what is built into the OS, the native UI control which renders web pages. It doesn't need to download a whole 200mb Chromium or anything like that. So your binaries can be really small too. Seems like faster start up times also.
- flohofwoe 6y ago
  It's a minimal native application which creates a window with an HTML widget in it, essentially a mini-browser wrapped in a native application. The difference to Electron is that this browser isn't a bundled Chromium, but the browser engine that's integrated with the operating system (Edge on Windows, WebKit on macOS and Linux), so the application installer is much, much smaller. When I tinkered with https://github.com/webview/webview https://github.com/webview/webview on macOS a minimal Hello World application was around 26 kBytes (kilo, not mega), which is about 7000x smaller than a default macOS Electron instance (173 MBytes).
  - philsnow 6y ago
    > this browser isn't a bundled Chromium, but the browser engine that's integrated with the operating system so I wouldn't have to worry about various electron app packages shipping with versions of Chromium from three years ago?

deleted 6y ago

[deleted]

jchw 6y ago

I just recently tried webview/webview in Go and was a little fed up with the fact that it could not be a single-binary plug & play experience on Windows. To that end, I am working on an experimental alternative that uses Webview2 directly without CGo: https://github.com/jchv/go-webview2 https://github.com/jchv/go-webview2 It still requires WebView2Loader.dll, but I am working on another library so I can just embed it directly into the application, and that work is happening over here: https://github.com/jchv/go-winloader https://github.com/jchv/go-winloader Sorry for the blatant self promotion, but I thought fellow stubborn people might have a desire to drop to as few dependencies as possible. I prefer building without CGo. The only downside is there’s not really a great way to fall back to EdgeHTML so users will need a Webview2 install, and right now Windows isn’t shipping it, but I think going forward it will be reasonable to just link users to the webview2 runtime page to go install it. (Also, it should go without saying, but this approach only improves things on Windows. You will still need other bindings for other platforms.)

fileeditview 6y ago
Is this a Windows-only solution or does this also work on Linux/Mac somehow?
- jchw 6y ago
  Windows-only; Windows is really the only platform where I am concerned about making the binary very self-contained anyways. On Linux/BSD package management makes the GTK-based solution pretty reasonable. On macOS I think the webview/webview solution is already self-contained. What I'd like is to help make upstream webview/webview more self-contained somehow, but for now a possible approach is to just use go-webview2 for Windows and then webview/webview for everything else. My approaches to lower dependencies may not be accepted upstream webview/webview: direct bindings to Webview2 mean no EdgeHTML fallback + code duplication from the C bindings, and go-winloader is (WIP, it doesn't even work yet) a fairly complex piece of code that would be an additional dependency. (Just so it's clear, I do actually want to make a concerted effort to try to support an EdgeHTML fallback, but it will effectively be based on directly binding to MSVC ABI from Go, and therefore will be a lot uglier than the current Webview2 code that just deals with COM interfaces directly.)

kgersen 6y ago

see https://www.vugu.org/ https://www.vugu.org/

grahar64 6y ago
This is cool, didn’t find this in my googling. Like with go-app (https://github.com/maxence-charriere/go-app https://github.com/maxence-charriere/go-app) though, it is a front and backend framework that seems closely tied together. I would like to see a front-end GoLang framework that can be reused easily. Still awesome, will take a look later

ptrik 6y ago

Carlo [1] was an exciting project to hear, sad that it's no longer maintained. Glad to see Lorca [2] as a spiritual successor. [1] https://github.com/GoogleChromeLabs/carlo/ https://github.com/GoogleChromeLabs/carlo/ [2] https://github.com/zserge/lorca https://github.com/zserge/lorca

rajveermalviya 6y ago

This is great but there many drawbacks. I tried Qt but needed something native-er. After much digging got to know about gioui[1] but it also has some issues. Also Flutter[2] seems to be better fit but binding to golang is a little tough. [1]: https://gioui.org/ https://gioui.org/ [2]: https://flutter.dev/ https://flutter.dev/

beojan 6y ago
Nativer than Qt? You could try WxWidgets, but really unless you use the native toolkits directly, Qt is as native as it gets.
- rajveermalviya 6y ago
  Oh yes.. I meant, completely in Golang. And as far I know gioui tries to avoid Cgo where it can.
mmargerum 6y ago
How is flutter "nativer"? It literally draws all the controls itself and does not use native controls? I mean it looks nice but its not native.

_lobster 6y ago

I generally recommend Sciter for desktop apps; The programming model is extremely intuitive and straightforward, and in my experience, the performance is excellent. Besides that, I'd look at something like webview

akrymski 6y ago
I've considered using it, how has your experience been with regards to webkit compatibility and performance? Did it render correctly out of the box?
- _lobster 6y ago
  Yup, it renders correctly out of the box. Occasionally some small odd quirks with more complex CSS styling though. I've done lots of development with Qt and webview but saw significantly better performance in Sciter.

steeve 6y ago

Cool article! Small note: you can use rules_go's builtin go_embed_data [1] rule instead of rolling out your own using genrule. 1. https://github.com/bazelbuild/rules_go/blob/master/go/extras.rst#go_embed_data https://github.com/bazelbuild/rules_go/blob/master/go/extras...

grahar64 6y ago
Oh, awesome. Didn’t know that was a thing will, look at that later. Cheers

WinstonSmith84 6y ago

People complains about this setup but WASM is optional. I've been using Golang with Lorca without WASM. I actually don't see the value of WASM here.. Anyway, I used Svelte on the frontend, pretty straightforward but any other lib would have been as easy to bind. And it just... works. The main advantage over Electron is the size of the bin (~20MB for a medium app vs. >100MB if it was Electron). If you know the people who are going to use your app have Chrome installed, it's definitely better than Electron and you get the best of both worlds - quick crafted & beautiful UI and performant backend

fileeditview 6y ago
Sure you have the smaller distribution size. However you also have drawbacks. As you mentioned Chrome must be installed. Then you can not guarantee the Chrome version like this.. maybe the version the user has breaks your app. Also you cannot use the "native" menu and other windowing features as you can with electron. I am not really convinced by the "Lorca concept".

snarfy 6y ago

My problem with these approaches, is what's the next step? Do you implement GUI buttons on top of canvas and push pixels in WASM? Do you try and do something like ImGui and use WebGL? None of these approaches are efficient. If you are making a native app because it would be more efficient, I'm not sure what the point of this approach is.

tyingq 6y ago
It seems like the WASM folks have a plan to address it in the future. https://github.com/WebAssembly/proposals/issues/16 https://github.com/WebAssembly/proposals/issues/16
fulafel 6y ago
In the their linked previous article, they also considered Electron. So the motivation is probably not efficiency. There are many other possible requirements that get you making native apps.
city41 6y ago
FWIW, this approach intrigues me as a decent way to bring a web based game I am creating to places like Steam. I like it when people explore different avenues like this. Often nothing really comes of them, but you never know.

LeoNatan25 6y ago

If one is using Go/C++/whatever WASM, why not go the extra step and use a binding framework for the OS's native UI toolkit, and just produce a native app? I don't understand with the fascination of bringing an entire OS (the browser) on top of an OS.

deleted 6y ago
[deleted]

deleted 6y ago

[deleted]

fmakunbound 6y ago

Err, what you have there is a web app.

Maxence 6y ago

Hello, I'm super happy to see that some folks are trying to make apps with Golang. I'm myself the author of a Go package to build GUI with WASM and Go => https://github.com/maxence-charriere/go-app https://github.com/maxence-charriere/go-app WASM give us an incredible amount of new possibilities and hopefully, we will get to a point where Go will be used in production also for GUI/apps purposes :) Congrats for this and good luck for the future.

grahar64 6y ago
Hey, I love your go-app library! I wrote a blog post using it here https://maori.geek.nz/a-web-app-using-bazel-golang-wasm-and-proto-c020914f4341 https://maori.geek.nz/a-web-app-using-bazel-golang-wasm-and-... and have used it on multiple small experimental projects. I have plans to use your code, either as inspiration or direct dependence, for many of my future projects! Cheers :)_