Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Not sure how this compares to the myriad other similar libraries that have been around for a while, like Lawnchair? That would have made a good section in this blog post.

But the real problem with offline storage is that Apple refuses to support IndexedDB, when every other browser vendor implemented it years ago (even IE!). My question is, why? I can think of three potential answers:

1. They just don't care about the web. (But in that case, why raise such a stink about not letting other web browsers run on iOS?)

2. They are incompetent. (But in that case, how have they made so much other great software? And IndexedDB isn't even very complicated. Even if it was, they could just copy Mozilla's or Google's open source implementation.)

3. It's a conspiracy to cripple HTML5 apps and encourage people to write native apps. (I don't like conspiracy theories, but it's hard to come up with a better explanation than this...)



Or: it's low on the roadmap and it's not something that markets well, since the non-dev user doesn't care about IndexedDB support.

Occam's Razor applies here.


I guess that's possible, but then why did Google, Microsoft, and Mozilla all decide it was important enough to implement years ago? It's not like this is some controversial political thing like DRM, or some huge technical challenge that would require a lot of resources - it's just a simple database API. Even if they ignored the multiple existing open source implementations, they could build their own very easily. And they've had years to do it.

Incidentally, I've been trying to make non-dev users care. I wrote a semi-popular HTML5 game that runs everywhere except iOS because it uses IndexedDB. When people complain that it doesn't run on iOS, I implore them to direct their complaints at Apple for not supporting IndexedDB. AFAIK nobody has even gotten a response.


I agree that the absence of IndexedDB is a little weird, but I don't know if it's "crippling," just annoying. Safari has supported Web SQL for a long time. While it was (rightly) abandoned by W3C because it was attempting to standardize SQLite as an implementation, there is a polyfill (https://github.com/axemclion/IndexedDBShim) that implements IndexedDB semantics on top of Web SQL. It looks like localForage also supports Safari using Web SQL.


The polyfills (there is another by Facebook in addition to the one you linked) are slow and buggy (look at all the open issues, or try using it in a non-trivial project yourself). Web SQL in Safari is also slow (check any performance benchmark) and buggy (see the huge bugs introduced in the most recent version of Safari). So the truth is probably closer to "crippling" than just "annoying". Who is going to go through the trouble of working around all the polyfill and browser bugs, only to be rewarded with horrible performance? Not many people except those with simple needs. Making something complex? Better put it in the App Store.

Libraries like localForage are great if you're doing very simple stuff. But if you need to use slightly more advanced DB features (indexes, transactions, etc), they don't work. IndexedDB, while not a panacea, does generally work for that stuff... except for Safari :)


It not marketing well isnt the simplest answer, it markets as well as every other html5 feature that they have implemented.

Given they already have a working implementation just waiting to be merged, and webSQL is both dead and their implementation horribly broken, I also cant come to any other conclusion that Apple have little interest in their devices being used for advancecd web content


re: lawnchair

Would have been nice seeing as it solves the same problems in a very similar way. I would rather have one good implementation than two buggy ones.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: