Je pense que cela dépend beaucoup de l'endroit où vous tracez une frontière entre les applications (c'est-à-dire quelle est votre définition d'une application) et des cas d'utilisation que vous prenez en considération.
Bien que vous puissiez implémenter un navigateur Web en tant que fusion de wget/ curl, un analyseur HTML / XML qui appellerait une application simple pour chaque nœud de document, un moteur JavaScript autonome qui interagirait avec tout cela et un afficheur "simple" qui "juste" placez la sortie de ce qui précède à l'écran (et renvoyez les entrées à un processus de coordination de base), ce serait encore plus compliqué que (probablement n'importe quel) autre navigateur d'aujourd'hui.
Quant à la transmission des données à un processus externe - c'est ainsi que cela a réellement commencé . Si vous êtes préoccupé par la taille d'un code d'application Web moyen, oui, ils sont souvent volumineux (et souvent parce qu'ils sont une couche située au-dessus d'une plate-forme écrite dans un langage de programmation interprété plutôt qu'une application "simple"), mais comparez-la à leurs équivalents. Clients de messagerie, suites bureautiques ... vous l'appelez. Tous ces éléments sont assez complexes et ont trop de fonctionnalités pour être implémentés sous la forme de deux processus communiquant via des canaux. Pour les tâches pour lesquelles vous utilisez ces applications, elles sont souvent aussi complexes. Il n'y a pas de bonnes solutions simples à des problèmes complexes.
Il est peut-être temps de regarder un peu au-delà de la motivation derrière la devise UNIX "les applications qui font un peu mais qui sont bonnes dans ce domaine". Remplacez «applications» par «unités modulaires générales» et vous arrivez à l'une des bonnes pratiques de programmation de base: faire les choses de manière modulaire, afin que les pièces puissent être réutilisées et développées séparément . C'est ce qui compte vraiment, à mon humble avis (et le choix du langage de programmation a très peu à voir avec cela).
ps (après le commentaire) : Au sens strict, vous avez généralement raison - les applications Web ne suivent pas la philosophie UNIX (d'être divisées en plusieurs programmes autonomes plus petits). Pourtant, tout le concept de ce qu'est une application semble plutôt trouble - sedpourrait probablement être considéré comme une application dans certaines situations , alors qu'il agit généralement comme un filtre.
Par conséquent, cela dépend de la façon dont vous voulez le prendre. Si vous utilisez la définition habituelle d'un processus - quelque chose qui fonctionne comme un seul processus (au sens où le noyau le voit), alors par exemple une application Web PHP interprétée en httpd par un module est exactement le contraire. Les bibliothèques partagées chargées tombent-elles toujours dans le cadre d'un processus unique (car elles utilisent le même espace d'adressage) ou sont-elles déjà quelque chose de plus séparé (immuable du point de vue du programmeur, complètement réutilisable et communiquant via une API bien définie)?
D'un autre côté, la plupart des applications Web sont aujourd'hui divisées en parties client et serveur, qui s'exécutent en tant que processus distincts - généralement sur des systèmes différents (et même sur du matériel physiquement séparé). Ces deux parties communiquent entre elles via une interface bien définie (généralement textuelle) (XML / HTML / JSON sur HTTP). Souvent (au moins dans le navigateur) il existe plusieurs threads qui traitent le côté client de l'application (JavaScript / DOM, entrée / sortie ...), parfois même un processus distinct exécutant un plugin (Java, Flash, ... ). Cela ressemble exactement à la philosophie UNIX originale, en particulier sous Linux, où les threads sont des processus par (presque) n'importe quel compte.
En plus de cela, les parties du serveur sont à peu près toujours divisées en plusieurs parties distinctes - un moteur de base de données distinct effectuant les opérations demandées sur des données structurées (ou non structurées) est un exemple canonique. Il n'est tout simplement pas très logique d'intégrer une base de données dans un serveur Web. Pourtant, cela n'a pas beaucoup de sens de diviser une base de données en plusieurs processus qui se spécialiseraient par exemple en analysant uniquement les demandes, en récupérant les données du stockage de données, en filtrant les données ... Il faut trouver un équilibre entre la création d'un géant omnipotent et un essaim de travailleurs presque nilpotents qui passent la plupart de leur temps à se parler.
En ce qui concerne l' interface textuelle : notez que ce qui était vrai pour les données traitées il y a 40 ans n'est pas nécessairement vrai aujourd'hui - les formats binaires sont moins chers à la fois en termes d'espace et de puissance requis pour la dé / sérialisation, et la quantité de données est immensément plus grande.
Une autre question importante est également de savoir quelle a été la cible de la philosophie UNIX? Je ne pense pas que des simulations numériques, des systèmes bancaires ou des galeries de photos / réseaux sociaux accessibles au public aient jamais existé. Cependant, la maintenance des systèmes exécutant ces services a été et sera probablement dans le futur.