Local-First Software Is Easier to Scale (elijahpotter.dev)

Closest thing to true “serverless”: entire MVC app (Django/Rails/Laravel) in the browser with WASM and data persistence by SQLite over CDN.

All the server has to do then is serve binaries, all the business logic is in the client.

Local-first is the true server-less and your device is the real "edge".

So much truth to this post.

An alternate article for this traffic spike is "PaaS is Easier to Scale". When the author relies on others to do the hosting and handle the scale the author doesn't have to worry about it. That's why he didn't need to be alerted. He's relying on others for that responsibility.

The reason it's easier to scale local software is that it does not rely on cloud resources. As a result it's cheaper for a startup to distribute local first software since they don't need the infrastructure of a traditional cloud app. The problem is there is no business model for local first software like there is for subscriptions with SaaS. Traditional desktop apps were sold as single purchase items on CDs. That just doesn't work for local first software, since you probably just navigate to a website to get the software.

Three clear advantages of a local first software:

1. No network latency, you do not have to send anything across the atlantic.

2. Your get privacy.

3. Its free, you do not need to pay any SaaS business.

An additional would be, the scale being built-in. Every person has their own setup. One central agency doesn't have to take care of all.

I purposely did not set up any infrastructure for my iOS app Reflect and made it local-first [0]. I did it so that I could make the app completely private but it’s come with the wonderful side effect that the product is easily horizontally scalable. The only overhead I have for more users is a busier discord channel and so far that community growth has felt very rewarding.

[0] https://apps.apple.com/us/app/reflect-track-anything/id64638...

Local first is easier to scale technically.

Paid hosted software is easier to scale financially.

Without the latter, it's very hard to come up with the money to pay people to build, to support the market, etc.

Local first apps have some peculiar technical features, yes. I worked on CRDTs from maybe 2008 and in 2012 we made a collaborative editor. Local first, all data on the client, syncing by WebSocket. I remember when we debugged it we once had a problem resetting a document. It kept reappearing. The guilty was an iPad laying on the table face down. It synced all the data back. That was seriously different from e.g. Evernote that was losing data all the time. In our system, intentionally purging was really difficult.

Once we ran two weeks with a "poisoned" document that was crushing any server it was uploaded to. The user kept the tab open just working like nothing was happening. Then, we found the bug, but in theory we may have made the entire cluster restart all the time. Apart from electricity consumption, that would hardly change anything. The load and syncing time would be worse, but not by much.

With local-first, everything keeps working even without the server.

Here is the 2012 engine, by the way:

https://github.com/gritzko/citrea-model

"Lots of cloud providers like to brag about being able to scale with their users. I like to brag about not having to scale at all"

Bars.

"Lots of cloud providers like to brag about being able to scale with their users. I like to brag about not having to scale at all."

Bars.

It's amazing to me how we called "box-product" now has a fancy new name "local-first". "Box product" is quite well understood. It has a lot of benefits, but also the business model is harder to get right comparing to cloud services. For opensource projects, that will not be a problem tho.

While local first software might be easier to scale, the financial aspect remains unsolved.

I can see that Harper (The author's software) was acquired by Automattic so I assume that Automattic is paying the author to maintain Harper, effectively subsiding the maintenance costs to keep Harper free.

Not every local first (and open source) software has the opportunity to be supported by a big company.

Why local first and not a native application?

If the problem fits into the limited local resources, if there's no syncing required, no login, no multiplayer, ... Sure, do it. But don't pretend this solves all business cases.

So many comments are based on different understanding of local-first. For some it means no data on the server, allowing some claim it's better for data privacy (but what about tracking?). For others it means it works offline but data is also on the server and there is some smart syncing (e.g. with CRDT). Others speak of apps requiring no remote data and no network needed, though I find box-product to not be very explicit in describing such category.

Also there does not seem to be any commonly agreed definition for local-first or even offline-first. I would assume the -first suffix means there are other ways but one is favored. So offline-first would mean it works online and offline, while local-first means it stores data locally and also remotely, meaning some syncing happens for any overlapping area. However syncing requires network connection, so is there really a difference between local-first and offline-first?

Personally I would use local-only or offline-only for apps that do not require respectively access to remote data or network, the latter being a subset of the former. With these -only terms in mind, I then see no difference between local-first and offline-first.