The Internet Operating Environment
Princesa SophiaThis article was formerly named:
"The Internet OS: A Community-Driven Operating System Built from JavaScript".
I think this title does not apply anymore for what i want. But the link name will be the same.
PAGES:
2;
We normally think of the Internet as a place where software is published and websites are places where software is executed.
What if we reversed that relationship?
What if the browser were not merely a program used to access applications, but the computational substrate on which an entire operating environment could exist?
And what if the software of that environment did not have to come from one repository, one server, or one organization?
It could come from the Internet itself.
This is the idea behind what I call the Internet Operating Environment, or more informally, the Internet OS.
It is not intended to be another operating system kernel written in JavaScript. It is not intended to emulate Linux inside a browser. It is not simply a desktop interface made with HTML and Canvas.
The fundamental idea is different:
Use the browser and HTML document as the computational host, JavaScript as the executable computational substrate, and the Internet as a distributed source of interoperable software modules.
The Browser Is Already a Computer Abstraction:
Modern software operates through layers of abstraction.
At the physical level, we have:
CPU RAM GPU Storage Network Input devices Output devices
An operating system abstracts these resources and exposes higher-level interfaces to applications.
A browser does something similar again.
Instead of giving JavaScript direct access to a network card, it provides APIs such as:
fetch() WebSocket WebRTC
Instead of exposing the GPU directly, it provides:
Canvas WebGL WebGPU
Instead of exposing hardware audio directly:
Web Audio
Instead of exposing keyboard and mouse hardware:
DOM Events
And instead of exposing raw memory:
JavaScript objects Arrays TypedArrays WebAssembly memory etc.
The browser has already constructed a large virtual machine around the physical computer.
JavaScript executes inside that environment.
Therefore, from an architectural perspective, we can treat the browser as a kind of virtual computer, with JavaScript acting as its programmable computational layer.
The Internet Operating Environment simply adds another layer above it.
Physical Computer
↓
Operating System
↓
Browser
↓
HTML Document
↓
Internet Operating Environment
↓
JavaScript Modules
↓
Applications
The goal is not to reproduce the lower layers.
The goal is to exploit the abstractions that already exist.
JavaScript as the Computational Substrate:
JavaScript is normally described as a scripting language.
That description is appropriate from the perspective of conventional software development, but computationally JavaScript is much more powerful than the word "script" suggests.
It is a Turing-complete programming language with sophisticated execution engines, modules, asynchronous computation, networking APIs, graphics APIs, storage APIs, event systems, and access to many capabilities provided by the browser.
The JavaScript engine itself performs the work necessary to transform JavaScript programs into executable computation.
We therefore do not need to build another CPU.
We do not need to implement our own instruction set.
We do not need to emulate a physical machine.
The browser has already provided that layer.
Conceptually, we can treat:
JavaScript
↓
JavaScript Engine
↓
Browser Runtime
as the computational machinery available to the Internet Operating Environment.
The interesting problem is therefore not:
"How can JavaScript become a CPU?"
but:
"What operating-system abstractions can we construct on top of JavaScript's existing computational environment?"
HTML as the Host Environment:
The same applies to HTML.
An HTML document already provides a structured environment in which JavaScript can create state, interfaces, elements, events, graphics, and other resources.
For example, an Internet OS could represent its graphical desktop using Canvas:
+------------------------------------------------+ | Internet OS | +------------------------------------------------+ | | | [Calculator] [Editor] [Terminal] | | | | | +------------------------------------------------+
But there is nothing inherently requiring a graphical interface.
The same underlying system could theoretically expose a terminal-like interface:
Internet OS > load calculator > calculator 42 * 17 714
The important point is that the application module should not necessarily care which user interface is being used.
The graphical environment and the terminal environment could both consume the same module interfaces.
That requires a protocol.
The Missing Layer: A JavaScript Module Protocol:
The central component of the proposal is not the desktop.
It is the protocol.
Suppose somebody publishes:
https://example.com/calculator.js
Normally, another developer would have to know how that particular JavaScript file works.
The Internet Operating Environment would instead define a standard module interface.
A module could declare information such as:
Name Version Type Dependencies Exports Required capabilities Entry point Compatible protocol version
Conceptually:
JSOS.module({
name: "example.calculator",
version: "1.0.0",
type: "application",
dependencies: [
"example.math"
],
exports: [
"Calculator"
],
permissions: [
"ui"
]
});
The exact syntax is not important.
What matters is that the system can distinguish:
arbitrary JavaScript
from:
JavaScript conforming to the Internet OS module protocol
That distinction makes interoperability possible.
The Internet Becomes the Software Distribution Layer:
This is where the concept differs most strongly from conventional browser operating systems.
An application would not necessarily have to be bundled with the operating environment.
It could be located anywhere on the Internet.
For example:
github.com
└── user/project/calculator.js
example.org
└── libraries/math.js
alice.example
└── applications/editor.js
The Internet OS could request these modules through ordinary Internet protocols.
Conceptually:
Internet OS
│
├── request calculator.js
│
├── request math.js
│
└── request ui.js
↓
Internet
↓
independent servers
The location of the software becomes separate from the environment that executes it.
This is analogous to how an operating system can execute programs without requiring every program to have been developed by the operating-system vendor.
The difference is that the Internet OS would not necessarily require a centralized software repository.
The software could remain distributed.
Websites Become Potential Software Providers:
This also changes the conceptual meaning of a website.
A website normally represents a finished document or application.
But technically, a website is already capable of serving:
HTML CSS JavaScript JSON Images Fonts WebAssembly Other resources
The Internet Operating Environment could treat compatible JavaScript resources as software components instead of merely treating them as implementation details of a webpage.
A site could therefore expose:
https://example.com/modules/math.js https://example.com/modules/audio.js https://example.com/modules/editor.js
Another Internet OS could consume them.
The developer does not necessarily have to upload them to a special central repository.
The website itself becomes a software distribution point.
This is why the term Internet OS is more appropriate than simply JavaScript OS.
The important resource being operated upon is not merely JavaScript.
It is the distributed computational environment of the Internet.
From Applications to Modules:
The protocol could also allow software to become composable.
Imagine several independent developers.
Developer A creates:
Math
Developer B creates:
Graphics
Developer C creates:
Audio
Developer D creates:
Text Editor
Developer E creates:
Game Engine
They do not need to be part of the same project.
They only need to agree on interfaces.
The resulting structure could look like:
Internet OS
│
┌────────────┼────────────┐
↓ ↓ ↓
Math Graphics Audio
│ │ │
└────────────┼────────────┘
↓
Applications
The protocol becomes the "wiring" connecting independently developed components.
This is arguably more important than the graphical desktop itself.
The desktop is only one possible client of the underlying system.
The OS Does Not Need to Be Low-Level:
A conventional operating system has to deal with problems such as:
Memory management CPU scheduling Interrupts Device drivers Filesystem drivers Hardware discovery Process isolation Network interfaces
An Internet Operating Environment does not necessarily need to reproduce these mechanisms.
The browser already provides abstractions for many of them.
Instead, the system can operate at a higher level:
Module management Application lifecycle Dependency resolution Inter-module communication Capabilities Permissions Resources Discovery Versioning Interfaces UI abstraction Network resources
This is not a weakness.
It is precisely what abstraction is supposed to accomplish.
We do not need to implement an Ethernet driver merely because an application ultimately communicates through Ethernet.
The browser already did that work.
The Internet OS can operate on the abstraction exposed by the browser.
The Internet as a Computational System:
This leads to a broader question:
What exactly is a computer?
At the physical level, we can describe a computer through transistors, logic gates, registers, memory, buses, multiplexers, and electronic signals.
But computer science continuously builds abstractions above those physical mechanisms.
A virtual machine can behave as a computer.
An emulator can behave as a computer.
A programming language runtime can provide a computational machine.
A distributed system can behave as a computational system.
The Internet itself consists of interconnected computational machines exchanging structured information.
Therefore, there is nothing inherently contradictory about constructing an operating environment whose resources are primarily represented by network-accessible computational objects.
The Internet OS would operate on a different layer of the stack.
Its "hardware" would not be the transistor.
Its "hardware" would be the computational and communication abstractions already exposed by the Web.
Hence why the "Internet OS", because it is not an OS for your machine, but for the data that travels your Ethernet cable or Wi-Fi signal.
A Possible Architecture:
A minimal implementation could look something like this:
┌──────────────────────────────────────┐
│ Browser │
├──────────────────────────────────────┤
│ HTML │
│ │
│ ┌──────────────────────────────┐ │
│ │ Internet OS Runtime │ │
│ ├──────────────────────────────┤ │
│ │ Module Manager │ │
│ │ Dependency Resolver │ │
│ │ Application Manager │ │
│ │ IPC / Message System │ │
│ │ Capability System │ │
│ │ Resource Manager │ │
│ │ UI Abstraction │ │
│ └──────────────────────────────┘ │
│ │ │
│ JavaScript Modules │
└──────────────────┼───────────────────┘
│
▼
INTERNET
A module could then be retrieved from:
GitHub SourceForge Personal website University server CDN Local server Another Internet OS node
provided that it conforms to the protocol.
Decentralization Is a Consequence, Not a Requirement:
There does not necessarily need to be one central "Internet OS Store."
A central registry could exist as a convenience, but it would not have to be the fundamental architecture.
The protocol could allow:
Module identifier
↓
Resolver
↓
One or more possible sources
↓
Module
This means the ecosystem could remain distributed.
A developer could publish software independently.
Another developer could mirror it.
A community could maintain a repository.
A company could maintain its own private modules.
A user could host modules locally.
The protocol would define how software behaves, rather than dictating where software must live.
HTML Does Not Have to Mean "Website":
This is an important conceptual distinction.
An HTML document is normally interpreted as a webpage.
But HTML is ultimately a structured representation that a browser knows how to render and manipulate.
There is no fundamental requirement that the document represent:
a newspaper a blog a corporate website a social network
It can represent:
a desktop a terminal a game a simulation a development environment an application an operating environment
The Internet OS would simply use HTML as its host substrate.
Canvas could provide a graphical display.
DOM elements could provide interface components.
JavaScript could provide computation.
Network APIs could provide communication.
The browser supplies the machinery.
The Internet OS supplies the organization.
The Same Module, Multiple Interfaces:
One particularly interesting consequence is that applications could become independent of their presentation layer.
For example:
Calculator Module
│
┌─────────┴─────────┐
↓ ↓
Canvas Interface TUI Interface
The calculator itself provides computational functionality.
The Canvas environment provides one interface.
A terminal provides another.
A completely different HTML interface could provide another.
This resembles the separation between applications and graphical shells, terminals, libraries, and system APIs found in conventional operating systems.
The difference is that the interfaces themselves can also be distributed JavaScript modules.
This Is Not Runtime.JS:
Projects such as Runtime.JS explore a related but fundamentally different direction.
Runtime.JS treats JavaScript as the software environment of a much lower-level operating system/unikernel.
The conceptual stack is approximately:
Hardware
↓
Runtime.JS
↓
JavaScript engine
↓
JavaScript applications
The Internet Operating Environment instead proposes:
Hardware
↓
Existing OS
↓
Browser
↓
HTML
↓
Internet OS
↓
Internet-distributed modules
Runtime.JS asks:
Can JavaScript operate closer to the hardware?
The Internet OS asks:
Can the Web itself become an operating environment for distributed JavaScript software?
These are related ideas, but they solve different problems.
15. The Fundamental Difference from Other JavaScript Operating Systems
There is an important distinction between the Internet Operating Environment and what is commonly described as a "JavaScript operating system."
Many projects that use JavaScript as the basis of an operating system are essentially constructing a new computational environment.
They define their own system APIs, their own application model, their own system services, and their own expectations about how applications communicate with the system.
The relationship is therefore similar to a conventional operating system:
Operating System
↓
System API
↓
Application written for that API
A Windows application is designed to interact with Windows APIs.
A Linux application is designed to interact with Linux/POSIX interfaces or other interfaces provided by its environment.
Likewise, a JavaScript-based operating system can define its own interfaces and require applications to be written according to those interfaces.
The application is therefore, in some sense, an application for that system.
That is not the fundamental idea of the Internet Operating Environment.
Existing JavaScript as the Starting Point:
The Internet Operating Environment starts from the opposite direction.
It does not begin by asking:
"What kind of applications should developers write for our new operating system?"
It begins by asking:
"What JavaScript applications already exist on the Internet, and how can we operate them as components of a common environment?"
This distinction is fundamental.
The Internet already contains enormous amounts of JavaScript.
There are calculators, mathematical libraries, visualization engines, games, editors, parsers, audio systems, image processors, scientific tools, simulations, utilities, interfaces, and countless other pieces of software.
Most of these programs were not designed to be applications for a hypothetical Internet Operating Environment.
They were designed for the Web.
The objective is therefore not to replace them with specially written "Internet OS applications."
The objective is to make existing JavaScript usable within the environment.
Compatibility Instead of Exclusivity:
A protocol would still be necessary.
However, the protocol does not have to mean:
"Every application must be rewritten specifically for this operating environment."
Instead, the protocol can provide a compatibility layer.
For example:
Existing JavaScript
↓
Compatibility Wrapper
↓
Internet OS Interface
↓
Application
An existing library could potentially be wrapped with a small adapter that translates between its existing API and the Internet OS interfaces.
Therefore:
Existing JavaScript
+
Compatibility Layer
↓
Internet OS
could be sufficient.
A module that follows the protocol natively would obviously be easier to integrate, but the underlying software does not need to have been created specifically for the system.
This is similar to the distinction between creating a new software ecosystem and creating a layer that can interoperate with an existing ecosystem.
The latter is the central objective here.
In short, Windows requires you to compile a binary that fits Windows itself, it is exclusive for Windows, it reads the binary and make calls to an API that then mess with the Hardware. The same for Linux.
OSs that are based on JS, be it on browser or not, also follows this exclusivity, for you to use the system, you need to make something exclusive for the system, you have to re-invent the wheel in a way such systems understand.
My idea is not that, my idea is to understand how our browser interprets HTML / JS and this is already an app, we just need to isolate it in to an environment instead of creating an exclusive environment for it. We use the browser power of interpreting JS that already exists, we get the data and make an operational system for this data that already exist; instead of the "JS based OS" idea of "designing an exclusive code for it".
OS is made to translate the data that runs in the metal and make operable by an user. OS does not need to be seem merely as an exclusive environment. An "Internet OS" makes the same thing, it translate the data that runs in your Ethernet cable and make it operable by an user, it does not need exclusive apps, APIs and etc, this already exists in modern browsers.
The Internet Is Already Full of Applications:
Consider an ordinary JavaScript application on a website.
The user may see:
Browser ↓ HTML ↓ CSS ↓ JavaScript ↓ Application
But the application itself might require only a small portion of everything that was downloaded.
The page may contain:
HTML CSS Images Fonts Advertisements Tracking code Analytics UI elements JavaScript Other resources
while the actual computational component the user wants may be relatively small.
For a simple calculator, mathematical utility, parser, converter, visualization, or similar program, loading an entire website can be a substantial amount of infrastructure surrounding a comparatively small computational core.
The Internet Operating Environment asks:
Why should the software and the webpage necessarily be the same unit?
They do not have to be.
A website can remain a website.
But its JavaScript application can also be treated as a reusable software component.
Separating the Application from the Website:
The proposed model therefore separates:
Website
from:
Software hosted by the website
A conventional interaction might be:
User ↓ Website ↓ HTML ↓ CSS ↓ JavaScript ↓ Application
An Internet Operating Environment could instead do:
User ↓ Internet OS ↓ Request application module ↓ example.com/application.js ↓ Execute module ↓ Internet OS interface
The website becomes the host of the software, rather than necessarily being the software's user interface.
This allows the same JavaScript component to potentially be used by multiple environments.
A Website Can Become a Software Repository Without Becoming One:
This does not require websites to stop being websites.
A personal website could still have:
https://example.com/
and additionally expose:
https://example.com/modules/calculator.js https://example.com/modules/math.js https://example.com/modules/graphics.js
The Internet Operating Environment could request only the relevant module.
The website remains an ordinary website.
The module simply becomes independently addressable software.
This is important because it means the system can build upon the infrastructure that already exists rather than requiring a completely new Internet.
The Potential Efficiency Advantage:
There is also a practical reason for this architecture.
If a user wants a small computational tool, the amount of information required to execute that tool can be much smaller than the complete website through which it is normally accessed.
For example:
Entire website ├── HTML ├── CSS ├── images ├── fonts ├── UI ├── analytics ├── unrelated JavaScript └── application
could become:
Internet OS ├── application.js └── dependencies
The exact savings depend on the application, but the architectural principle is straightforward:
transfer the computational component rather than necessarily transferring the entire presentation layer surrounding it.
A small JavaScript program could potentially be transferred in kilobytes, cached locally, and reused by multiple applications.
The browser would therefore stop being required to repeatedly reconstruct an entire website simply to access a small piece of functionality.
The Application Does Not Belong to the Website:
This also changes the relationship between applications and websites.
Today, the computational logic of a website is often treated as an implementation detail of that website.
The Internet Operating Environment treats it as a potentially independent object.
For example:
example.com
└── calculator.js
could be understood as:
Provider: example.com Application: calculator Protocol: Internet OS
The application can therefore have an identity independent of the webpage that happens to distribute it.
This makes the Internet resemble a distributed software filesystem.
A URL does not merely identify a document.
It can identify a software component.
The Protocol Is the Wiring, Not the Main Idea:
It is important not to confuse the protocol with the fundamental idea.
The protocol is necessary because independent software needs a common way to communicate.
But the protocol itself is not the innovation being proposed.
A compatibility wrapper could theoretically transform an existing JavaScript application into a protocol-compatible module:
Existing JS
↓
Adapter
↓
JS OS Protocol
Therefore, the existence of software that does not natively implement the protocol does not invalidate the concept.
The protocol is simply the wiring. And this also shows that my view is not the ordinary "JS based OS".
The deeper idea is:
There is already an enormous distributed collection of executable JavaScript on the Internet. Instead of treating every website as an isolated application, create an environment capable of consuming that existing software as reusable computational resources.
From Webpages to Computational Resources:
This produces a different interpretation of the Web.
Instead of:
Internet
↓
Websites
↓
Pages
we can think:
Internet
↓
Network-accessible resources
↓
Documents
↓
Software modules
↓
Applications
The same server can provide both.
A document can remain a document.
A JavaScript file can become a module.
A JSON resource can become structured data.
An image can become an application resource.
A WebAssembly module can potentially become another computational component.
The Internet Operating Environment simply establishes a way of organizing these resources into a computational system.
Operating the Internet Rather Than Replacing It:
This is ultimately why the name Internet Operating Environment is intentional.
A conventional operating system operates the physical computer.
It manages:
CPU Memory Storage Devices Processes Networks
The Internet Operating Environment operates at another level.
It organizes and operates:
Internet resources JavaScript modules Applications Dependencies Interfaces Network endpoints Data Services
It does not need to replace the operating system underneath it.
It does not need to invent a new physical machine.
It does not need to create an entirely new software ecosystem.
Its purpose is to organize an ecosystem that already exists.
That is the fundamental distinction.
A JavaScript operating system generally asks:
"How can we build an operating system using JavaScript?"
The Internet Operating Environment asks:
"How can we turn the JavaScript software already distributed across the Internet into an interoperable operating environment?"
The first creates a new system.
The second creates a layer over an existing system.
That is why the objective is not merely a JavaScript OS.
It is an Internet Operating Environment.
This Is Also More Than a Web Desktop:
A web desktop can provide:
Windows Icons Menus Applications File managers Terminals
That is useful, but it does not by itself define the Internet Operating Environment.
The desktop is merely one possible interface.
The deeper component is the protocol underneath it.
Without the protocol, we have:
HTML application that looks like an OS
With the protocol, we can have:
HTML host
↓
Internet OS protocol
↓
Distributed software ecosystem
That distinction is fundamental.
The objective is not to make a webpage look like Linux or Windows.
The objective is to create a new software layer with its own rules for discovering and composing Internet-distributed computation.
The First Version Could Be Extremely Small:
The project does not need to begin as an enormous operating system.
A minimal prototype could consist of only:
1. Module specification 2. Module loader 3. Module metadata 4. Dependency resolver 5. Standard interfaces 6. Application lifecycle 7. Basic IPC 8. One HTML interface
For example:
index.html
↓
jsos.js
↓
load("https://example.com/calculator.js")
↓
validate module
↓
resolve dependencies
↓
instantiate module
↓
provide interface
At that point, the fundamental experiment already exists.
Everything else can be built on top.
The Real Project Is the Standard:
The most valuable contribution might therefore not be the desktop itself.
It might be the specification.
If a protocol is sufficiently simple and useful, independent implementations can appear.
One person could create a Canvas implementation.
Another could create a terminal implementation.
Another could create a native wrapper.
Another could create a browser extension.
Another could create a server-side runtime.
Another could create a completely different interface.
They could all consume the same modules because they understand the same protocol.
That is when the project stops being merely an application and starts becoming an ecosystem.
CONTINUE:
https://telegra.ph/The-Internet-OS-A-Community-Driven-Operating-System-Built-from-JavaScript-2-09-19