Hacker News Reader

Comment by samwillis | Hacker News Reader

These ideas are some of the founding principles of "local-first software": 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.

View on HN

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/fc0b399d...

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

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.

Hmm, that's wrong. Will look into it, thanks!

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

My mistake, I see that post wasn't written by you

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.

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.

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

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

Reply on news.ycombinator.com