Personal web apps, part 1

Sometimes, I just want a simple, bespoke app running on my home network. Examples include shopping lists and bill tracking.

In the past, I've either tried to shoehorn the problem into some existing solution (usually OneNote), or I've tried to find some self-hostable turnkey solution (e.g. Jellyfin). You could also pay for a solution from a big corporation or a small software-as-a-service company.

But what I'd really like to do (for simple problems only) is build my own simple solution, because then it would do what I want, without bloat, for free.

The first step is to decide which stack to start building upon.

Infrastructure candidates

I want something simple and hackable. Ideally, I could tweak and/or debug things from any computer. That last requirement is why I'm envisioning web apps instead of, say, a shell script.

Some ideas follow, along with brief analysis (in no particular order).

PHP (not an April Fools joke)

Even though I haven't written any PHP since roughly the turn of the century, PHP might be a great fit here:

I'm not sure how I feel about PHP for web-scale apps, but for just messing around locally it sounds convenient.

For the record, I'm not the only one who thinks PHP is a good fit for quick and dirty apps like this: see "famsite" on ratfactor.com.

Fossil

Fossil is a small and trivially deployed source control system based on (and used for) SQLite.

It's not intended to be used for general web apps, but it has a lot of features that could potentially be cobbled together to support certain workflows:

To my surprise, it's even possible to tweak the data model of the bug tracker!

Obviously, this is straying into the "shoehorning problems into existing solutions" bucket that I said I'd avoid, but Fossil is something I wanted to play with anyway. It's not a perfect fit, but still worth considering.

Wapp

Wapp is a Tcl-based web app framework that I think was also created by the SQLite author(s) and is, again, small and trivially deployed (and it embeds SQLite).

Upsides:

Of course, I'm even less comfortable with Tcl than with PHP, so ramp-up could be slow for me.

The Wapp examples page's shopping list app is the kind of thing I could see myself wanting to build.

Lisp

Back in 2023, I learned Common Lisp in order to experience iterative, interactive development (using SBCL, Emacs, and SLIME). I never posted a follow-up retrospective (note to self: I should write one), but overall my experience was positive. If I had tried Common Lisp 25 years ago, I would have been absolutely blown away. Even in 2023, REPL-based development felt innovative and exciting.

There were some downsides, however. Namely, the lack of strict static typing let errors bleed into run-time and my impression that REPL-driven development can be fragile and error-prone (e.g. more than once I wasted time tracking down bugs only to find that my source files and running code had gotten out of sync). The community is also fairly small and some of the tooling is antiquated.

But in the context of apps that only a handful of people will ever see, REPL-driven development makes a lot of sense. You can develop the app as you use it and debug (and resolve) issues as you encounter them, all from the (ahem) comfort of Emacs (even from another computer). Lisp sounds like a perfect fit for personal apps, assuming you don't mind learning Lisp.

In bullet form, the upsides are:

Downsides:

Node.js or Python

Node and/or Python are probably the default answers for a lot of people.

In the past, I might have used Node.js or Python, but the jungle of dependencies (of unknown origin) honestly terrifies me. Recent high-profile malware incidents confirm for me that I'd like to keep my list of dependencies small.

If I went with one of these, I'd stick to only the built-in standard library, with possibly one or two third-party dependencies.

Despite my concerns, Python is probably worth a shot. Node, well... I'm not so sure.

To be continued?

I'm sure there are other options, but these are the ones that seem like the best fit and I'm personally most interested in exploring further.

It remains to be seen how far I actually go down this path, but if I actually end up writing enough of an app to have opinion, I'll try and post a follow-up.