5 ms·
My biggest gripe with offline-first capability of PWAs is speed. a network roundtrip is generally faster then fetching the same information from indexeddb, and
by y4mi 5y ago
My biggest gripe with offline-first capability of PWAs is speed.
a network roundtrip is generally faster then fetching the same information from indexeddb, and you still have to sync first because indexeddb tends to get wiped at inopportune times.
its great if you're writing a traditional app though, but really unfortunate wrt to the PWAs
- getcrunk 5y agoReally? I've never used index db but to confirm your saying to fetch data from local memory is slower than network round trip?
- tehbeard 5y agoindexedDB is quite a low level in what the interface gives you. This includes what options you have available for querying (just accessing a key range, upper/lower bound, forward or backwards (backwards can be much slower), rather than a full query language like SQL etc.. So you need to design your app / data format and pre-plan any queries so you'll have the indexes you need, or do some glue logic to combine indexes as needed.
- dmw_ng 5y agoThe complaint was about IndexedDB access, not local memory. Folk mentioning this are usually referring to the disastrous implementation in Chrome: see https://dev.to/skhmt/why-are-indexeddb-operations-significantly-slower-in-chrome-vs-firefox-1bnd https://dev.to/skhmt/why-are-indexeddb-operations-significan... and https://jlongster.com/future-sql-web https://jlongster.com/future-sql-web
- getcrunk 5y agoWow. Orders of magnitude slower than ff.
- tehbeard 5y agoWhy is that?. Is this because you're on a fibre link? indexedDB is being used with several layers to add a comfy SQL and ORM layer for you? I've used indexedDB on a couple of projects at work, while there are definitely downsides with its indexing design, limited querying options and the menagerie of fuckups by Team Fruit(TM), it works well as a local cache when our clients are out on site with their customers and all they've got is a crappy intermittent 3/4g signal.
- y4mi 5y agoIn my tests I actually went with plain indexed db at the end, because I wanted to make sure it's as fast as it could go. It's true that the indexeddb access is faster then a 3g signal with timeout, but that wasn't happening often enough to warrant slowing down all other requests measuribly just to speed up the rare case when this occurs. Loading from indexeddb generally took about 100-200ms, loading data over WLAN/4g from a remote server (~500km real life distance) over socket took < 50ms overall for multiple json payloads with about 200 serialized entities altogether. And doing both at the same to serve whatever finished first wasn't worth the trade for me either, as the indexeddb access isn't cheap from a energy drain perspective either. Other people might come to different conclusions depending on their challenges.
- mikojan 5y agoCurious! Even with machines on the same premises IDDB has been orders of magnitutes faster for us. In the beginning we were storing carbon copies of mariadb tables and initial load times went down drastically.
- radex 5y agoIndexedDB is a _bad_ API, and making many small read/write operations on it is absurdly slow. This is one of the reasons why WatermelonDB on web only uses IDB as a dumb storage medium but actually does all the database'y things in memory. You won't reasonably scale to gigabytes this way, but for most PWAs this is plenty enough and MUCH faster in practice. Certainly far faster than network.
- oblib 5y agoYou can use CouchDB installed on a desktop PC and tell PouchDB to use that instead of the web browser's IndexedDB for offline-first apps. This approach gets you pretty close to native app speed.