LCID-Fire/emscripten — comment on commit 81016c7c61a00ae15a7f4eaa7cbf949ee3439bc4
File: src/library.js line 402
By LCID-Fire:

1. Since the former is for storing files it is probably implemented (at least in Chrome) as a file store. The mapping between API and OS is minimal. So storing a few hundred MB or more is not a problem, whereas databases (in the latter name) tend to not handle big chunks of blobs that well. And of course to safe all data there is to a file (metadata, modification time, etc.) you'd have to introduce a huge amount of code in JS (which is not the fastest to begin with).
2. You access the ```FileSystem``` via ```requestFileSystem``` and a ```size``` argument. This is intended so the user is asked first whether the application may reserve chunk x of space. With ```IndexedDB``` an app could just spam the space of the user.
3. You have to serialize and deserialize like crazy if you use the other APIs
4. You can use the new ```filesystem``` URL scheme and directly access your stored files in HTML (or anywhere else).
5. You get direct access to all file objects like ```FileReader```, ```FileWriter```, etc. which even Firefox implements. So again this should be fairly fast.
(6. ```localStorage``` is not really an option since implementations currently limit it to ~5 MB of size :( )

For more please see [Use cases](http://dev.w3.org/2009/dap/file-system/file-dir-sys.html#use-cases)

So I will write a ```FileSystem``` on top of ```IndexedDB``` and ```localStorage``` but I am kind of grumpy about these browsers not implementing ```FileSystem``` API.