4 ms·

Mozilla localForage

streptomycin 13y ago
Previous discussion: https://news.ycombinator.com/item?id=7224225 https://news.ycombinator.com/item?id=7224225
akerl_ 13y ago
Previous discussion on this topic: https://news.ycombinator.com/item?id=7224225 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.
dudus 13y ago
Can someone explain to me why localStorage doesn't do async?
mattdeboard 13y ago
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.
- goldfeld 13y ago
  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.
  - matb33 13y ago
    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
- bluefinity 13y ago
  I haven't had the opportunity to try it myself yet, but it seems like this is the problem PouchDB (http://pouchdb.com/ http://pouchdb.com/) is designed to solve.
  - mattdeboard 13y ago
    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.
DTrejo 13y ago
http://offlinefirst.org/ http://offlinefirst.org/
pixelcort 13y ago
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.

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

Previous discussion on this topic: https://news.ycombinator.com/item?id=7224225 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.

dudus 13y ago

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

mattdeboard 13y ago

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.

goldfeld 13y ago
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.
- matb33 13y ago
  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
bluefinity 13y ago
I haven't had the opportunity to try it myself yet, but it seems like this is the problem PouchDB (http://pouchdb.com/ http://pouchdb.com/) is designed to solve.
- mattdeboard 13y ago
  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.

DTrejo 13y ago

http://offlinefirst.org/ http://offlinefirst.org/

pixelcort 13y ago

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.