Saya pikir itu sangat tergantung pada di mana Anda menggambar batas antara aplikasi (yaitu apa definisi Anda tentang aplikasi), dan apa kasus penggunaan yang Anda pertimbangkan.
Meskipun Anda dapat mengimplementasikan browser web sebagai penggabungan dari wget/ curl, parser HTML / XML yang akan memanggil aplikasi sederhana untuk setiap node dokumen, mesin JavaScript mandiri yang akan berinteraksi dengan semua ini dan displayer "sederhana" yang akan "hanya" letakkan output di atas pada layar (dan kembalikan input ke beberapa proses koordinasi inti) bahkan akan lebih berantakan daripada (mungkin ada) browser hari ini lainnya.
Adapun memipipkan data ke proses eksternal - begitulah sebenarnya itu dimulai . Jika Anda khawatir tentang ukuran kode aplikasi web rata-rata, ya mereka sering besar (dan sering karena mereka adalah lapisan yang duduk di atas platform yang ditulis dalam bahasa pemrograman yang ditafsirkan daripada aplikasi "sederhana"), tetapi bandingkan untuk setara mereka. Klien email, suite kantor ... sebut saja. Semua ini cukup kompleks dan memiliki terlalu banyak fungsi untuk diimplementasikan sebagai beberapa proses berkomunikasi melalui pipa. Untuk tugas-tugas yang Anda gunakan untuk aplikasi ini seringkali rumit juga. Tidak ada solusi sederhana yang baik untuk masalah yang kompleks.
Mungkin sudah waktunya untuk melihat sedikit di luar motivasi di balik moto UNIX "aplikasi yang melakukan sedikit tetapi baik dalam hal itu". Ganti "aplikasi" dengan "unit modular umum" dan Anda tiba di salah satu praktik pemrograman dasar yang baik: lakukan hal-hal secara modular, sehingga bagian-bagian dapat digunakan kembali dan dikembangkan secara terpisah . Itulah yang benar-benar penting, IMHO (dan pilihan bahasa pemrograman sangat sedikit hubungannya dengan itu).
ps (mengikuti komentar) : Dalam arti paling ketat Anda sebagian besar benar - aplikasi web tidak mengikuti filosofi UNIX (dibagi menjadi beberapa program mandiri yang lebih kecil). Namun keseluruhan konsep tentang apa yang tampak aplikasi agak keruh - sedmungkin dapat dianggap sebagai aplikasi dalam beberapa situasi , sementara biasanya bertindak hanya sebagai filter.
Oleh karena itu tergantung pada seberapa harfiah Anda ingin mengambilnya. Jika Anda menggunakan definisi proses yang biasa - sesuatu berjalan sebagai proses tunggal (dalam arti kernel melihatnya), maka misalnya aplikasi web PHP yang ditafsirkan dalam httpd oleh modul adalah kebalikannya. Apakah pustaka bersama yang dimuat masih termasuk dalam ruang lingkup proses tunggal (karena mereka menggunakan ruang alamat yang sama) atau apakah mereka sudah sesuatu yang lebih terpisah (tidak dapat diubah dari titik pemrogram, sepenuhnya dapat digunakan kembali dan berkomunikasi melalui API yang terdefinisi dengan baik)?
Di sisi lain, sebagian besar aplikasi web saat ini dipecah menjadi bagian klien dan server, yang berjalan sebagai proses terpisah - biasanya pada sistem yang berbeda (dan bahkan perangkat keras yang terpisah secara fisik). Dua bagian ini berkomunikasi satu sama lain melalui antarmuka yang didefinisikan dengan baik (biasanya tekstual) (XML / HTML / JSON melalui HTTP). Seringkali (setidaknya di browser) ada beberapa utas yang memproses sisi klien dari aplikasi (JavaScript / DOM, input / output ...), kadang-kadang bahkan sebuah proses terpisah menjalankan sebuah plugin (Java, Flash, ... ). Itu suara persis seperti filosofi UNIX asli, terutama pada Linux, di mana benang adalah proses oleh (hampir) setiap akun.
Selain itu, bagian server cukup banyak selalu dibagi menjadi beberapa bagian yang berbeda - mesin database terpisah melakukan operasi yang diminta pada data terstruktur (atau tidak terstruktur) adalah contoh kanonik. Tidak masuk akal untuk mengintegrasikan database ke server web. Namun itu juga tidak masuk akal untuk membagi database menjadi beberapa proses yang akan mengkhususkan diri dalam mengatakan hanya mengurai permintaan, mengambil data dari penyimpanan data, menyaring data .... Kita harus mencapai keseimbangan antara menciptakan raksasa yang mahakuasa dan sebuah segerombolan pekerja yang hampir tak berdaya yang menghabiskan sebagian besar waktu mereka berbicara satu sama lain.
Adapun antarmuka tekstual : perhatikan bahwa apa yang benar untuk data yang diproses 40 tahun yang lalu belum tentu benar hari ini - format biner lebih murah baik dalam ruang dan daya yang diperlukan untuk de / serialisasi, dan jumlah data jauh lebih besar.
Pertanyaan penting lainnya adalah, apa yang sebenarnya menjadi target filosofi UNIX? Saya tidak pernah berpikir simulasi numerik, sistem perbankan atau galeri foto / jejaring sosial yang dapat diakses publik. Namun, pemeliharaan sistem yang menjalankan layanan ini sudah dan kemungkinan akan terjadi bahkan di masa depan.