Episode: 4625
Title: Site Specific Browsers
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr4625/hpr4625.mp3
Transcribed: 2026-07-31 16:15:22 (official HPR transcript)

---

This is Hacker Public Radio Episode 4625, for 2026-04-24
Today's show is entitled, "Site Specific Browsers"
The host is Lee and the duration is 00:07:37
The flag is Clean, and the license is CC-BY-SA
The summary is "Lee talks about using Progressive Web Apps on the desktop"
Hi, I'm Lee.
I'm going to talk to there about my experiences using various tools
that make web-based apps seem like desktop apps.
Firstly, you might wonder why anyone would want to do this,
because surely if you're using a desktop computer,
then you want your apps to be real apps running on your computer,
not a femoral things, running on some machine
that doesn't miles away.
There are a few reasons, and the main one
I can think of relates to what in software engineering
you would call a non-functional requirement.
That is, it has nothing to do with what the software does,
but instead with how it does it.
And that requirement is partly due to laziness of developers
like me, but partly due to practicality
when time and cost are issues.
This is that you can write the app once,
and it will run everywhere.
Despite various technologies that promise
to make it possible to build an app,
where the source code just compiles down to a program
that works wherever you might want to deploy it,
that really isn't fully realized.
I discovered this when I built a Swiss army knife app
containing dozens of handy,
cisadmin and dev tools, mainly for converting
or generating snippets of data that you would paste into it.
I thought I was being clever when I chose the KD
plasma base framework called Kirigami,
and was careful only to use standard cross platform
compatible libraries in my code.
However, when I actually clone my code,
developed on my Ubuntu machine,
and tried to build it on MacOS on my Mac mini,
all help wrote loose.
I was juggling with the Mac cross platform
in Stahlahombrou, and the KD cross platform
library environmental craft, and the command line tools
in sort via X-code, and then trying to match together
one version of one thing with another version of another.
This is the thing about building software.
One theory, lots of stuff is compatible.
In practice, you can end up balancing spinning plates
on your nose, or riding you in a cycle to get it all to work.
And I'm not pinpointing Kirigami in particular.
I've obtained my own genes like Flutter or Electron,
I've found to have these issues.
And it's not that the technology itself
is poorly conceived or implemented,
but that the program is complex and without investing time,
effort and resources, making code that you write once
and compiles everywhere is problematic.
If it does work, it's often a matter of skilled
local perseverance.
This is why so many companies
will opt to make different app for each platform.
One for Windows, one for MacOS, hopefully one for Linux,
one for Android, one for iOS.
So I'll come back to the reason for using web-based technologies
for running low-coaps on a desktop computer.
It's because web-technology, CSS, HTML, JavaScript,
and so on have become a universal standard.
It's often said nowadays that the browser
has become the operating system.
Well, that's not quite true, but it's getting close.
Operating systems like Chrome OS, for example,
based on that tenant, where to a large extent,
everything you see on the screen is a web page.
And then there are some disadvantages
to using web technologies, perhaps.
One of these is that they're often cloud-first.
You have to log in so credentials, give away
a load of personal data that you should be able to do
perfectly well on a computer without all that nonsense.
Also, if the internet connection goes,
you could have lost access to your data.
Often, things that might easily be perfectly well stored
on your computer without relying on an always-on connection.
These disadvantages have been
ameliorated somewhat nowadays as some web-absorbed
what is often termed respectful in that they do not
demand linking yourself to some online-rich-driven users,
and they can also take advantage of web-technologies
that store data locally on your computer without loading it.
The exception would be if you explicitly
wanted to synchronize your data, it may give an option
to sink to some way out of your own choosing,
even to some service that you host yourself.
These reservations aside, there are some types of web-abs,
we might accept it's okay to trust the provider in question,
especially if you're paying them,
and there is less incentive for them
to treat you as a broad fodder for data collection and marketing.
Another thing, if like me, you run a Linux
distrayer as your daily driver,
and that means you do pretty much all your proper computer
really stuff within the Linux.
Then you'll notice you can get treated as a second-class citizen
by often in quotes, big companies,
the like to assume everyone is running windows
or maybe macros, or at least an eye-fine or an Android phone.
This often forces you to run these tools in the web browser,
and you lose that app-like experience
that other platforms enjoy.
That, as I said, web-tool-onjies and browsers,
well, have moved on.
I've encountered a few tools
that let you run a web application more or less
as if it was a proper desktop app.
I think the first time I became aware of this
was with Peppa Mint Noes,
which had a single-side browser tool called Ice,
though that's been replaced by one called Kuma apparently.
More recently, I installed a program
on my Ubuntu machine called France.
The key advantage of this was it detected things like notifications,
so you would actually know when a webmail email arrived
versus having to check it.
After a while, I realized this did not seem
to be getting that much support,
especially when the web app changed something
that broke the recipe that was allowing it
to work within the France container.
I swapped France for what looked like
a more community-driven branch of the same tool,
called Ferdium, and this I've been using for a while now.
During an update to my PC, though,
I somehow lost all the services I'd set up,
and rather than setting them up again,
decided for a while to just run everything
in my web browser, despite my common problem
of out-of-habbit closing tabs or closing the browser,
then realizing the service I was working with had gone.
Another issue being that some web services
don't do too well if you're using more than one tenant
or once, tenants being effectively a different user.
At this point, I found there was another option
that I've only been using for a short time,
but suits my needs remarkably well.
This is to install these services
as what are called progressive web apps.
While I generally browse the web with Firefox,
I found the Chromium handles these quite well,
and it seemed to me to keep these PWA separate
from my general web browsing,
especially as they're often work-related,
so I don't want them available,
unless I'm actually doing something specific with them.
So at the moment, I have two different email providers
fast-mowing outlook, a software development project
management tool called Jira,
and a general collaboration tool called Teams
or sitting at separate apps in my KD plasma task bar.
The specifics of how to install a website
as it's own desktop app will vary from browser to browser,
and from one Linux distro and desktop environment to another.
And while this way of doing things
is born out of compromises or ground,
it does seem to be a case of the lowest common denominator
winning out.
Your own mileage may vary, but practically speaking,
if you happen to have Chromium running
and have navigated to a particular web app,
you can go to the three dots menu,
scroll down to cast, save and share,
and click and still pages app.
For me, it was that simple,
and even in one case, the web app was smart enough
to prompt me to do this without me needing
to even search for that menu option.
For me, it's a bit like having a Chromebook,
or having mobile apps on my desktop,
not to everyone's taste,
and not suitable for all use cases,
but this is working for me quite well at the moment.
Anyway, that's all for now.
Thanks for listening.
You have been listening to the Hacker Public Radio podcast, at hackerpublicradio.org.
Today's show was contributed by a HPR listener like yourself.
If you ever thought of recording a podcast, then visit the HPR site to find out how easy it really is.
Hosting for HPR has been kindly provided by anhonesthost.com, the Internet Archive, rsync.net, and the HPR Community Content Delivery Network.
Unless otherwise stated, today's show is released under a Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.