Mozilla localForage | Hacker News Reader

Mozilla localForage

github.com

As someone who's put considerable effort into implementing offline utility as an afterthought for a web application, the biggest favor you can do yourself when writing a Javascript web application is to make it "offline first".

In other words, make local storage, IndexDB, etc., the primary persistence layer. Then, at checkpoints, sync the whole MFing deal to the server (kind of like database checkpoints). From what I can tell this isn't a concept that's been explored by the community of dedicated front-end devs (of which I am decidedly not a member). However, I feel like it would be pretty awesome.

We haven't figured it out yet and have essentially thrown in the towel, settling for an ad hoc, informally-specified, bug-ridden, slow implementation of half of a "real" database in the name of "getting offline to work".

edit: If someone reading this eventually does get this figured out, and easy, please for the love of god let me know. My email address is in my profile.

I haven't been following Meteor too closely lately, but from the start it implemented minimongo on the client side, which is a good subset of the Meteor+MongoDB integration. This allows Meteor apps to mostly be 'offline by default.' Of course, Meteor makes many other decisions for you which you may or may not like, but I think they've been trying to pick out their functionality as libraries, so maybe there's a low hanging fruit there w.r.t. getting it to work offline without adhering to the whole framework.

For large client-side databases, minimongo won't cut it especially on low memory devices. Minimongo is essentially just an API on top of a JavaScript object. And that makes it a synchronous API too. This could pose performance issues (UI locking up for example) when fetching large datasets.

Of course if you use Meteor as intended with the large data on the server and only what is required for the active view on the client, minimongo is just fine

I haven't had the opportunity to try it myself yet, but it seems like this is the problem PouchDB (http://pouchdb.com/) is designed to solve.

This looks interesting, but in practical terms we would need a document model that maps client data to endpoints on the server, with the understanding they might not be similar. The data the client associates with a user might not necessarily match the server's modeling, for example.

In other words, the client should still be decoupled from the server. But PouchDB looks like it has the right idea on the client.

edit: I realize I Just kind of described an ORM. Sorry.

Previous discussion on this topic: https://news.ycombinator.com/item?id=7224225

As a backend dev who occasionally has to write some frontend stuff, this looks intriguing to me. Anything that lets me think less about the zoo that is the varied state of browser implementations is great.

http://offlinefirst.org/

Previous discussion: https://news.ycombinator.com/item?id=7224225

I think the bigger issue with offline storage is how complicated it is to do cross platform indices. FFx only supports IndexedDB and Safari only SQL. There are abstraction layers, but they're also a bit difficult to get working correctly.

K/V storage is nice, but once you have more than a few thousand objects that you want to index, it's a little bit painful.

Can someone explain to me why localStorage doesn't do async?

Reply on news.ycombinator.com