This statement very much depends on the kind of app you're developing, as mentioned in the article. Is the main use case communicating with another user? Do you need a third party API for your app's basic functionality? Sure, don't even consider offline first.
But what if the app is only about storing and displaying data entered by the user and you'd definitely also want to be able to use it on an airplane, e.g. a todo/notetaking/journaling app? Then offline first can make sense.
I'd even say that the complexity of developing an offline-first app can be lower than that of a classical client/server app + caching logic. Sure, you need to figure out how to do schema migrations and you probably want a kill switch to lock out older apps at some point. But the same applies in a classical setting when API-endpoints should be changed or removed. Basically, your document model is now your API. And a very simplistic conflict resolution strategy like „just take the most recent version“ is often good enough.
Once that + basics like auth and account creation are set up, it's very productive and low overhead to work with PouchDB/CouchDB and offline first:
- no need to coordinate with a backend team because nothing else than auth happens there
- simpler state management and error handling because the state in the local DB can always be assumed to be correct and the DB is always there
- no need for schema migrations as long as you only add new docs or extend existing ones
- it's great for quickly hacking a prototype or for beginners who just know some HTML/CSS/JS
But what if the app is only about storing and displaying data entered by the user and you'd definitely also want to be able to use it on an airplane, e.g. a todo/notetaking/journaling app? Then offline first can make sense.
I'd even say that the complexity of developing an offline-first app can be lower than that of a classical client/server app + caching logic. Sure, you need to figure out how to do schema migrations and you probably want a kill switch to lock out older apps at some point. But the same applies in a classical setting when API-endpoints should be changed or removed. Basically, your document model is now your API. And a very simplistic conflict resolution strategy like „just take the most recent version“ is often good enough.
Once that + basics like auth and account creation are set up, it's very productive and low overhead to work with PouchDB/CouchDB and offline first:
- no need to coordinate with a backend team because nothing else than auth happens there - simpler state management and error handling because the state in the local DB can always be assumed to be correct and the DB is always there
- no need for schema migrations as long as you only add new docs or extend existing ones
- it's great for quickly hacking a prototype or for beginners who just know some HTML/CSS/JS