Hacker News new | past | comments | ask | show | jobs | submit login

> 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).




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: