Eu acho que depende muito de onde você define um limite entre aplicativos (ou seja, qual é a sua definição de aplicativo) e quais casos de uso você leva em consideração.
Embora você possa implementar um navegador da Web como uma amálgama de wget/ curl, um analisador HTML / XML que chamaria um aplicativo simples para cada nó do documento, um mecanismo JavaScript independente que interagisse com tudo isso e um exibidor "simples" que "apenas" colocar a saída do exposto acima na tela (e retornar as entradas para algum processo de coordenação principal), seria ainda mais confuso do que (provavelmente qualquer) outro navegador de hoje.
Quanto a canalizar os dados para um processo externo - foi assim que ele realmente começou . Se você está preocupado com o tamanho de um código médio de aplicativo da Web, sim, eles geralmente são grandes (e geralmente porque são uma camada acima de uma plataforma escrita em uma linguagem de programação interpretada em vez de um aplicativo "simples"), mas compare-o aos seus equivalentes. Clientes de e-mail, suítes de escritório ... o nome dele. Tudo isso é bastante complexo e possui muita funcionalidade para ser implementada em alguns processos de comunicação através de pipes. As tarefas para as quais você está usando esses aplicativos também costumam ser complexas. Não existem boas soluções simples para problemas complexos.
Talvez esteja na hora de olhar um pouco além da motivação por trás do lema do UNIX "aplicativos que fazem um pouco, mas são bons nisso". Substitua "aplicativos" por "unidades modulares gerais" e você chega a uma das boas práticas básicas de programação: faça as coisas de forma modular, para que as peças possam ser reutilizadas e desenvolvidas separadamente . Isso é o que realmente importa, IMHO (e a escolha da linguagem de programação tem muito pouco a ver com isso).
ps (após o comentário) : No sentido mais estrito, você está certo - os aplicativos Web não seguem a filosofia UNIX (de serem divididos em vários programas independentes menores). No entanto, todo o conceito do que é um aplicativo parece bastante obscuro - sedprovavelmente poderia ser considerado um aplicativo em algumas situações , enquanto geralmente atua apenas como um filtro.
Por isso, depende de quão literalmente você deseja tomá-lo. Se você usar a definição usual de um processo - algo em execução como um processo único (no sentido em que o kernel o vê), então, por exemplo, um aplicativo Web PHP interpretado no httpd por um módulo é exatamente o oposto. As bibliotecas compartilhadas carregadas ainda se enquadram no escopo de um único processo (porque usam o mesmo espaço de endereço) ou já são algo mais separado (imutável do ponto do programador, completamente reutilizável e se comunicando por meio de uma API bem definida)?
Por outro lado, a maioria dos aplicativos da Web hoje são divididos em partes de cliente e servidor, que estão sendo executadas como processos separados - geralmente em sistemas diferentes (e até mesmo em hardware fisicamente separado). Essas duas partes se comunicam por meio de uma interface bem definida (geralmente em texto) (XML / HTML / JSON sobre HTTP). Frequentemente (pelo menos no navegador), existem vários threads que processam o lado do cliente do aplicativo (JavaScript / DOM, entrada / saída ...), às vezes até um processo separado executando um plug-in (Java, Flash, ... ) Isso soa exatamente como a filosofia original do UNIX, especialmente no Linux, onde os threads são processados por (quase) qualquer conta.
Além disso, as partes do servidor são praticamente sempre divididas em várias partes distintas - o mecanismo de banco de dados separado que executa operações solicitadas em dados estruturados (ou não estruturados) é um exemplo canônico. Simplesmente não faz muito sentido integrar um banco de dados em um servidor web. No entanto, também não faz muito sentido dividir um banco de dados em vários processos que se especializam em, digamos, analisar apenas solicitações, buscar dados do armazenamento de dados, filtrar os dados ... É preciso encontrar um equilíbrio entre criar um gigante onipotente e um enxame de trabalhadores quase sem força que passam a maior parte do tempo conversando entre si.
Quanto à interface textual : observe que o que era verdade para os dados processados 40 anos atrás não é necessariamente verdade hoje - os formatos binários são mais baratos tanto no espaço quanto na energia necessária para a des serialização, e a quantidade de dados é imensamente maior.
Outra questão importante também é: qual foi realmente o alvo da filosofia do UNIX? Acho que nunca foram simulações numéricas, sistemas bancários ou galerias de fotos / redes sociais acessíveis ao público. A manutenção dos sistemas executando esses serviços, no entanto, definitivamente tem sido e provavelmente ocorrerá no futuro.