This was before things like local storage, etc. were available in browsers.
So I set out to build the simplest thing that could provide this functionality for the type of applications I was writing. The interface, HTTP with REST conventions was chosen primarily out of necessity as it was easy to get data out and back into the browser this way.
I didn’t realize it at the time, but I was beginning to write a filesystem, an essential part of creating an operating system. You could forgive my obliviousness to this if not for the fact that had spent decades studying and made several attempts at building my own operating systems in the years leading up to this point.
Within a few days of starting the project it worked well enough to fulfill its objective and I started to realize that it had the potential to do more, to take the next step toward becoming an operating system by providing an standardized abstraction of the underlying hardware. This could be accomplished by combining it with another earlier project of mine RESTduino. Later I considered adding server-side code execution to JSFS, which would fill in the last piece of the operating system puzzle: the scheduling and execution of programs.
Before I could get too far on these other things I found an application for the JSFS filesystem that allowed me to work on that more-or-less full-time. This allowed me to turn JSFS into a high-performance filesystem with a range of powerful features, but it also meant that the other components were pushed-aside. In the following years I never got a chance to spend much time on them, and web application development turned-away from the sort of HTML & JavaScript approach I used and instead revolved around frameworks and such.
Recently I’ve been revisiting these ideas and as I find scraps of time to work on them I realized that by combining these three components the result could be an operating system for the web. We think of operating systems as large, complex systems that include everything from the kernel to the desktop environment (or even the web browser), but what I have in mind is a more fundamental operating system that provides an interface to the hardware, a filesystem and the ability to schedule and run programs.
Obviously, other operating systems can run web applications, but this operating system runs them natively. The fundamental system programming interface is HTTP itself, the opcodes are GET, POST, etc. The standard I/O is an HTTP request and response, and the systems programming language is JavaScript.
By extending JSFS to not only store files but execute them, we create a simple, portable programming environment that will feel familiar to any web developer. By exposing hardware resources at standardized JSFS namespaces (a URL-compatible internal representation of the resources a JSFS instance manages) any imaginable device could be utilized by web-based applications.
It’s hard for me to capture in a single post (and a single writing session) why this is so powerful and in turn why I’m so excited about it. It is both an old and new way to write applications for the web, and I think it’s unique in that it may be the first operating system to treat web applications as the primary, native software for the system. Coupled with other JSFS features like the universal URL-compatible namespace (which could eliminate the need for DNS), deduplication, federation and distributed processing and operating system like this could solve a lot of long-standing challenges in web application development in addition to making web development fun and accessible to people who are not served well by contemporary web development.
I will try to follow this post with more detailed and specific examples of how this new OS, which I refer to as JS/OS, works and how it can be used to do all the things I mention above. Hopefully over time it will become more clear as it becomes more real.