I just learned about the existence of a framework called, “Forked.” The blurbs about it talk about “local first” application design and automated merging of concurrent offline editing. This seems very interesting to me. So I started looking at the source code and the example applications, and then reading about other stuff in the “local first” ecosystem, which is totally a thing I didn’t know about but which I wish I’d learned about in, let’s say 2010, when I started having some time to think about this kind of thing.
I’m coming at this whole area from a couple of different angles. One, of course, is to look at the frameworks that people are talking about and using and trying to figure out what they’re good for and how they fit into a larger, application context. The other significant angle is, I have some software that is currently client/server but really only because I want to allow multiple users to collaborate on a single…let’s call it a document.
The really hard part about all of this is that no two people write about the same data structures or architecture entities using the same words. For instance, let’s take a to-do list, since it’s one of the first toy applications everyone ever creates these days. You’ve got one data entity which is a to-do item. Some people call it a ‘task’ while others call it a ‘todo’ or even an ‘item’. Then, you’ve got your list of all these things. Some people just call it a list, while others don’t call it anything at all, because, and this is where it starts to get confusing, they don’t think of the list as a structure, it’s just whatever gets returned from “the database” when their application runs a query for the items. Meanwhile, you’ve got other people talking about how their package or framework or library or whatever they’re calling it takes care of accepting modifications from other sources (which magically exist but which, like Bruno, we don’t talk about). But while the way you hook up your application’s UI to these things may be documented, often the rest of the system is left to your imagination.
Oh, here’s another interesting thing: for the past twenty years, everyone’s been targeting web browsers and mobile devices and treating actual computers as just quaint old things that happen to have big screens. So all the examples and “local first” application development involves progressive web applications, and writing JavaScript and deploying your “application” via Electron, which is great if you hate yourself and your users, I guess. I am old and grouchy and I think that Word or even MacPaint, from 1990, yes, those programs, are excellent models for “local first.”
Think about a PDF, for a second. It is just a big structured file with a bunch of different resources embedded within it. Images, fonts, as well as layout instructions and, okay, maybe some text, too. That’s a great model. The file is something you can point to and copy and share. Now, there’s a pretty straightforward way to make that work with Swift Data (which is some tasty Swift sugar on top of Core Data, which is some, well, chewy Swift on top of Objective C on top of SQLite). However, that still means that your application has all its data access sitting in its different UI views. Which is fine, I guess, if you only ever have one or two, but if it’s a complex application with a complex data model, maybe you have more than one model object and maybe you have more views? And maybe, wiring some kind of replication and merging framework into your score or more of views and model objects gets kind of complicated? And gosh, it’s made even harder when no two people are using the same terminology or even the same software architecture let alone programming language to describe what their thing does and how to use it.
This is frustrating.