Tôi nghĩ nó phụ thuộc khá nhiều vào việc bạn vẽ ranh giới giữa các ứng dụng (nghĩa là định nghĩa của bạn về ứng dụng là gì) và trường hợp sử dụng nào bạn xem xét.
Mặc dù bạn có thể triển khai trình duyệt web dưới dạng hợp nhất của wget/ curl, trình phân tích cú pháp HTML / XML sẽ gọi ứng dụng đơn giản cho mỗi nút tài liệu, một công cụ JavaScript độc lập sẽ tương tác với tất cả điều này và trình hiển thị "đơn giản" sẽ "chỉ" đặt đầu ra của phần trên lên màn hình (và đưa đầu vào trở lại một số quy trình phối hợp cốt lõi), nó thậm chí còn lộn xộn hơn (có thể là bất kỳ) trình duyệt ngày nay khác.
Đối với đường ống dữ liệu đến một quy trình bên ngoài - đó là cách nó thực sự bắt đầu . Nếu bạn lo ngại về kích thước của mã ứng dụng web trung bình, vâng, chúng thường lớn (và thường vì chúng là một lớp nằm trên một nền tảng được viết bằng ngôn ngữ lập trình được giải thích thay vì ứng dụng "đơn giản"), nhưng hãy so sánh nó tương đương của họ. Email khách hàng, bộ văn phòng ... bạn đặt tên cho nó. Tất cả những thứ này khá phức tạp và có quá nhiều chức năng được triển khai như một vài quy trình giao tiếp qua các đường ống. Đối với các tác vụ bạn đang sử dụng các ứng dụng này thường rất phức tạp. Không có giải pháp đơn giản tốt cho các vấn đề phức tạp.
Có lẽ đã đến lúc phải nhìn xa hơn một chút động lực đằng sau phương châm UNIX "các ứng dụng làm được một chút nhưng rất tốt". Thay thế "ứng dụng" bằng "đơn vị mô-đun chung" và bạn đến một trong những thực tiễn lập trình tốt cơ bản: thực hiện mọi thứ theo mô-đun, để các bộ phận có thể được tái sử dụng và phát triển riêng . Đó là điều thực sự quan trọng, IMHO (và sự lựa chọn ngôn ngữ lập trình có rất ít liên quan đến nó).
ps (theo nhận xét) : Theo nghĩa chặt chẽ nhất, bạn hầu như đúng - các ứng dụng web không tuân theo triết lý UNIX (được chia thành nhiều chương trình độc lập nhỏ hơn). Tuy nhiên, toàn bộ khái niệm về những gì một ứng dụng có vẻ khá u ám - sedcó thể được coi là một ứng dụng trong một số tình huống , trong khi nó thường hoạt động như một bộ lọc.
Do đó, nó phụ thuộc vào cách bạn muốn dùng nó theo nghĩa đen. Nếu bạn sử dụng định nghĩa thông thường của một quy trình - một cái gì đó đang chạy như một quy trình đơn lẻ (theo nghĩa hạt nhân nhìn thấy nó), thì ví dụ, một ứng dụng web PHP được mô tả trong httpd bởi một mô-đun là hoàn toàn ngược lại. Các thư viện chia sẻ được tải vẫn nằm trong phạm vi của một quy trình (vì chúng sử dụng cùng một không gian địa chỉ) hoặc chúng đã tách biệt hơn (không thể thay đổi từ điểm của lập trình viên, hoàn toàn có thể sử dụng lại và giao tiếp thông qua API được xác định rõ)?
Mặt khác, hầu hết các ứng dụng web ngày nay được chia thành các phần máy khách và máy chủ, đang chạy dưới dạng các quy trình riêng biệt - thường là trên các hệ thống khác nhau (và thậm chí cả phần cứng được phân tách vật lý). Hai phần này giao tiếp với nhau thông qua giao diện được xác định rõ (thường là văn bản) (XML / HTML / JSON qua HTTP). Thông thường (ít nhất là trong trình duyệt) có một số luồng đang xử lý phía máy khách của ứng dụng (JavaScript / DOM, đầu vào / đầu ra ...), đôi khi thậm chí là một quy trình riêng biệt chạy plugin (Java, Flash, ... ). Nghe có vẻ giống hệt triết lý UNIX gốc, đặc biệt là trên Linux, nơi các luồng là các quá trình bằng (gần như) bất kỳ tài khoản nào.
Ngoài ra, các bộ phận máy chủ luôn được chia thành nhiều phần riêng biệt - công cụ cơ sở dữ liệu riêng biệt thực hiện các hoạt động được yêu cầu trên dữ liệu có cấu trúc (hoặc không có cấu trúc) là một ví dụ điển hình. Việc tích hợp cơ sở dữ liệu vào máy chủ web sẽ không có ý nghĩa gì nhiều. Tuy nhiên, việc phân chia cơ sở dữ liệu thành nhiều quy trình chỉ chuyên phân tích các yêu cầu, tìm nạp dữ liệu từ lưu trữ dữ liệu, lọc dữ liệu .... Người ta phải cân bằng giữa việc tạo ra một chế độ toàn năng và một một nhóm công nhân gần như vô dụng dành phần lớn thời gian để nói chuyện với nhau.
Đối với giao diện văn bản : lưu ý rằng những gì đúng với dữ liệu được xử lý 40 năm trước không nhất thiết phải đúng ngày hôm nay - các định dạng nhị phân rẻ hơn cả về không gian và năng lượng cần thiết cho việc khử / tuần tự hóa, và lượng dữ liệu lớn hơn rất nhiều.
Một câu hỏi quan trọng khác là, điều gì thực sự là mục tiêu của triết lý UNIX? Tôi không nghĩ mô phỏng số, hệ thống ngân hàng hoặc phòng trưng bày ảnh / mạng xã hội có thể truy cập công khai đã từng có. Bảo trì các hệ thống chạy các dịch vụ này tuy nhiên chắc chắn đã và có thể sẽ có trong tương lai.