I don't get it. You still have to sync the state one way or another, network latency is still there.

Aldipower 6 days ago | parent | next [-]

Me neither. Considered we are talking about collaborative network applications, you are loosing the single-source-of-thruth (the server database) with the local first approach. And it just adds so much more complexity. Also, as your app grows, you probably end up to implement the business logic twice. On the server and locally. I really do not get it.

▲

jitl 6 days ago | parent [-]

You can use the same business logic code on both the client and server.

With the Linear approach, the server remains the source of truth.

▲

foldr 5 days ago | parent [-]

It’s difficult to ensure that it’s always the same logic when client and server software versions can get out of sync. You can try to force the client to reload whenever the server redeploys, but realistically you’ll probably end up dealing with cases where the client and server logic diverge.

▲

jitl 5 days ago | parent [-]

i mean that's life with client computers, you make stuff backwards compatible and you avoid making it too brittle.

	▲	foldr 5 days ago \| parent [-]
		It's not an insurmountable problem, but it's a problem that you don't have if you execute your business logic only on the server.

▲

WickyNilliams 6 days ago | parent | prev | next [-]

The latency is off the critical path with local first. You sync changes over the network sure, but your local mutations are stored directly and immediately in a local DB.

▲

croes 6 days ago | parent | prev [-]

But the user gets instant results