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.
Careful, [CanadaHonk] is Loonie.
But actually the Common Loon doesn’t honk:
Hear the Hauntingly Beautiful Call of the Common Loon:
https://www.audubon.org/news/hear-hauntingly-beautiful-call-common-loon
https://media.audubon.org/180803-call-of-the-loon-the.mp3
Canadian Geese do honk though:
https://www.audubon.org/field-guide/bird/canada-goose
Honking of several Canadian Geese:
https://nas-national-prod.s3.amazonaws.com/birds/audio/CANGOO_1.honkingofseveralgeese_KYle_1.mp3?tok=1671176071
Ah, but calling them “Canadian Geese” is incorrect. They are “Canada Geese”. (I read this somewhere a while back.)
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…
lol; no, the joke eluded you this time. It was quite innocuous.
It’s a bird pun
I hate browser-based apps, and don’t get why anybody would not.
(Well apart from a few CEO’s of techgiants I suppose.)
Why must you hate
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.
Perfect. I hate also the font rendering of Chromium on Windows it looks horrible. Now we just need to convince Qt to use Firefox as well/the installed browser.
All these browser-based software feels so unbelievably slow. The best example for inefficient software.
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.
The most efficient software is that which is produced and deployed with minimal effort and this is hugely efficient.
Unless it is a ‘one time use’ software – the launching speed and speed of response matter much more than install time and effort.
The most efficient software runs faster and uses less system resources. FTFY
It is an illusion. Poor sods don’t know how to do GUIs with anything else, and that’s the only reason they feel “productive” with the crappy web stack. If only they knew Tcl/Tk…
Python webkit can be used to achieve the same:
https://github.com/zoobab/monitoring_browser
I discovered HTMX recently, i want to try it out.
Add Windows98 look on top:
https://jdan.github.io/98.css/
Why not just run an apache server on your machine with the web app cgi or whatever, and then http://127.0.0.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…
Easier for the user to compile it to a PWA, no extra dependencies and configuration.
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.
“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.”
“I wouldn’t be surprised if lonely USB pen drives in brick walls will outlive the internet eventually (so called “dead drops”).”
I print most of my photos to avoid data rot.
This future stinks. Nothing is more disgusting, more overengineered, more needlessly layered than the web stack.
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.
Agreed. Not to mention you don’t have to go through a storefront. both IOS and Android have web browsers.
Just got flashbacks of IE4 and Active Desktop in Windows 9x!! 😂
Websites as a wallpaper on the Windows desktop.
AFAIK, that was one of the most hated features in the 90s. 🤣
This is an unfortunate name. I think most developers will recognize Gluon as the tool (and company) that lets JavaFX apps be published as Android & iOS apps, which is confusingly close to the same problem space as this tool.
e.g. https://foojay.io/today/creating-mobile-apps-with-javafx-part-2/
I hope that *most* developers do not care about either of them.
How does it compare to Progressive Web Apps (PWAs)?
Gluon allows you to have a Nodejs backend, allowing you to do much native/desktop things, similar to Electron.
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.
Gluon uses your already installed browser (Chromium or Firefox), it doesn’t bundle a copy. Says that in article and readme ;)
You can just use C# with WebView2. There’s a native controller and a (not official) nuget called photino if you want cross platform code only solution.
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.
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.
My project uses both Javascript and C++. used each for their respective places. C++ for the low end embedded things, and JS/HTML for GUI since it is crossplatform and established. I have seen a lot of crossplatform ecosystems come and go.
https://github.com/FL0WL0W/EFIGenie