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:
- Each page (or app) can just be a separate file (or two)
- Requires minimal setup
- "Re-deploying" might just be a no-op?
- Interleaving code with HTML, while horrifying for "real" apps, sounds perfect for experimental, one-off tools
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:
- File history
- Web-based file editor
- Issue/work item tracking
- Wiki
- Forum
- Real-time chat
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:
- Small, simple
- Embeds SQLite, so no need to worry about installing any other database dependencies
- Supports CGI, so each "app" could be its own script, avoiding the need for restarting any server
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:
- Can build apps iteratively and interactively
- Can debug and fix issues interactively
- Has compact and expressive code (assuming you don't mind parentheses--which you shouldn't, if you have a decent editor)
- Might even be able to support a web/phone-based structural editor (yes, I'm getting way ahead of myself here)
Downsides:
- No built-in or default data storage
- Mapping JSON to Lisp was more annoying than it should have been
- Small community
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.