In general, projects like these are great — they unify a lot of underlying architecture and, with time, can make them ubiquitous to use. LocalForage[1] is a great example of this, and I would recommend using that over regular local storage for every serious web project.
This project raises my eyebrows at two technical points, though:
There is no mention of "Promise" or "async/await" in the readme. I know the project tries to mirror the current Node filesystem, but that also offers Promises[2] — something I would call the industry standard for writing readable async code these days. Despite being in beta, I would argue that this project should also aim to support Promises over nested callback pyramids as the default pattern.
Secondly, maybe I'm just not familiar with the idea, but I'm very sceptical of the AsyncMirror backend — when you use an asynchronous service synchronously, how do you guarantee all writes are flushed before the user leaves the page?
Other than that, a project of this scale is no small feat, so godspeed to all contributors.
It’s straightforward and quick to write a promise wrapper on callbacks. If one of the goals of the project is interoperability, then it makes sense to leave async/promise implementations to the user.
BrowserFS seems to even have Dropbox etc. backends, and GUN already has a NodeJS `fs` adapter, so could theoretical could seamlessly swap BrowserFS in for fs and get GUN backed up to Dropbox!!!
I posted this earlier but it failed to gain enough upvotes, thx. BrowserFS is a pretty darned nice library that I'm using to make an extension based file manager.
I'm hoping IndexedDB is fast enough for my use case. I haven't been able to benchmark it yet.
The browser has become a virtual machine that routinely executes untrusted code downloaded from the internet. The capabilities of the virtual machine will expand until it becomes native to the host system.
To be perfectly honest, yes it does. But what am I to do if I want maximum interoperability and ease of installation? The difference in penetration my project will get via web extension installation vs binary distribution is huge. I can extend it later with native application calls. Not to mention all of the interactive content that we instantly have access to in the browser vs only on a single person's machine. In addition, the extension also works on mobile Firefox for both ios and android when I use Fenec and extend it.
There are use cases that you'll see in the future that couldn't grow or exist otherwise.
Hyperbolic tldr; Don't be old and crotchety. Join us, lead us, or die.
> Hyperbolic tldr; Don't be old and crotchety. Join us, lead us, or die.
I know it was hyperbole but this sort of attitude is what got a generation of technologists and end-users to blindly accept oversharing their personal data, having that data used by nefarious third parties, and to be spied on. We're now in the midst of that same generation realising this far too late and having the monumentally difficult task of convincing their technologically-illiterate friends and family to move away from the shiny reality they promised but never delivered.
I'm happy with softly-softly-catchy-monkey rather than driving off the side of the cliff at 100 km/h, thank you.
> If you decide to use BrowserFS in a project that leads to a publication, please cite the academic papers on Doppio and Browsix
I empathize with their desire for more citations, but this rubs me the wrong way. Either they don't trust authors to cite sources appropriately, or they are asking authors to create inappropriate citations. I suggest trusting authors to cite appropriately.
Moreover, using a system isn't the same as building on work from a paper. If one needs to add a reference for a system, it may be more useful to cite a more up-to-date reference for the system rather than the original paper where it was proposed.
In general, do people recommend using libraries like this for in-browser filesystem or building it from scratch? I’m looking for something to sync files between Google Drive, IndexedDB, and which has a treeview component to display and modify files.
This project raises my eyebrows at two technical points, though:
There is no mention of "Promise" or "async/await" in the readme. I know the project tries to mirror the current Node filesystem, but that also offers Promises[2] — something I would call the industry standard for writing readable async code these days. Despite being in beta, I would argue that this project should also aim to support Promises over nested callback pyramids as the default pattern.
Secondly, maybe I'm just not familiar with the idea, but I'm very sceptical of the AsyncMirror backend — when you use an asynchronous service synchronously, how do you guarantee all writes are flushed before the user leaves the page?
Other than that, a project of this scale is no small feat, so godspeed to all contributors.
[1] https://github.com/localForage/localForage
[2] https://nodejs.org/dist/latest-v10.x/docs/api/fs.html#fs_fs_...