> What would it even mean to "locally first" turn the lights in my house on and off?
It would mean that even when the vendor decides to disconnect the cloud server, the app still knows how to find the lights over the local WIFI and turn them on-and-off. This is one of the poster-child use cases for "local first".
> check the weather?
There's less to work with here, because we generally treat weather as a read-only use case. But it isn't! There are weather apps today that let you connect to your own local weather station, and/or fetch results from other tiny weather stations in your region. All of which could be handled in a "local first" manner (modulo some reasonable way to discover nearby weather stations).
> or play a multiplayer-only video game?
Chess, scrabble, or really any asynchronous turn-based game can be handled via local edit for your move, and then sync to your peer (optionally through a server for easier coordination).
> It would mean that even when the vendor decides to disconnect the cloud server, the app still knows how to find the lights over the local WIFI and turn them on-and-off. This is one of the poster-child use cases for "local first".
I agree with this, but my point is “what should the app do when you’re offline” - as in, your phone is on aeroplane mode. “Local” as in, local to your device. Not your wifi.
What does it mean to turn the lights on and off in that situation?
In my opinion, nothing, it shouldn’t work. And if that’s true, the light is essentially a server, the app / phone is a client. Nothing has changed except making the routing more efficient.
Sure, that's just the nature of interacting with a remote object of any type. But I don't think that invalidates wanting the app to be designed in a "local first" manner with respect to whatever happens to the cloud backend.
Right. A remote object. But the point of local first software is the objects are local.
If I edit a note using Apple Notes, I’m not editing a remote object. I’m editing something local - authoritatively local - to my device. The server doesn’t know more than my phone does, and the server doesn’t get to tell my phone that I don’t have permission to edit my own, local stuff.
That’s different from interacting with a remote object as a client. Hence, I don’t see turning a remotely controllable light on and off to be local first software because way more like interacting with a server than it is like Apple notes. The server just happens to be harder to route packets to sometimes.
By that definition, pretty much the only apps that qualify for local first are document stores. I'm not convinced that it is useful to narrow the definition that far (nor that most of the local first advocates would agree with such a narrowing).
We're basically talking about 1 bit of state that the light is authoritative about (on/off), versus all the other state that your copy of the app can be authoritative about (configuration, schedules, etc).
- turn on lights — there are smart light bulbs that phone home to the cloud. Along with smart assistance, home automation, etc. those are exactly the things that should be local-first, or at least, the server software should be onsite (such as Home Assistant — edge computing). We already have examples of what happens when companies shut down the servers those automations depend upon. To go even fuether, each device that is truly local-first enables the kind of cooperative automation conceived of in Promise Theory.
- checking the weather — although predictions are easier to come by from NOAA’s weather models, areas can have microclimates both natural and man-made that are not so easily predicted through atmospheric modelling. Permaculture design includes scaling microclimates in very small areas (on the order of specific plants) to tweak what can grow there. Local-first makes sense if you want to instrument those microclimates. Better yet, there are ways to read the clouds and conditions to get decent predictions for weather conditions for your immediate area.
- local-first multiplayer video game - what an intriguing idea! The closest I can think of is that multi-user virtual reality spaces that was built on a modern version of Smalltalk. It isn’t local first, but it supports multiple, independent servers that mesh together. There are probably also ways to do this with turn based games, such as chess or go.
Do you have any other examples? The ones you brought up were a good exercise to see how far one can take local-first design.
On the other hand, this is still tethered to the server, so likely more commercially viable than a true local-first design.