Turn A Webpage Into A Desktop App With Gluon

Screenshot of the framework-built app, showing it running through Firefox

Electron is software for running web-written apps in the same way as native ones, and has gotten plenty of bad press for its RAM appetite around these parts. But while the execution might leave something to be desired, the concept itself is quite solid —  if you’ve already got code written for the web, a quick and easy way to bring it over to the desktop would be very valuable.

Which is why [CanadaHonk] is building a framework called Gluon, which aims to turn your web pages into desktop apps with little to no effort. We’ve seen their work a few months ago with the OpenASAR project, hacking the Discord desktop app to speed it up. Drawing from that experience, Gluon is built to be lean – with apps having low RAM and storage footprints, lightning-speed build times, and a no-nonsense API.

One of the coolest parts is that it’s able to use your system-installed browser, and not a bundled-in one like Electron. Firefox support is firmly on the roadmap, too, currently in experimental stage. Linux support is being worked on as well — the framework is Windows-born, but that’s to change. There’s also room to innovate; [CanadaHonk] recently added a hibernation feature with aggressive RAM and CPU footprint reduction when the app is minimized, something that other frameworks like this aren’t known for.

If you want to write user-facing software, JavaScript’s a decent language, and quite a few of you are going to be familiar with it. You aren’t limited to the software side of the tech world, either — tools like WebUSB and WebSerial will let you write a user interface for a board that you’ve just developed. For instance, here’s a WebSerial-based oscilloscope, a nifty serial terminal, or a hacker conference badge programming toolkit. For all that browsers have gotten wrong, they certainly don’t seem to become less abundant, and if that means you can quickly develop cross-platform hardware-facing apps, it’s certainly a useful addition to one’s toolkit.

38 thoughts on “Turn A Webpage Into A Desktop App With Gluon

    1. Care to elaborate? Are talking flat earth, perpetual motion loony or disagrees with me politically loony? If it’s the former, what relevance does it have w.r.t. the article? If it’s the latter, please grow up…

    1. using browser-based apps allows me to use them on my de-googled Android without having to resort to download clutter from apkpure.
      But there are probably myriads of other reasons to like browser-based apps.

    1. That’s largely down to the implementation, electron being the big issue. An electron app is clunky and slow without the app loaded, just because of electron. There’s no reason it can’t be done well.

    1. Any system with a current python3 installation can do a CGI web app without apache. Python3 has several built-in http server support modules, and supports CGI web applications without difficulty. I use it to avoid all the work of apache configuration to let me test updates to the ancient CGI-based appointment tracking web app I wrote for my wife’s psychology practice. Very convenient.

      That said, someday I should update her app to something more modern (Flask? CherryPy?). Trouble is that the app is responsive enough using ye olde technology that I seem always to have higher priorities…

  1. Web browser based Apps are the future. Fact.
    It allows for truly cross compatibility, it has support for different display formats (screen sizes), accessibility built in, multi regional support and there are thousands of frameworks for beautiful and responsive GUI.

    1. “fact” – you made my day. 😂
      Unless an apocalyptic event will break our digital infrastructures.
      The whole internet/5G nonsense is very fragile.

      We’ve traveled far away from the redundancy of Arpanet. One or two of the backbone servers removed and everything falls apart.

      Take away DNS name resolving and users don’t know how to reach websites anymore. Heck, most can’t even remember IPv6 address and are stuck in IPv4 days, mentally.

      I wouldn’t be surprised if lonely USB pen drives in brick walls will outlive the internet eventually (so called “dead drops”).

      Let’s just remember what Einstein said:
      “I do not know with what weapons World War III will be fought, but World War IV will be fought with sticks and stones.”

    2. That’s a pretty flawed argument, isn’t it? GTK and Qt both provide primitives for responsiveness, internationalization and accessibility. And while web tools alleviate the developer load when it comes to cross-platform apps, they don’t do everything, many system APIs will require you to use platform-specific code.

      All in all, it depends on what you’re trying to build, when it comes to tech choices, there rarely is a clear-cut answer.

  2. The key to PWA is the Progressive part: it still launches your browser of choice but allows additional features such as local storage access, web workers and a synchronous data management (ie. Store and work locally if a network connection is not available). All application logic is still downloaded over the wire. Electron (and presumably Gluon) install a separate copy of the browser engine and business logic which means conceptually from a DX side it is more like coding for Java as the browser engine has dealt with the cross platform compatibility. I expect a Cambrian explosion of browser based apps as WASM becomes more robust: the ease of deployment, cross platform compatability, over the air application updates and pure speed of C# or Rust will make this a compelling stack, but probably not in 2023.

  3. i love the idea from a portability perspective. i hate it from a performance perspective — web browsers are outrageous, and web applications are even moreso. but practically speaking i keep running into two problems…and i think they’re both symptoms of a deep unseriousness. the firefox os phone disappeared before it had a chance. and there’s still no LinearLayout equivalent for html! writing html for screens has improved a lot in the last decade but it’s still not a usable ui layout language.

    i’m disappointed that mozilla put so much effort into the idea without confronting the actual requirements of app authors and embrace-and-extending html until they actually had something useable.

  4. I’ve always loved the term “script kiddie” to offer a distinction between those doing lower-level, compiled-language work… and those pushing data around with scripting languages whilst patting themselves in the back door being a “programmer”.

    Sure, you can write complex scripts with JavaScript – but at the end of the day it’s a scripting language. It’s the half-arsed solution that reuses other’s work, which puts it in script kiddie turf. (Don’t get me wrong, I deeply appreciate the concept of “don’t reinvent the wheel” – I just hate to see any new development go down this path)

    An app written in a precompiled language is going to be a better use of compute resources every single time. Sometimes we have to assess the “right tool for the job”, but rarely is a bloated turd like JS the answer outside is moving some DOM in a browser window.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.