Create Desktop Apps with HTML5 and Go

(phoronix.com)

115 points | by folknor 3 days ago

20 comments

  • rolleiflex 3 days ago

    I'm doing something similar (Go-based desktop app) with Aether (https://getaether.net), without requiring any additional tools.

    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.

    Here's the source code: https://github.com/nehbit/aether

    • tracker1 3 days ago

      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.

      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

      • kjksf 3 days ago

        The project they describe IS a Go port of carlo (it's even named lorca).

        carlo/lorca is meaningfully different than electron.

        Electron takes chrome code base, adds node.js code, a bunch of other stuff and makes it an SDK. As a result Electron-based app consists of a copy of chrome a copy of node and maybe 2% of the total size is unique to the app.

        carlo/lorca re-use Chrome instance already installed so 100% of the size is unique to the app.

        That removes the biggest complaint about electron i.e. bloat of shipping 100+ MB of SDK to deliver 100 kB of app.

        • chatmasta 3 days ago

          I think the biggest complaint about electron is not bloat of shipping the app (a one time download, not a big deal in modern times), but running the app. Since each electron program uses its own instance of Chrome, there is no resource sharing and so memory consumption is high.

          • bpye 2 days ago

            Absolutely. I don't really care about the size on disk, a little bit, but not really. What I really care about is some application using far too much RA - Chrome (and by extension Electron) is notourious.

          • andreareina 2 days ago

            So if I don't already have Chrome I now have to install it?

            • kjksf 2 days ago

              What lorca does: it shows a message box telling the user to download chrome.

              What is possible and easy (and what I would do if I was shipping an app using it): silently download chrome on first run if Chrome is not already downloaded.

              That's an obviously good idea from the point of view of the user.

              • andreareina 2 days ago

                I would not be happy if some bit of software "helpfully" downloaded a copy of Chrome for me.

                • PunchTornado 2 days ago

                  silently download chrome is a good idea?

                  why don't you tell the user if it wants Google's browser on his computer?

              • tracker1 2 days ago

                I'm not against it... just the way it was presented was supposed to be so much bigger in terms of runtime. So the biggest complaints against electron/chrome still hold.

                Didn't catch the carlo/lorca naming thing. And, tbh, I'm all for it... I think electron is slightly better in some ways as I like the idea of one language everywhere, but that's less an issue.

              • solarkraft 3 days ago

                It's a fair argument that browser based UIs are not the best in all areas (resource usage, reliability ...), but an area where they win is effort needed to make them good enough or even nice simply due to its popularity.

                And I certainly prefer an app launching my browser to show its UI over it bundling a whole fucking browser.

                > You have to conform to ???

                Web applications are able to work in browsers.

                • tracker1 2 days ago

                  Personally, I like electron and web apps... the approach from TFA mentions it being lighter weight than Electron... when the actual running engine for both is still Chrome, which is the biggest complaint from detractors.

                  I'm a fan of the model and have used embedded browsers for UI for years, even for embedded kiosks as localization tended to be easier to handle for the translaters, etc.

                  I'm just suggesting that you can make assumptions when packaging against a specific version of electron, where a chrome install from a couple years ago may not have the features you are wanting to use.

              • JeanMarcS 3 days ago

                Well, on one hand it will certainly lighten the ressources needed.

                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.

                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)

                • johnisgood 3 days ago

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

                  Is it just me, or the API changes and breaks way too often? I recently wanted to make an extension and I Google'd here and there, and all the code posted just a few months ago is now obsolete. It is crazy!

                  • giancarlostoro 3 days ago

                    I think WebExtensions might be to blame for that, but without more information as to what wasn't working I couldn't say.

                  • solarkraft 3 days ago

                    > you won’t be able to use specific API for sure

                    How about W3C standards?

                    • JeanMarcS 2 days ago

                      For just visualizing your document, sure.

                      I was thinking of my webkiosk software where Interfaces on Internet Explorer changed with version (but thankfully Microsoft provided compatibility).

                      But as long as the Event / API / I don't really know how it works with Chrome / Whatever way to get the Before Navigate information (and be able to stop it) still works from a version to another, W3C standard would suffice for the majority of cases

                    • Scarbutt 3 days ago

                      You can rely on chrome/chromium => 70.

                    • candiodari 3 days ago

                      Man, that slidedeck is frightening for someone who wants functional applications:

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

                      But I could not explain this half as well as these articles about Flash. They also apply to HTML5.

                      https://www.nngroup.com/articles/flash-99-percent-bad/

                      • zbruhnke 3 days ago

                        Every time I see these things I just sit in relative disbelief trying to figure out how PWAs have somehow not taken off yet.

                        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.

                        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

                        • danShumway 3 days ago

                          PWAs still have lots of problems. There are multiple issues, but IMO one of the biggest is that storage on the web is bad. We've gotten a lot of iteration on this, there are tons of ways to store information on a website. But none of them have offered really substantial gains over each other.

                          - All of them can be cleared directly from the browser, which might happen as a part of regular cleanup. This can happen on the desktop, but is much less likely to happen. Usually if a text file or image gets deleted from the desktop, the user deleted it. If localstorage gets cleared, maybe an extension deleted it. Or maybe the user just has "clear all data on exit" checked for the browser.

                          - There's no way for me as a user to easily clear out part of that storage, unless the app builds in its own tools to do so. Managing the storage in general is cumbersome -- quick, without looking can you tell me how to clear local storage for a specific site in Firefox without visiting the web site?

                          - None of them are easily accessible across browsers. So if a user accesses your website in Chrome and then opens it up again in Firefox, it's kind of a pain to move something like local storage over. Certainly, it's not something the user can easily control.

                          - None of them are easily accessible from native apps. Think about something like Atom, which couldn't really work on the web even in a paired down form unless it prompted you to manually download every file you edited.

                          - None of them are easily backed up and transferred across computers. At best, you'll get some kind of browser sync that's tied to an online account. But it's not trivial for an average user to say, "hey, I'm going to put the storage for this site on a USB drive and plug it into a new computer." If you're bundling software as an electron app, you could run the entire thing from a USB drive.

                          The way most sites get around this is they have online accounts that sync things and back things up. This is (again IMO) sub-optimal. It makes web apps more complicated, it forces them to require an Internet connection (it's all well and good to hook up a service worker to your site, but without good file storage you can't really make an offline-only app). It requires users to give up control of their data, and to supply personal information to use your app. It makes everything more expensive -- what would Atom look like if all of your code was getting synced to a remote server somewhere?

                          I understand that local file access is ridiculously dangerous. It's a huge can of worms that could be a disaster on the web if done poorly, and I absolutely don't trust anyone except maybe Mozilla to get it even mildly right. But I do think even with all of that danger, if we want the web to transition towards PWAs and protocols that value user-control over hosting and data (IPFS for example), we need to consider adding some kind of user-accessible file-based storage to the web. Something where I can open a web app in any browser, point it at a directory, and have it write files to that directory that can be accessed by native software I control.

                          It doesn't have to literally be, "let web browsers just start writing stuff to my hard drive." That would be stupid. But we should try to think of something.

                          The alternative is that the only services that actually work on the web are server-backed apps that require you to give up your data and that don't integrate well with other programs. And any (web) app where that's not feasible or where the developer cares about user privacy will be bundled into gigantic, resource-hungry Electron frameworks.

                          • solarkraft 3 days ago

                            May I ask what you use to install a PWA on Linux? I am so far using WebPin, but it doesn't offer some PWA APIs and is based on Chrome instead of Firefox.

                            • enobrev 2 days ago

                              Chrome seems to allow it after enabling it in chrome://flags. The only desktop-installable PWA I've been able to find thus far is pokedex. Pretty cool to see it show up like any other app on ubuntu, though.

                          • alexandernst 3 days ago

                            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.

                            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.

                            • imustbeevil 3 days ago

                              What application renders HTML/CSS/JS using less resources than a browser?

                              • 2 days ago
                                [deleted]
                                • opan 3 days ago

                                  A document reader, perhaps. Something like zathura/mupdf that can read epub files. I think epubs use html/css for formatting. I could be a bit wrong here.

                                  • shakna 2 days ago

                                    Yes/no.

                                    Epub 3.x does support a substantial subset of HTML5. However, there are only a small number of core media types that can come with an expectation of working.

                                    Atop of that, most styling can be expected to be ignored.

                                    The CSS-section of the spec [0] lays out most CSS fits the spec, with a few exceptions, and a few additions, but that most readers won't make use of them. That is absolutely the case.

                                    Most of the speed from an ereader over a browser comes from these parts:

                                    + You can safely ignore most CSS, or all CSS and just use Author-Defined CSS profiles.

                                    + You can safely ignore any of the script tags you encounter, though they are part of the spec.

                                    + You don't need to support every media-type out there.

                                    + Most documents won't be HTML - they'll be the well-defined XHTML, meaning you need less cascading rules to transform the document into something well-formed.

                                    [0] http://www.idpf.org/epub/31/spec/epub-contentdocs.html#sec-c...

                                  • johnisgood 3 days ago

                                    Would something like libRocket work? Sadly it is not under active development anymore.

                                • chenzhekl 2 days ago

                                  In case you are interested, there is a flutter based GUI framework for Go, which looks promising. https://github.com/Drakirus/go-flutter-desktop-embedder/blob...

                                  • spacenick88 3 days ago

                                    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.

                                    • kjksf 3 days ago

                                      The way this works: that the program locates chrome executable, launches it in a special mode, chrome prints which port it allocated for that instance to stdout, the program parses stdout to find the port and opens websocket connection.

                                      See: https://github.com/zserge/lorca/blob/master/chrome.go#L50

                                      How would that be intercepted? Only the program that launches that chrome instance can read chrome's stdout.

                                      It's no more or less secure than the same concern with a regular Chrome.

                                    • mikewhy 3 days ago

                                      Webview seems interesting. Go/C++ to do native stuff and use the systems web view to render the interface. Seems like the best of both worlds.

                                      • AnIdiotOnTheNet 3 days ago

                                        It is a bit weird to me that people are so intent on reinventing HTAs.

                                      • sfifs 3 days ago

                                        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.

                                        • marticode 3 days ago

                                          Alternative that uses the system webview rather than requiring Chrome: https://github.com/zserge/webview

                                          • chmike 2 days ago

                                            HTML is really bad to create GUI applications, and it uses javascript. It's not a pure Go desktop application.

                                            A Qt equivalent in go would be worth considering.

                                            • zemnmez 3 days ago

                                              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

                                              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

                                              edit: this happened already with node in the case of CVE-2018-7160

                                              • irq-1 3 days ago

                                                There is also https://sciter.com/

                                                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.

                                                https://github.com/sciter-sdk/go-sciter

                                                • api 2 days ago

                                                  An alternative is this:

                                                  https://github.com/andlabs/libui

                                                  There are Go bindings here:

                                                  https://github.com/andlabs/ui

                                                  • 3 days ago
                                                    [deleted]
                                                    • lucasmullens 3 days ago

                                                      Is it worth mentioning the 5 specifically anymore? It doesn't seem to be even using HTML5 features.

                                                    • steve1977 2 days ago

                                                      Or, don't.

                                                      • __alias 3 days ago

                                                        Electron is bad? Your website is bad and I don't trust anyone with a bad website