Pretty slick. Anyone thinking of using this for anything serious, though, should note the disclaimer:

“The HTML5 Filesystem API is only supported in Chrome. Therefore, the library only works in Chrome.”

This is a perfect compliment to something like jstorage though. html5 localstorage gives about 5mb of data stored as text (~5million characters). But chrome uses UTF-16 encoding giving you only about ~2.7 million characters of storage. Effectively halving the size of the total storage. Something like this might work well in place of jstorage on chrome.

Isn't there a binary storage option? I don't wanna Base64 encode everything... Seems ridiculous.

Nope. Probably something to do with security. But everything needs to be string. It works well for everything other than images.

Nice demo: http://html5-demos.appspot.com/static/filesystem/filer.js/de...

Pretty neat but not sure why you would use UNIX commands for the method names. Good clear names go a long way when adopting a new library.

Every file API always has its own syntax that's hard to remember. I like the fact this API is leveraging an existing standard, finally a file API without having to look up the docs for every call.

But why UNIX commands? This is a JavaScript library that's going to be used by developers that most likely don't know UNIX. Just spell out the method names. Instead of "cp()" just use "copy()".

"copy" is straightforward, how about to create a directory? Is it "create", "makeDirectory", etc?

Even for "copy", which order to the arguments go? This has historically been ambiguous. If you base it on the Unix standard, you get that for free.

I'd rather pick one standard many people know than just choose yet another arbitrary set of API signatures. So it really comes down to Unix versus MS-DOS, and I think most professional web developers would opt for a Unix standard. (Yes, there are still quite a few Windows-based developers, but I don't know how much time they're spending on the command line. And I say that having spent years (collectively) developing web apps on client sites where Windows was mandatory.)

This, I think, would be totally fair enough, but I think you'd get a disparity between the 'standard' and the implementation.

You mention arguments. In PHP, for example, you have `mkdir`, and `rmdir`, and all that. You supply the file or directory string as the first argument, and a limited subset of options as the rest.

In Unix you have `mkdir`, but you supply the flags before the name of the directory to create.

Further to this, it's all more verbose, so you don't set the `-R` (or `-r`) argument to true to make it recursive in the PHP equivalent.

So there's no real standard being implemented per se, and your JS function 'ls()' or 'cp()' is a JS function in all but name. When it comes to using it you still have to read the doc to figure out what on earth you're supposed to do with it.

    filer.cp('myFile.txt', '/path/to/other/folder', 'file.txt', function(entry) {}, onError);

    cp myFile.txt /path/to/other/folder/file.txt

I'm not seeing how function name familiarity reduces confusion. Because it's evident the arguments aren't the same, and you can't tell people to look at Unix man pages to figure out how to work a totally unrelated lib.

>>> You mention arguments. In PHP, for example, you have `mkdir`, and `rmdir`, and all that. You supply the file or directory string as the first argument, and a limited subset of options as the rest.

http://linux.die.net/man/2/mkdir

http://php.net/manual/en/function.mkdir.php

... they look similar enough to me. The PHP function has some additional tricks, such as creating all parent directories up to the specified path.

http://linux.die.net/man/2/rmdir

http://php.net/manual/en/function.rmdir.php

In this case, the POSIX/C function accepts only one argument. So does PHP, for common usage.

>>> In Unix you have `mkdir`, but you supply the flags before the name of the directory to create.

I think you might be confusing the programs mkdir and rmdir (which don't care much about argument order) with the functions mkdir and rmdir (which, similar to filer.js functions, are part of the API).

From comments: "How is filer.js better or different than the HTML5 Filesystem API?". I'm curious what the answer would be - but perhaps more importantly, the flip side - why does HTML 5 do such a bad job that filer.js has a reason to exist?