Server-Side Models
When code runs on the server or the client, it runs within a specific execution model. These models have evolved over decades, each with distinct trade-offs in portability, performance, and complexity. Understanding them helps you see why Node.js exists, why PHP works the way it does, and why the browser is effectively an operating system for web applications.
| Model | Examples | Portability | Performance | Complexity |
|---|---|---|---|---|
| Fork/Exec (CGI) | CGI scripts, early PHP*, Python (WSGI)*, Ruby (Rack)* | Variable | Variable (Low–Medium) | Variable (Medium–High) |
| Server-Side Scripting | PHP, ColdFusion, Classic ASP, JSP*, Python*, Ruby* | High | Medium | Low |
| Embedded Container | Java Servlets | Medium | Medium–High | Medium–High |
| Embedded Native | Apache Modules, ISAPI | Low | High | High |
| Code-as-Server | Node.js, Python, Perl, Deno, Bun | High | Medium–High | Medium–High |
* Depends on language and architecture
- Fork/Exec (CGI): The server spawns a new process for each request. Simple but expensive — every request pays the process creation cost. The original model.
- Server-Side Scripting: Code is embedded in or invoked by the web server process. PHP's model — the server loads the interpreter once and runs scripts within it. Fast enough, easy to deploy.
- Embedded Container: A runtime (like Java's servlet container) lives inside the server. More complex setup, but the application stays loaded in memory across requests.
- Embedded Native: Code compiled directly into the web server as a module (Apache modules, ISAPI filters). Maximum performance, minimum portability. C/C++ territory.
- Code-as-Server: The application is the server. Node.js is the canonical example — your JavaScript code creates an HTTP server directly. High flexibility, but you own the entire server lifecycle.
Client-Side Models
| Model | Examples | Portability | Performance | Complexity |
|---|---|---|---|---|
| Helpers | External apps for MIME types (Acrobat, Winzip) | Variable | Variable | Variable |
| Client-Side Scripting | JavaScript, VBScript (dead), WASM | High | Medium–High | Low–Medium |
| Applets | Java Applets (dead) | Medium | Medium–High | Medium–High |
| Plug-ins | ActiveX, Netscape Plugins, NaCl (all dead) | Low | High | High |
| Native Wrapping Web View | Electron apps | High | Variable | Medium–High |
| Native Code Calling Web | Swift/Java using HTTP + web tech | Low | High | High |
The history here is a graveyard: Java Applets, ActiveX, Flash, NaCl — all attempted to extend the browser's capability and all died. Client-side scripting (JavaScript) won, and WASM is extending its reach into high-performance territory.
The "native wrapping web view" pattern (Electron, Capacitor, etc.) is today's compromise: write web tech, wrap it in a native shell. It's the app shell pattern. The web view / native app spectrum ranges from fully native apps to thin web wrappers — the real distribution issue between web and native is more economic than technical.