4 ms·

These ideas are some of the founding principles of "local-first software": https://www.inkandswitch.com/local-first/ https://www.inkandswitch.com/local-first/

These ideas are some of the founding principles of "local-first software": https://www.inkandswitch.com/local-first/ https://www.inkandswitch.com/local-first/ As I like to put it - Local-first is the real serverless. Your user's device is the real edge. I think the future of the web needs to be that the server is optional, we need our data (albeit personal or our companies) to be on our own devices. We are all carrying around these massively powerful devices in our pockets, let use that capability rather than offload everything to the cloud. One of the things I find most exciting about local-first (and I'm very fortunate enough to be working on it full time), is the sync tech thats being developed for it. 2024 is I think going to be the year local-first goes mainstream.

runningamok 3y ago
Clarification: I'm not the author of the linked post. I read your post some time back and feel it's been an organizing force for developers in this space — great job and thanks for the work you put into it. I often wonder about terminology. What was the reason you chose "local-first" over "offline-first" (or even "serverfree" as in this case)?
- runningamok 3y ago
  My mistake, I see that post wasn't written by you
- samwillis 3y ago
  Sadly, I'm not part of Ink and Switch and did not write that post... They are an incredible bunch, as are so many people in the local-first / CRDT space, many I have had the opportunity to meet and collaborate with.
- bombcar 3y ago
  For me (not the author) "local first" makes it clear that "on device" is a first-class citizen, and the server is an afterthought. "Offline-first" or "server free" sounds much more limiting, like it will be able to limp when offline, but really wants to connect to a server eventually. I also (personally) don't like "serverfree" because servers are good - they're not the problem! It's the "servers you don't and can't control" cloud dependencies that are the issue.
dunham 3y ago
Hopefully the sync tech being developed for it is solidly open, but it's good to have access to your data regardless. The thing that always bothered me about that article is: > Notably, the object server is open source and self-hostable, which reduces the risk of being locked in to a service that might one day disappear. It appears that the object server is neither open source and nor self-hostable. The repository that they link is mostly empty. It has a rich version history of "releases" that only change the changelog file. I assume the article was accurate when written, and have always wondered what happened. So I suspect mongo rewrote the git history to remove the code when they bought Realm. Was it ever open source? Did they intimidate people into taking down forks or did nobody bother? I do see an edit to the README around that time adding that a license is required to run the self-hosted server. It is dated about two months before the linked article, but they may not have noticed or it may be back-dated: https://github.com/realm/realm-object-server/commit/fc0b399d0bcf805f3cd664ac0bcb830a140ae291 https://github.com/realm/realm-object-server/commit/fc0b399d...
- samwillis 3y ago
  There are many projects developing sync tech for local-first, I work on a fully open source one - ElectricSQL - and we are fortunate to have a couple of the CRDT co-inventors on the team. We maintain a list of any local-first sync project we know of here: https://electric-sql.com/docs/reference/alternatives https://electric-sql.com/docs/reference/alternatives
  - IanCal 3y ago
    Electricsql looks cool but on a mobile browser the "local first" instant reactivity example is waaaay slower than the cloud version. Latencies of 600+ms Vs 120ms. The comparison list is very useful as a collection, thank you.
    - samwillis 3y ago
      Hmm, that's wrong. Will look into it, thanks!
deleted 3y ago
[deleted]
charcircuit 3y ago
>let use that capability rather than offload everything to the cloud. That costs battery life. With more powerful chips more time can be spent sleeping consuming minimal energy.
- sellmesoap 3y ago
  What costs more power? Writing to local storage or running the data over the radio and back the next time the app is launched?

runningamok 3y ago

Clarification: I'm not the author of the linked post. I read your post some time back and feel it's been an organizing force for developers in this space — great job and thanks for the work you put into it. I often wonder about terminology. What was the reason you chose "local-first" over "offline-first" (or even "serverfree" as in this case)?

runningamok 3y ago
My mistake, I see that post wasn't written by you
samwillis 3y ago
Sadly, I'm not part of Ink and Switch and did not write that post... They are an incredible bunch, as are so many people in the local-first / CRDT space, many I have had the opportunity to meet and collaborate with.
bombcar 3y ago
For me (not the author) "local first" makes it clear that "on device" is a first-class citizen, and the server is an afterthought. "Offline-first" or "server free" sounds much more limiting, like it will be able to limp when offline, but really wants to connect to a server eventually. I also (personally) don't like "serverfree" because servers are good - they're not the problem! It's the "servers you don't and can't control" cloud dependencies that are the issue.

dunham 3y ago

Hopefully the sync tech being developed for it is solidly open, but it's good to have access to your data regardless. The thing that always bothered me about that article is: > Notably, the object server is open source and self-hostable, which reduces the risk of being locked in to a service that might one day disappear. It appears that the object server is neither open source and nor self-hostable. The repository that they link is mostly empty. It has a rich version history of "releases" that only change the changelog file. I assume the article was accurate when written, and have always wondered what happened. So I suspect mongo rewrote the git history to remove the code when they bought Realm. Was it ever open source? Did they intimidate people into taking down forks or did nobody bother? I do see an edit to the README around that time adding that a license is required to run the self-hosted server. It is dated about two months before the linked article, but they may not have noticed or it may be back-dated: https://github.com/realm/realm-object-server/commit/fc0b399d0bcf805f3cd664ac0bcb830a140ae291 https://github.com/realm/realm-object-server/commit/fc0b399d...

samwillis 3y ago
There are many projects developing sync tech for local-first, I work on a fully open source one - ElectricSQL - and we are fortunate to have a couple of the CRDT co-inventors on the team. We maintain a list of any local-first sync project we know of here: https://electric-sql.com/docs/reference/alternatives https://electric-sql.com/docs/reference/alternatives
- IanCal 3y ago
  Electricsql looks cool but on a mobile browser the "local first" instant reactivity example is waaaay slower than the cloud version. Latencies of 600+ms Vs 120ms. The comparison list is very useful as a collection, thank you.
  - samwillis 3y ago
    Hmm, that's wrong. Will look into it, thanks!

deleted 3y ago

[deleted]

charcircuit 3y ago

>let use that capability rather than offload everything to the cloud. That costs battery life. With more powerful chips more time can be spent sleeping consuming minimal energy.

sellmesoap 3y ago
What costs more power? Writing to local storage or running the data over the radio and back the next time the app is launched?