Creo que depende bastante de dónde trazas un límite entre las aplicaciones (es decir, cuál es tu definición de aplicación) y qué casos de uso tienes en cuenta.
Si bien podría implementar un navegador web como una fusión de wget/ curl, un analizador HTML / XML que llamaría una aplicación simple para cada nodo del documento, un motor de JavaScript independiente que interactuaría con todo esto y un visualizador "simple" que "simplemente" colocar el resultado de lo anterior en la pantalla (y devolver las entradas a algún proceso de coordinación central) sería aún más complicado que (probablemente cualquier) otro navegador de hoy.
En cuanto a canalizar los datos a un proceso externo, así es como realmente comenzó . Si le preocupa el tamaño de un código de aplicación web promedio, sí, a menudo son grandes (y a menudo porque son una capa situada sobre una plataforma escrita en un lenguaje de programación interpretado en lugar de una aplicación "simple"), pero compárelo a sus equivalentes. Clientes de correo electrónico, suites de oficina ... lo que sea. Todos estos son bastante complejos y tienen demasiada funcionalidad para implementarse como un par de procesos que se comunican a través de tuberías. Para las tareas para las que está utilizando estas aplicaciones, a menudo también son complejas. No hay buenas soluciones simples para problemas complejos.
Tal vez sea hora de mirar un poco más allá de la motivación detrás del lema de UNIX "aplicaciones que funcionan un poco pero son buenas en eso". Reemplace las "aplicaciones" con "unidades modulares generales" y llegará a una de las buenas prácticas básicas de programación: haga las cosas de forma modular, de modo que las piezas puedan reutilizarse y desarrollarse por separado . Eso es lo que realmente importa, en mi humilde opinión (y la elección del lenguaje de programación tiene muy poco que ver con eso).
ps (siguiendo el comentario) : en el sentido más estricto, en su mayoría tiene razón: las aplicaciones web no siguen la filosofía de UNIX (de dividirse en varios programas independientes más pequeños). Sin embargo, todo el concepto de lo que es una aplicación parece bastante turbio: sedprobablemente podría considerarse una aplicación en algunas situaciones , mientras que generalmente actúa solo como un filtro.
Por lo tanto, depende de cuán literalmente quieras tomarlo. Si utiliza la definición habitual de un proceso: algo que se ejecuta como un proceso único (en el sentido en que lo ve el núcleo), entonces, por ejemplo, una aplicación web PHP interpretada en httpd por un módulo es exactamente lo contrario. ¿Las bibliotecas compartidas cargadas todavía caen dentro del alcance de un solo proceso (porque usan el mismo espacio de direcciones) o ya están algo más separadas (inmutables desde el punto del programador, completamente reutilizables y se comunican a través de una API bien definida)?
Por otro lado, la mayoría de las aplicaciones web hoy en día se dividen en partes de cliente y servidor, que se ejecutan como procesos separados, generalmente en diferentes sistemas (e incluso hardware físicamente separado). Estas dos partes se comunican entre sí a través de una interfaz bien definida (generalmente textual) (XML / HTML / JSON sobre HTTP). A menudo (al menos en el navegador) hay varios subprocesos que procesan el lado del cliente de la aplicación (JavaScript / DOM, entrada / salida ...), a veces incluso un proceso separado que ejecuta un complemento (Java, Flash, ... ) Eso suena exactamente como la filosofía original de UNIX, especialmente en Linux, donde los hilos son procesos de (casi) cualquier cuenta.
Además de eso, las partes del servidor se dividen casi siempre en varias partes distintas: un motor de base de datos separado que realiza operaciones solicitadas en datos estructurados (o no estructurados) es un ejemplo canónico. Simplemente no tiene mucho sentido integrar una base de datos en un servidor web. Sin embargo, tampoco tiene mucho sentido dividir una base de datos en varios procesos que se especializarían en, por ejemplo, analizar solo solicitudes, recuperar datos del almacenamiento de datos, filtrar los datos ... Uno tiene que encontrar el equilibrio entre crear un gigante omnipotente y un Enjambre de trabajadores casi nulos que pasan la mayor parte del tiempo hablando entre ellos.
En cuanto a la interfaz de texto : tenga en cuenta que lo que era cierto para los datos procesados hace 40 años no es necesariamente cierto hoy en día: los formatos binarios son más baratos tanto en espacio como en potencia para la deserialización y la cantidad de datos es inmensamente mayor.
Otra pregunta importante también es, ¿cuál ha sido realmente el objetivo de la filosofía UNIX? No creo que hayan existido simulaciones numéricas, sistemas bancarios o galerías de fotos / redes sociales de acceso público. Sin embargo, el mantenimiento de los sistemas que ejecutan estos servicios definitivamente ha sido y probablemente lo será en el futuro.