Some random thoughts about modern application development.

GUI on Perl is not currently in a good state.

I agree. Somewhat. I feel strongly that the way forward (on all platforms) is to write for the web. This can run locally, or in a container, or on a server that provides the required resources (storage, processing power, databases). Using the browser as GUI will provide a more uniform user experience across platforms, and you certainly have an easier time integrating multimedia content (images, sound, video).

I mean, when you write a cross-platform application that wants to play a single sound, you will have a lot of "fun" getting this to work on Windows, Linux, FreeBSD and OSX. On the other hand, if you deliver a HTML, all you would need to do is something like:

var audio = new Audio('audio_file.mp3');
audio.play();
<code></p>

<p>Same with displaying dynamic images (i'm using jquery here):</p>

<p><code><img id="imagepreview">
<input type="text" val="" id="imagename">
<input type="button" val="Load Image" id="loadbutton"
...
<script>
$(window).on('load', function() {
    $('#loadbutton').on('click', function() {
        var imagename = $('#imagename').val();
        var imgpath = '/preview/' + imagename; // Input validation? Na
+h, there are no bad people on the internet ;-)
        $('#imagepreview').attr('src', imgpath); // Triggers loading o
+f the new image source
    });
});
</script>
[download]

If someone writes a program that is part of the basic OS, then writing for that OS+Desktop setting is fine. But as soon as you start designing a third party software that needs all kinds of extra dependencies on every install, this can get quite tricky. Not only for you, but also for the end user and (in a company setting) any sysadmin that has to manage the installation.

Yes, you could provide a docker image, but there is a good chance that your program will not match the themeing of other local programs, unless you put in even more work. If it runs as a website, users are used to it looking different than their local stuff or other websites.

Plus, if it runs as a website, a sysadmin can just set it up on a (virtual) server and email to link to the users. Which is certainly easier than to roll it out to potentially hundreds of users and making sure all their installations works and are up-to-date. And running the stuff centrally also makes sure that you have a central, backup-able copy of the data, instead of hoping against hope that the user somehow makes sure company data is not lost.

The thin client idea is fine if the user is on a thin client (only) device. If however they're not, and they have local data they want to work on, the thin client idea would require them to first upload their data to the mainframe (that's what a web app is, sort of), which can be tricky. Just as with software engineering itself, there are no silver bullets.

I totally agree that, yes, there are no silver bullets. But regarding UI, modern web browsers come quite close in my opinion. And you can avoid lots of system administration work, especially when you have a large number of users.

Didn't look into it for some time, but there are multiple approaches to handle this transparently.

• The File System Access API: simplifying access to local files
• Building an App that uses a Web browser internally. Using something like Flutter, you can probably compile it for Windows and Linux. This would still minimize doing a lot of OS specific stuff, but would give your the ability to add custom JS interfaces for things like file access. Since most of the logic is delivered from the webserver, you hardly ever need to update the local app.

Of course, you could just bundle the Perl application and all required tools into a docker container and run it on the users computer. And still use the webbrowser as the UI, letting the boffins as Google figure out how the users OS does multimedia.

PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP
Also check out my sisters artwork and my weekly webcomics