Cleaving apart software schema concepts
Diving deep into software schema in local-first software architecture with three distinct, diverging paths.
Cleaving apart software schema concepts
I'm steadily plodding along on my article on schema and local-first software architecture. The writing has been the healthy and painful variety: discovering what I know and the gaps in my thinking as I try to describe it.
The scope of the article itself has been difficult to pin down. I assumed 'twould be a simple matter to translate the talk I gave at Effect Days into an accompanying article. But the article has constantly shifted as I wrote, had new ideas, and received feedback. This week I had a clarifying realization: I was essentially trying to write about three different ideas and each of these ideas was pulling the article, unhelpfully, in different directions. I can echo John Bunyan in "The Author's Apology for his Book":
When at the first I took my Pen in hand,
Thus for to write; I did not understand
That I at all should make a little Book
In such a mode: Nay, I had undertook
To make another; which, when almost done,
Before I was aware, I this begun.
Here are the three diverging paths.
My first instinct was to define schema as a philosopher: what is a schema, really? What is it good for? Where do they show up in the real world? Where do they show up in software? While enjoyable, this was a line of thinking only a philosopher could love and opening the article with this exploration was distracting and unhelpful. I wrote a brief (too brief, sadly!) evergreen note on the topic and excised it from the article entirely.
The second idea is the most concrete: local-first software systems have an opportunity to unify schema across the system due to a different architectural pattern than the traditional layered architecture, enabling a better DX and novel user experiences. This was the main thrust of the talk at Effect Days. This idea already exists in practice in DXOS and a few other local-first systems. There are nice demos. It's tangible, well-bounded, reasonably well-understood. Define the schema once, use it everywhere.
But once you have the same schema everywhere, I start to want more. I want to attach behavior to that schema. I want presentation. Schema starts to become more like an SmallTalk object, or a web component, or an OpenDoc Part. This idea is much further out there. It's speculative and based on a gut feeling that good things lie in this direction. There's no working system to demo (though Composer is headed in that direction). The most concrete thing I can offer is this rambling sketch:
Once I realized I was dealing with three different, though related, ideas the task became clear: scope the article down to Unifying Schema in Local-first Software Systems and ship it. Leave those other, enticing, amorphous ideas for later. I set to it. I have an outline of the scoped-down article (happy to share if you'd like to see the in-progress work) and it's quite achievable.
I both love and hate this about writing. It's not often a straight path to get to something like a singular work. I have to learn to love the process!
As Paul Graham noted: "expect 80% of the ideas in an essay to happen after you start writing it, and 50% of those you start with to be wrong."
ICYMI: Stuff I worked on
- I facilitated Open Canvas Working Group Meeting № 1 on Tuesday, and it's off to a great start! Read the recap here.
- At DXOS Office Hours on Thursday, we talked about the feedback we've gotten on Composer and the next three feature areas: (1) credible exit through filesystem sync, (2) organization through a new UI called Deck, and (3) revamping the account system.
Recently Read
- In Marking the Web’s 35th Birthday: An Open Letter, Tim Berners-Lee argues that "we must break down data silos to encourage collaboration, create market conditions in which a diversity of options thrive to fuel creativity." Couldn't agree more! But is SOLID the way to get there?
- Excuse me, is there a problem here? by Jason Cohen is the article I wish I'd written about the importance of startups solving real problems. It has a flowchart! And a diagnostic tool for estimating viability! It's humorous! It bridges from "finding good ideas" into "viable business models." If you're working on a startup, you must read this. Right away. Thanks for saving me from having to write this, Jason!
Glimpses of the future
I love the work Orion Reed is doing with 3D visualizations of a webpage's DOM. The build-in-public vibe, the beauty and utility of the visualization, and even the simplicity of the solution, it's all done well.
Rob Haisfield blew my mind with an LLM that hallucinates entire web pages based entirely on the URL you provide. It's a lot of fun to play with and almost a meta-commentary on what an LLM expects the internet to be for and be about. One of my favorite things is generating a working web application. I managed to get it to generate a calendar for me with working date picker and completely made-up events.