Comment by mattdeboard | Hacker News Reader

Comment by mattdeboard | Hacker News Reader

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.

Reply on news.ycombinator.com