This is the one thing I'm missing the most about Notion, Miro, Google Calendar, and all of this - offline support. In German trains, I'm offline, on flights, I'm often offline; while traveling, I'm often offline. Offline capabilities are often neglected.
It's rare to see offline support in a web app for a few reasons:
LocalStorage is easy to use but too limited at 50Mb.
WebSQL got deprecated by FireFox because of secuirty issues years ago ( albeit is still somewhat supported in Chrome ).
The FileSystem API looked promising, and then google killed it.
IndexedDb is the only option, it's slow on writes, therefore requiring major hacks like absurd-sql to be performant.
It's also old, written before ES6, needs lots of boilerplate, but it does actually work.
https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_A...
Even then however there is a limit of 2GB of persistent storage it can use, which is workable but still:
Some versions of Safari are known to delete IndexedDB after 1 week because of power savings.
Chrome does not allow it unless you either accept notifications from that domain and/or pass a certain lighthouse score (these reasons are anectodal and not well-documented).
So yeah it's a mess, and a bit sad considering it will take years to ratify a better standard for this, but not impossible to do.
Also annoying to know that internally your browser is actually using sqlite under-the-hood anyway.
Web based game engines (i.e. XREngine) are able to get by with IndexedDB i think, and apps like https://github.com/actualbudget/actual created by the author of absurd-sql are good codebases to follow as example.
2 GB is a lot when you store plain json document data.
> IndexedDb is the only option, it's slow on writes
Only when you need a new transaction per write. Writing many documents in a single tx is not slow [1]
> Safari are known to delete IndexedDB after 1 week
This is not really a problem because if you have not used the app for one week, you can just replicate the data from the server again.
> WebAssembly based sqlite is coming along nicely too
WebAssembly cannot access the IndexedDB API. In my tests, all the wrappers that use webassembly are slower on writes the just using IndexedDB via javascript.
The fastest you can go is by using a Memory-Synced wrapper around IndexedDB, like LokiJS does it or the RxDB memory plugin. [2]
> This is not really a problem because if you have not used the app for one week, you can just replicate the data from the server again.
You can't if you haven't been able to push up the data for a week.
But in that case, you'd just have to remember to 'use it' ever day or so.
Had a use case a few years back for data collection app in remote African villages. There were definitely situations where a week without decent data access were possible, and 'offline' became a requirement.
"I lost data because I went on a vacation" is not an acceptable failure mode. Users understand "no data is saved" or "all data is saved," complex rules will lead to pain.
I had not looked into RxDB before thank you.
By any chance you know how much their Premium plugin with IndexedDB support costs, their price is not listed.
You could just wrap the web app in Capacitor for mobile and Electron for desktop, and easily use a SQLite db for unlimited persistence. If someone is interested in offline support, I don’t think it is a dealbreaker to have to download an app. That’s pretty common (eg Netflix, Spotify, hbo, any of the streaming services. The offline support only works in the app, not the web player).
Logically it's not a deal breaker (as Electron is quite mature) but practically there are a few problems:
Users are downloading apps less and less and relying more on web links from apps they already have.
So they mostly tend to end up on their browser anyway, and then workflow is disrupted while commuting and going in and out of signal.
Other less important reasons to consider would be in my opinion:
Electron is a bit too heavy on memory for users with 8GB and less of ram albeit it's gotten better lately.
I can't use ublock-origin on chrome or private-relay on safari while using an electron app (in this case however I still benefit from adding a blocklist like https://someonewhocares.org/hosts/ipv6zero/ to my /private/etc/hosts file on mac)
My experience is different regarding Electron apps. Many of the Electron apps I use (Spotify, Slack, Notion) have a web UI option. I never use it and now just a handful of people who sometimes open Notion or Slack on web.
> WebSQL got deprecated by FireFox because of secuirty issues years ago ( albeit is still somewhat supported in Chrome ).
Major technical corrections on this:
WebSQL was never implemented by Firefox. It was an experimental thing that Chrome and Safari shipped, but Firefox refused to because it was the wrong direction since it was certain to in the future cause either major compatibility or functionality problems. The Chrome and Safari developers agreed with this assessment, and so the draft was discontinued, and the two implementations deprecated. Safari finally removed its three years ago, and Chrome has begun the process of removing its this year.
There were no security issues whatsoever—it’s just that what had been made was unsuitable for standardisation, and no one was willing to do the work that would be required to make it suitable for standardisation perhaps because there was no consensus that it would still be a good idea in that form. All up, the WebSQL story is pretty much “it seemed like a good idea at the time because people want the result, and we implemented and shipped it because it was really easy, but then we stepped back and thought things through and realised the entire approach was a mistake”.
> The FileSystem API looked promising, and then google killed it.
The File System Access API [0] exists today. Unfortunately it's only Chrome based browsers, and not Firefox supporting this. Mayby you referred to an older "standard".
Insightful comment! I've faced similar issues when wanting to store an arbitrary amount of data "locally", but usable via a web interface. Because of the various limitations you enumerated, our conclusion was to have a local web server, written in Go, that stores what we need on disk. Then the web application talks over a JSON HTTP API when storing and retrieving.
I think we need to define better (or re-define) what offline support actually means. Even an ideal fantasy implementation of a PM app with offline support will have limitations unless you sync the entire company’s space with all clients (users, files, docs, comments, tasks, roadmaps, etc).
So IMO selling offline support as a feature has to come with a clear description of what it means.
We built Linear(https://linear.app) to be offline first from the beginning. It’s kind of hard to do later.
It’s architected in a way that client syncs the data, all the actions happen locally and then delta packets are synced back to the server. This also makes the app really fast because the client doesn’t have to wait for the network to complete the action.
I love linear but your advertised "offline mode" is not what I would expect it to be.
If I open the Mac app when I'm offline I just get a blank window and have no access to any of my data or a window telling me "Unknown Error loading your workspace data". So I have to login once and keep the app open before I go offline. If I close the app while being offline and reopen it without internet connection I won't have access to any of my data. This is sadly killing the app for me. Is this expected behaviour? Just a "read only" mode of the last state I had when last logged in would be enough for me.
Linear looks great! I love how focused it is on this specific problem area. I don’t find all-in-one apps like OPs very useful. Can’t replace all my tools like chat, docs, project management, etc at once.
Thank you for building Linear the way you have! So snappy in so many ways.
I think it could be interesting to see Linear add personal/private TODO support of some kind… like everyone gets a TODO list that is mostly a view of your linear tickets with each as a bullet point in a document (similar to when you mention them in a Notion checklist doc) but where you can also add other items which are just text (and/or entries in a personal/private linear space)
Offline support is costly, and we do not have the resources for it yet. For businesses that have a lot of small customers, offline support is challenging.
Really appreciated this no-no sense, straightforward reply.
I agree, the reason offline support is often not that great is that the customers who are most likely to pay for your product are the least likely to have issues with online connectivity or to care about offline support, OP's edge cases notwithstanding.
I even travel fairly often in the US and it's rare when I'm on a plane that doesn't have wifi.
To add why: the ecosystem is immature. I am building a decentralized app (the old way) but with an event sourced architecture (append-only list of JSON events/commands).
The storage itself is trivial but for everything else (queries, syncing, conflicts, validation, permissions, schema changes) there's little support and I had to make my own stuff. It works for me, because because I only have 2-3 entities but your app is much more complex, so I wouldn't recommend it even if you started from scratch.
I will say that there's nothing that really stops offline aside from ecosystem support and maturity. All it really takes is a medium-big well maintained project that solves 80-90% of use cases. I think CRDTs are promising for the data layer because it simplifies the API surface (at the expense of complex implementation).
Yeah, when we built our product (kitemaker.co) we introduced offline capabilities quite early because my co-founder often had very spotty wifi during train commutes. We ended up making all writes totally optimistic with data sync in the background. Has the nice performance benefit of the frontend never waiting for the server as well.
Offline is nice in theory, but not as useful in reality. For solo projects, I will skip all the fancy tools and just use org-mode (emacs), which is offline. For a company project, most people don't get to decide which tool to use. Besides, if you spend significant time in a project management tool, even if your title is project manager, there is something seriously wrong with the project already. In which case, the tools is not the problem you should be worried about.
This is the one thing I'm missing the most about Notion, Miro, Google Calendar, and all of this - offline support. In German trains, I'm offline, on flights, I'm often offline; while traveling, I'm often offline. Offline capabilities are often neglected.