Comment #⁨1⁩

I get that local-first is hard and comes with challenges with data consistency. I also get why Tana tries to invalidate sessions when the app is updated, to prevent drift.

But all this said, I wish Tana erred on the side of good user ergonomics rather than easy development.

I think the biggest point of friction here is the long load time as your Tana workspace(s) are loaded into memory.

Whatever you can do to ensure lazy loading or local caching is appreciated.
Right now, Tana is a bit of a “worst of all worlds” type of app.

It’s not local-first like Obsidian or LogSeq, yet I’m paying the up-front cost as a user to load all that data into memory without benefiting from local caching beyond a single session.

It’s not an optimized cloud-based app like Notion, where content is lazy-loaded as I navigate. So I can’t benefit from (faster) initial loads.

It’s very similar to Roam, which has the bad habit of loading your whole graph into memory each time.

A good compromise would be to let me locally cache just my personal workspace, in local storage or a SQLite DB, however you implement it, as long as it loads near-instantly and writes reflect optimistically while syncing in the background.

Surely there’s no need to ensure perfect consistency between multiple users, since my personal workspace is single-user. I don’t mind if there’s eventual consistency between the canonical cloud store and my local cache, as long as every session loads near instantly after perhaps the first cold boot.

Also, there’s no need for this to be a native mobile app. It can be a PWA, with the web interactions spruced up to work well on touch devices and web workers leveraged to do some of that syncing work