Title photo
frugal technology, simple living and guerrilla large-appliance repair

Regular blog here, 'microblog' there

Many of my traditional blog post live on this site, but a great majority of my social-style posts can be found on my much-busier microbloging site at updates.passthejoe.net. It's busier because my BlogPoster "microblogging" script generates short, Twitter-style posts from the Linux or Windows (or anywhere you can run Ruby with too many Gems) command line, uploads them to the web server and send them out on my Twitter and Mastodon feeds.

I used to post to this blog via scripts and Unix/Linux utilities (curl and Unison) that helped me mirror the files locally and on the server. Since this site recently moved hosts, none of that is set up. I'm just using SFTP and SSH to write posts and manage the site.

Disqus comments are not live just yet because I'm not sure about what I'm going to do for the domain on this site. I'll probably restore the old domain at first just to have some continuity, but for now I like using the "free" domain from this site's new host, NearlyFreeSpeech.net.

Sun, 18 Nov 2018

A local web-based program might not be such a bad idea

I just wanted to make a simple GUI program. You know, one that lives on your computer hard drive and creates, modifies and saves files, then uses that data to do things. Oh, and I wanted it to be cross-platform, meaning it would work on Windows, MacOS and Linux with little or no modification.

Sounds easy, right?

Previously: Everything doesn't have to be a web program

Well, despite the fact that local GUI programs aren't exactly dead — web browsers are GUI programs, for Christ's sake, the average coder is less and less interested in writing programs that run on desktop and laptop computers and almost exclusively interested in creating web apps that run in a browser and that maybe, possibly get magically turned into mobile phone apps through some voodoo with React Native or a similar and massive hunk of code.

"But I don't want to worry about security and establishing a account system for my app, which really should just run as a local program on a local PC," I said.

Did I mention that I want everything I do to run on all three major desktop/laptop platforms?

I thought, "This has got to be easy." I was coding in Ruby, which I knew has the Tk toolkit, a way to make simple GUIs that would work on any computer that runs Ruby and has the proper Gems (and/or compile-time options; I really don't know that much about it).

It turns out not to be so simple. Tk is not huge (in a community or people-use-it sense) in Perl and Ruby. It's bigger but still not huge on Python.

In fact, I should probably switch from Ruby to Python because there is a lot more Python GUI everything than in just about any other language (or any other dynamic language that isn't part of a single-system GUI programming environment).

I'm sure there are ways to use the Qt or GTK toolkits with languages that aren't C++ and then make what you build cross-platform. And I'm also sure that I could use Java and JavaFX, but that GUI — despite its relative newness when compared to Java's Spring GUI — seems to be about as dead as it could be from a mindshare, tutorial-availability and general-usage standpoint.

I would opt for Tk, but the documentation for using it with Ruby is at once impenetrable and old, the tutorials few and old. It seems like nobody is using it.

What the development world wants you (and me) to do is create a non-cross-platform desktop/laptop app using the well-supported, comprehensively documented and tutorial-rich toolkits created by the two major desktop OS makers, Microsoft and Apple.

They equip, support and, I guess, coddle application developers. What Apple and Microsoft provide is worlds away from Tk, Qt or JavaFX, though the latter's platform-agnosticism remains tempting.

Do I want to go in that direction, making a native app for the Windows or MacOS desktops? Hell no.

I don't have a Mac and don't want one.

I do run Windows 10 but don't want to limit my program to that system. My Ruby script that currently handles my social-style posting, both to my own site and Twitter, runs on anything that can run Ruby and install the Nokogiri and Twitter gems (which leaves out ARM devices that don't seem to be able to build the Twitter gem).

The prevailing winds for cross-platform "desktop" apps in the 2010s are blowing head on into the world of web apps — not exactly HTML apps accessible in the browser and using server-side back ends, but that is entirely OK in the collective mind of developers.

These days, the push is to use the Chrome browser-based Electron framework and use JavaScript/Node.JS to make a desktop app that looks like a web app but lives in its own window and has full access (via Node) to the local filesystem.

The "biggest" apps that have gone this route are the Atom and Visual Studio Code editors.

For my "little" app, this is overkill.

Instead, I'm going to create a web browser app — basically a web site — that uses JavaScript's local storage function to create blog and social-media posts, which will then be uploaded to Twitter and a web server directly from a Firefox, Chrome, Safari or Microsoft Edge browser.

The credential info needed to use the Twitter API would be in local storage in the browser and would persist across browser closings and system reboots.

FTP uploads would be handled via a third-party service that uses a local token to tap that service for the upload.

In the event that this doesn't work, I'll have to consider creating a web service, but I think I can get along without it.

I would love for users to be able to post to Twitter without requesting their own access for the API and instead authenticate using their own Twitter credentials, but that is something I can do in the future, long after this is all working.

That's the theory, anyway.

The benefits of a web app include:

  • It will run anywhere, on anything that has a web browser
  • Lots of documentation on what are fundamental technologies: HTML, CSS and JavaScript
  • Lots of libraries, frameworks, code snippets, etc., to make development quicker and easier

And what if I do want to save a local file? I can code a download button to create and download a file just like I'm creating in the Ruby console today.

My app is supposed to be simple. With "easy" HTML design local JavaScript storage and enough third-party services to make it all hang together, I think I can make it happen.

TL;DR — Trying to use abandoned or niche technologies with few current users, no recent documentation and few old tutorials or books and no new ones adds too much difficulty to the development process.

Making an HTML app without the weight and complexity of the Electron JavaScript framework seems like the way forward for simple apps.