Browserify's pretty sweet. Not because of anything special that it's doing to make it work (though there's plenty of that to go around), but because of what it reveals about the nature of node.js and the implications it has for browser-based JavaScript, specifically that node core is heavily written in JavaScript. (Shocker I know)
In other words, a lot of core functionality just works with no change in the browser like, Streams, util.inherit, path, etc... and several with only moderate tweaks like EventEmitter and Buffer. If you don't believe me, just compare the files in the following two directories for a possibly illuminating experience: https://github.com/joyent/node/tree/master/lib https://github.com/substack/node-browserify/blob/master/builtins/ Anywho, I've been playing around with the new FileSystem API in the browser recently, http://www.w3.org/TR/file-system-api/ http://www.html5rocks.com/en/tutorials/file/filesystem/ but I can't shake just how unpleasant it is compared with node's, which got me thinking, how much work would it take to port fs to the browser? It turns out, the answer is simultaneously not much, and quite a lot actually. Let me explain... Since fs.js is written entirely in JavaScript, and since node doesn't augment V8, porting fs to the browser requires only that we to port the node C++ bindings utilized in fs.js and add process.binding support to browserify. Though I haven't gone too far in depth yet, it seems quite doable. The bindings are exposed via `process.binding('fs')`. See the following thread: https://groups.google.com/group/nodejs-dev/browse_thread/thread/5699149204ed0445/fc280b6509b57cc6?lnk=gst&q=browser+fs#fc280b6509b57cc6 For convenience, I've copied the list of functions and constants needing to be ported here: // from process.binding('fs') [ 'Stats', 'close', 'open', 'read', 'fdatasync', 'fsync', 'rename', 'truncate', 'rmdir', 'mkdir', 'sendfile', 'readdir', 'stat', 'lstat', 'fstat', 'link', 'symlink', 'readlink', 'unlink', 'write', 'chmod', 'fchmod', 'chown', 'fchown', 'utimes', 'futimes', 'StatWatcher' ] // from process.binding('constants') { O_RDONLY: 0, O_WRONLY: 1, O_RDWR: 2, S_IFMT: 61440, S_IFREG: 32768, S_IFDIR: 16384, S_IFCHR: 8192, S_IFBLK: 24576, S_IFIFO: 4096, S_IFLNK: 40960, S_IFSOCK: 49152, O_CREAT: 512, O_EXCL: 2048, O_NOCTTY: 131072, O_TRUNC: 1024, O_APPEND: 8, O_DIRECTORY: 1048576, O_NOFOLLOW: 256, O_SYNC: 128, O_SYMLINK: 2097152 } So the question to the community is.... Who's with me?! =D For the curious, Substack's on board with including the eventual (assuming it works) builtin into browserify. My fork of node-browserify for fs.js development (to eventually submit a pull request) (there's nothing there yet): http://github.com/CrabDude/node-browserify I'm also interested in porting the zlib module to the browser as well, but that's another thing entirely. Cheers, Adam Crabtree -- Better a little with righteousness than much gain with injustice. Proverbs 16:8 -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
