Penso che dipenda molto da dove si traccia un confine tra le applicazioni (cioè qual è la tua definizione di applicazione) e quali casi d'uso prendi in considerazione.
Mentre potresti implementare un browser web come una fusione di wget/ curl, un parser HTML / XML che chiamerebbe semplice applicazione per ciascun nodo del documento, un motore JavaScript autonomo che interagirebbe con tutto questo e un "semplice" visualizzatore che "solo" posizionare l'output di quanto sopra sullo schermo (e restituire gli input a qualche processo di coordinamento di base) sarebbe ancora più disordinato di (probabilmente qualsiasi) altro browser di oggi.
Per quanto riguarda il piping dei dati a un processo esterno, ecco come sono stati effettivamente avviati . Se sei preoccupato per le dimensioni di un codice medio di applicazione web, sì, sono spesso grandi (e spesso perché sono uno strato sopra una piattaforma scritta in un linguaggio di programmazione interpretato piuttosto che un'applicazione "semplice"), ma confrontalo ai loro equivalenti. Clienti e-mail, suite per ufficio ... lo chiami. Tutti questi sono abbastanza complessi e hanno troppe funzionalità per essere implementati come un paio di processi che comunicano attraverso i tubi. Le attività per le quali stai utilizzando queste applicazioni sono spesso anche complesse. Non ci sono buone soluzioni semplici a problemi complessi.
Forse è tempo di guardare un po 'oltre la motivazione dietro il motto UNIX "applicazioni che fanno un po' ma sono brave a farlo". Sostituisci "applicazioni" con "unità modulari generali" e arrivi a una delle buone pratiche di programmazione di base: fai le cose in modo modulare, in modo che le parti possano essere riutilizzate e sviluppate separatamente . Questo è ciò che conta davvero, IMHO (e la scelta del linguaggio di programmazione ha ben poco a che fare con esso).
ps (seguendo il commento) : Nel senso più stretto hai per lo più ragione - le applicazioni web non seguono la filosofia UNIX (di essere divise in diversi programmi autonomi più piccoli). Tuttavia l'intero concetto di cosa sia un'applicazione sembra piuttosto oscuro - sedpotrebbe probabilmente essere considerato un'applicazione in alcune situazioni , mentre di solito funge solo da filtro.
Quindi dipende da quanto letteralmente vuoi prenderlo. Se usi la solita definizione di un processo - qualcosa in esecuzione come un singolo processo (nel senso in cui lo vede il kernel), ad esempio un'applicazione web PHP interpretata in httpd da un modulo è esattamente l'opposto. Le librerie condivise caricate rientrano ancora nell'ambito di un singolo processo (perché utilizzano lo stesso spazio degli indirizzi) o sono già qualcosa di più separato (immutabile dal punto di vista del programmatore, completamente riutilizzabile e in comunicazione attraverso un'API ben definita)?
D'altra parte, la maggior parte delle applicazioni web oggi sono suddivise in parti client e server, che sono in esecuzione come processi separati - di solito su sistemi diversi (e persino hardware fisicamente separato). Queste due parti comunicano tra loro attraverso un'interfaccia ben definita (di solito testuale) (XML / HTML / JSON su HTTP). Spesso (almeno nel browser) ci sono diversi thread che stanno elaborando il lato client dell'applicazione (JavaScript / DOM, input / output ...), a volte anche un processo separato che esegue un plug-in (Java, Flash, ... ). Sembra esattamente come la filosofia UNIX originale, specialmente su Linux, dove i thread sono processi di (quasi) qualsiasi account.
Inoltre, le parti del server sono praticamente sempre divise in più parti distinte: un motore di database separato che esegue le operazioni richieste su dati strutturati (o non strutturati) è un esempio canonico. Non ha molto senso integrare un database in un web server. Tuttavia, non ha molto senso dividere un database in diversi processi che si specializzerebbero nel dire solo analizzare le richieste, recuperare i dati dalla memoria dei dati, filtrare i dati .... Bisogna trovare un equilibrio tra la creazione di un colosso onnipotente e un brulicante di lavoratori quasi nilpotenti che trascorrono la maggior parte del loro tempo a parlare tra loro.
Per quanto riguarda l' interfaccia testuale : nota che ciò che era vero per i dati elaborati 40 anni fa non è necessariamente vero oggi - i formati binari sono più economici sia nello spazio che nella potenza richiesta per la de / serializzazione e la quantità di dati è immensamente più grande.
Un'altra domanda importante è anche: qual è stato l'obiettivo della filosofia UNIX? Non credo che simulazioni numeriche, sistemi bancari o gallerie fotografiche / social network accessibili al pubblico siano mai stati. La manutenzione dei sistemi che eseguono questi servizi, tuttavia, è stata sicuramente e probabilmente lo sarà anche in futuro.