An operating system for the web
jasongullickson.com
jasongullickson.com
These things are all applications. I don't understand this predilection that webgineers have to overstate the importance of the space they work in and deliberately try to obfuscate common terminology. Just go play with your HTML and JS and let the people who are not afraid of working at the hardware level do their job without trying to encroach on their territory and nomenclature.
(Operating system is a very vaguely defined term)
From Wikipedia:
"An operating system (OS) is system software that manages computer hardware and software resources, and provides common services for computer programs."
In the case of the web browser, half the application runs on someone else's computer usually far away from the user, and the other half runs in the browser.
The web browser doesn't manage computer hardware and software resources. It doesn't "provide access to the hardware". It can provide access to API's that can leverage the operating systems real hardware interfaces. Like other desktop applications, it only has access to the API's the operating system provides. These are not hardware interfaces, but software interfaces provided by libraries, the real operating system kernel etc.
It's like trying to say a set square is a spirit level just because you can check straight lines with both. Only one of them can tell you if something is level or not.
A webapp uses multiple computing resources.
But the software that gives resoruces to a webapp is not at all like an OS to you.
In the past (read: 80's and 90's), that mean you'd have applications running on top of your OS, so you could delegate screen, device drivers, I/O, interrupt requests, and everything else to the OS.
Now we're in a different abstraction layer. The browser became your interface to the hardware in many respects. If you're an application developer, you can develop "for the web", instead of targeting each OS individually. And with WebUSB/ WebGPU/ etc, the browser becomes even closer to a real OS.
Now, it's interesting that mobile apps push us back to the 90's model. The promise of "write once/run everywhere" is gone, and you'll not only develop at least 2 separate mobile apps (potentially more -- e.g., tablets, TV, gaming consoles), but also deal with different OS APIs and different AppStore policies.
I could see this being cool for decentralization/peer-to-peer. It's essentially HTTP in front of a FS. It could be implemented as anything from a blockchain to a NoSQL db to AWS S3.
OP says:
> This was before things like local storage, etc. were available in browsers.
And looking at the repo it's like a decade old. Would be really cool if OP could find a use case and share that - I think that of all libs/frameworks: Show me the thing being made with it.
I don't think it "works" in today's world where installed apps on iOS / Android are more common than web applications.
But it uses nodejs normal fs adapter to talk to the filesystem (or forwards to a GCP bucket). This is no more a filesystem than WebDAV is, which is already standardized and widely supported for the same usecase as JSFS.
> Obviously, other operating systems can run web applications, but this operating system runs them natively.
But does it really? In the proposed model could I run a browser on JS/OS?
The proposal seems to be some combination of a wrapper around nodejs fs module (or the standard GCP storage client), a wrapper around nodejs vm module to eval code, and a arduino sketch that reads/writes GPIO.
Either my reading comprehension is bad or there is not much here.
Makes me frequently hate my life but its what we got and it'll probably be around until I die
edit: if you are a competent Aestiva programmer, please shoot me an email at calvin@pobox.com