Comment by stopachka | Hacker News Reader

Comment by stopachka | Hacker News Reader

Parent Full thread

Imagine a you want to create a 'todo' list.

If you used classic Rails, you'd be very productive. You could write most of your code on the server, and sprinkle some erb templates.

However, if you want to improve the UX, you generally end up writing more Javascript. Once you do that, things get hairier:

You create REST endpoints, funnel data into stores, normalize them, and denormalize them. Then you write optimistic updates. If you want offline mode, you worry about IndexedDB, and if you want it to multiplayer, you end up with stateful servers.

If you had a database on the client, you wouldn't need to think about stores, selectors, endpoints, or local caches: just write queries. If these queries were multiplayer by default, you wouldn't have to worry about stateful servers. And if your database supported rollback, you'd get optimistic updates for free.

This is the inspiration for Instant: it gives you a 'database' you can use in the browser.

If you're curious, I wrote a more detailed essay about this here:

https://www.instantdb.com/essays/db_browser#client

> If you want offline mode, you worry about IndexedDB

I don't understand the offline mode. If I was to make a single player offline game that runs on the browser, sure, offline mode makes sense and I want to store on client machine.

But in the space of web apps, everything data needs to be synced with server db.

Why would I want to store half of my to do list on client and other half on the server? The end goal is the customer data is stored in the cloud...

So the user could keep working on a plane, when cable, or electricity is out, etc. Wants to experiment without inflicting changes on others, like dvcs. The user may not have “their data on your cloud” as an end goal.

There’s a paper by Kleppman et al about local-first apps that is worth a read.

I'am always skeptical about this offline use case. Is it really as important as the CRDT community claims?

If you are on a plain, you could also just read a book.

It’s about being in control of your data. git folks thought so too, and why not? The paper mentioned is approachable.

I'm a bit naive here, so asking a stupid question. I have an `offline only` app where I read things from the file system (markdown) and currently store them in a redux state for accessing filepaths and ids.

I've been planning to move to indexedDb using dexie for kinda the same use case of easier transaction, not maintaining a huge redux state (16k lines or so), and improved performance.

Now if my app is not supposed to be backed by a online database (single player only, complete offline), would instant make sense for this?

or would indexedDB be the safer choice?

I would not recommend using IndexedDB as your primary storage. This is because browsers can sometimes delete the underlying store (there are various reasons for this, but one is that the user is running out of space on their machines) [1]

If you have access to the file system, I would consider using SQLLite to store everything. If you end up then wanting auth / collaboration, you could try Instant.

[1] This is a good comment that goes deeper https://news.ycombinator.com/item?id=28158407

Ooo nice read! Since I use tauri, mac would have the browser as safari, and since it's a purely offline app, losing that is disastrous!

I'll move over to SQLite in that case, since that can atleast be persisted! Thanks!

Reply on news.ycombinator.com