I'm a huge fan of the work here & strongly strongly believe in file-system oriented architectures.
Being able to use a wide number of existing "server side" libraries in the browser could be a huge win.
And this has interesting server side applications too, where one can use the same Node.js code but target diverse & interesting backends & overlayed systems. Having a virtual-fs is an incredibly powerful and useful concept.
"Everything is a file!" still sounds like a great idea.
Alas BrowserFS lacks Streams support. Given how async oriented and streams based a lot of new JS tends to be, that is a huge sticking point for me, and a glaring exception that will rule out using a very sizable number of existing packages that otherwise would benefit greatly from BrowserFS. Issue 124, Support streams: https://github.com/jvilk/BrowserFS/issues/124
As an alternative: it lacks the flexible, pluggible/mountable backend of BrowserFS, but level-filesystem does do streams, and can be run in the browser (when combined with level-up): https://github.com/mafintosh/level-filesystem
Final aside, I always thought it would have been cool if the virtual file abstraction that the Gulp build tool built - Vinyl - had started getting used outside Gulp. Theres no file-system model, just a file model here, except for implicitly in that files have paths, but with some mapping one can imagine making something like BrowserFS or other with the Vinyl model. That said, I think John has done a great job with his rigorous, TypeScript-ed object model in BrowserFS.
https://www.npmjs.com/package/vinyl
Here's to hoping #124 - Streams Support - sees some progress. Great library John!
> I'm a huge fan of the work here & strongly strongly believe in file-system oriented architectures.
Me too! You might be interested in the way scheme-handlers abstract/generalize filesystems in Objective-Smalltalk. http://objective.st Super-simple + superficial example:
file:hello.txt := 'Hello World!'.
I've used the same concepts to treat a sync system effectively like rsync. You have common names (possibly translated) and tell the system to copy things over. It tells you when it's done so.
Thanks, rektide! Streams support haven't been added since a) there hasn't appeared to be great demand from folks using the library, and b) I haven't needed it for any project at all.
Feel free to leave comments on the issue if you or others would like to use BrowserFS but have been dissuaded because it lacks streams. I'm interested in your use cases. If your files are relatively small, then basic stream support can be bolted on with 100% preloaded files. If they are larger, then it would require a larger effort to bolt on incremental file loading into each backend to support streams.
For those new to the project: this is the file system that's used alongside Doppio, written by the same John Vilk. Both projects are excellent examples of large Typescript projects, the code is very well documented and readable.
What the heck? That's a thing you can do now? I just really wish someone time-travelled this back to like 2001 when people were still confused about Java vs JavaScript and MS had their own JVM implementation.
In seriousness, is the performance of Doppio bearable? Also, what are the use cases for a thing like that?
Performance is 24-40x over the HotSpot (Oracle Java) interpreter on compute-intensive benchmarks. The primary use case is for non-compute intensive code.
To better explain from my previous comment, the use case is that you can take a Java program and run it in the browser with no modifications. So, if you have a legacy program or library and rewriting it would be a large undertaking, you can run it in DoppioJVM.
Gotcha. I guess I have been happily avoiding Java apps for the past 10 years. The only one I routinely use is the Cisco VPN client, which wouldn't really work in Doppio.
For the past 6 months my startup has been compiling everything from node into browser - emulating a lot of the node's APIs along the way and frankly it has been a godsend in terms of testability, readability and modularization.
BrowserFS is yet another module to consider to add as part of this toolchain which will help us stick to the basics instead of reinventing the wheel. Unfortunately, there is no S3 backend at the moment but by having a quick look at memory backend it may be an easy thing to add.
The work on that has been discontinued by W3C (https://www.w3.org/TR/file-system-api/), so we have to rely on extensions... It is a useful tool however, it could have saved me a lot of time if available earlier.
From the first line of the linked page, "BrowserFS is an in-browser filesystem that emulates the Node JS filesystem API and supports storing and retrieving files from various backends."
Ordinarily, there's a hard cross-orgin security policy separating URLs like:
file:///Users/user/plain.txt
From:
http://example.com/plain.txt
I feel like something that blurs this boundary could be dangerous for non-developers and less techincal folks.
Things like Flash and Java applets often bridged that gap, causing many problems.
I wonder how many people understand the reasons for a clear distinction between browsing files on your machine with an FS explorer, versus an isolated file store jailed or sandboxed to the browser?
Being able to use a wide number of existing "server side" libraries in the browser could be a huge win.
And this has interesting server side applications too, where one can use the same Node.js code but target diverse & interesting backends & overlayed systems. Having a virtual-fs is an incredibly powerful and useful concept.
"Everything is a file!" still sounds like a great idea.
Alas BrowserFS lacks Streams support. Given how async oriented and streams based a lot of new JS tends to be, that is a huge sticking point for me, and a glaring exception that will rule out using a very sizable number of existing packages that otherwise would benefit greatly from BrowserFS. Issue 124, Support streams: https://github.com/jvilk/BrowserFS/issues/124
As an alternative: it lacks the flexible, pluggible/mountable backend of BrowserFS, but level-filesystem does do streams, and can be run in the browser (when combined with level-up): https://github.com/mafintosh/level-filesystem
Final aside, I always thought it would have been cool if the virtual file abstraction that the Gulp build tool built - Vinyl - had started getting used outside Gulp. Theres no file-system model, just a file model here, except for implicitly in that files have paths, but with some mapping one can imagine making something like BrowserFS or other with the Vinyl model. That said, I think John has done a great job with his rigorous, TypeScript-ed object model in BrowserFS. https://www.npmjs.com/package/vinyl
Here's to hoping #124 - Streams Support - sees some progress. Great library John!