我认为这很大程度上取决于您在应用程序之间的界限（即您对应用程序的定义）以及要考虑的用例。
虽然您可以将Web浏览器实现为wget/的组合curl，但HTML / XML解析器将为每个文档节点调用简单的应用程序，而独立的JavaScript引擎将与所有这些元素进行交互，而“简单”的显示器将“仅”将以上内容的输出放在屏幕上（并将输入返回到某些核心协调过程），它甚至比今天的其他浏览器（可能是任何其他浏览器）更混乱。
至于将数据管道传输到外部进程-这实际上是如何开始的。如果您担心平均Web应用程序代码的大小，是的，它们通常很大（并且通常是因为它们位于以解释性编程语言而不是“简单”应用程序编写的平台之上的一层），但请进行比较到他们的等价物。给客户发送电子邮件，办公套件...您为它命名。所有这些都非常复杂，并且具有太多功能，无法实现为通过管道进行通信的几个过程。对于使用这些应用程序执行的任务，通常也很复杂。对于复杂的问题，没有好的简单解决方案。
也许现在是时候超越UNIX座右铭“做一些但擅长的应用程序”背后的动机了。将“应用程序”替换为“通用模块化单元”，您将获得一种基本的良好编程习惯：模块化处理，以便可以重复使用和单独开发零件。恕我直言，这才是真正重要的事情（而编程语言的选择与之几乎没有关系）。
ps （在评论之后）：从严格意义上来说，您基本上是正确的-Web应用程序不遵循UNIX的哲学（被分成几个较小的独立程序）。然而，关于应用程序的整个概念似乎比较晦涩- sed在某些情况下，它通常可以充当过滤器，但可以将其视为一个应用程序。
因此，这取决于您实际使用它的方式。如果您使用进程的通常定义-某个东西作为单个进程运行（从某种意义上说，内核可以看到它），那么例如，在httpd中由模块解释的PHP Web应用程序正好相反。加载的共享库是否仍属于单个进程的范围（因为它们使用相同的地址空间），还是已经分开了（从程序员的角度来看是不变的，可以完全重用并通过定义良好的API进行通信）？
另一方面，当今的大多数Web应用程序都分为客户端和服务器部分，它们作为单独的进程运行-通常在不同的系统（甚至是物理上分开的硬件）上。这两个部分通过定义明确的（通常是文本的）接口（基于HTTP的XML / HTML / JSON）相互通信。通常（至少在浏览器中）有多个线程正在处理应用程序的客户端（JavaScript / DOM，输入/输出...），有时甚至是一个单独的运行插件的进程（Java，Flash，... ）。这听起来跟原来的UNIX哲学，尤其是在Linux上，其中线程是进程的（几乎）任何帐户。
除此之外，服务器部分几乎总是分成几个不同的部分-典型的示例是对结构化（或非结构化）数据执行请求的操作的独立数据库引擎。将数据库集成到Web服务器中并没有多大意义。但是，将数据库拆分为几个仅专门用于解析请求，从数据存储中获取数据，过滤数据的过程也没有多大意义。必须在创建万能的庞然大物与一群几乎无能的工人，他们大部分时间都在互相交谈。
至于文本界面：请注意，对于40年前处理的数据而言，今天的情况并不一定如此-二进制格式在空间和反序列化所需的功能上都更便宜，并且数据量非常大。
另一个重要的问题是，UNIX哲学的目标实际上是什么？我认为数字模拟，银行系统或公众可访问的照相馆/社交网络从未如此。但是，运行这些服务的系统的维护肯定已经并且将来甚至还会进行。