Acho que depende bastante de onde você desenha um limite entre os aplicativos (ou seja, qual é a sua definição de um aplicativo) e quais casos de uso você leva em consideração.
Embora você possa implementar um navegador da Web como uma fusão de wget / curl , um analisador HTML / XML que chamaria aplicativo simples para cada nó de documento, um mecanismo JavaScript independente que interaja com tudo isso e um displayer "simples" que "apenas" colocaria a saída dos itens acima na tela (e devolveria as entradas de volta a algum processo central de coordenação), seria ainda mais confuso do que (provavelmente qualquer) outro navegador de hoje.
Como para piping os dados para um processo externo - é assim que 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 uma aplicação "simples"), mas comparada aos seus equivalentes. Clientes de e-mail, suítes de escritório ... você escolhe. Todos estes são bastante complexos e têm muita funcionalidade para serem implementados como um par de processos que se comunicam através de tubos. As tarefas para as quais você está usando esses aplicativos também são complexas. Não há boas soluções simples para problemas complexos.
Talvez seja 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ê chegará a uma das boas práticas de programação básicas: fazer as coisas de modo modular, para que as partes 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 (seguindo o comentário) : No sentido mais estrito você está principalmente certo - aplicações web não estão seguindo a filosofia UNIX (de serem divididas em vários programas independentes menores ). No entanto, todo o conceito do que uma aplicação é parece bastante obscuro - sed provavelmente poderia ser considerado como uma aplicação em algumas situações , enquanto normalmente age apenas como um filtro.
Por isso, depende de como você quer literalmente levá-lo. Se você usa a definição usual de um processo - algo rodando como um único processo (no sentido do kernel o vê), então, por exemplo, uma aplicação web PHP interpretada no httpd por um módulo é exatamente o oposto. As bibliotecas compartilhadas carregadas ainda caem no escopo de um único processo (porque elas usam o mesmo espaço de endereço) ou são algo mais separado (imutável do ponto de vista do programador, completamente reutilizável e se comunicando através de uma API bem definida)?
Por outro lado, a maioria das aplicações web atuais é dividida em partes de cliente e servidor, que estão sendo executadas como processos separados - geralmente em sistemas diferentes (e até mesmo em hardware separado fisicamente). Essas duas partes se comunicam entre si por meio de uma interface bem definida (geralmente textual) (XML / HTML / JSON sobre HTTP). Muitas vezes (pelo menos no navegador) existem vários threads que estão processando o lado do cliente do aplicativo (JavaScript / DOM, entrada / saída ...), às vezes até um processo separado executando um plugin ( Java, Flash, ...). Isso soa exatamente como a filosofia original do UNIX, especialmente no Linux, onde threads são processos por (quase) qualquer conta.
Além disso, as partes do servidor são quase 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 da web. No entanto, também não faz muito sentido dividir um banco de dados em vários processos que se especializariam em apenas analisar solicitações, buscar dados do armazenamento de dados, filtrar os dados ... É preciso encontrar um equilíbrio entre criar um monstro onipotente e um enxame de trabalhadores quase nilpotentes que passam a maior parte do tempo conversando entre si.
Quanto à interface textual : note que o que era verdade para dados processados há 40 anos não é necessariamente verdade hoje - os formatos binários são mais baratos tanto no espaço quanto na energia exigidos para de / serialização, e o quantidade de dados é imensamente maior.
Outra questão importante também é: qual tem sido o alvo da filosofia do UNIX? Eu não acho que simulações numéricas, sistemas bancários ou galerias de fotos publicamente acessíveis / redes sociais já existiram. Manutenção de sistemas executando esses serviços, no entanto, definitivamente tem sido e provavelmente será no futuro.