Я думаю, что это во многом зависит от того, где вы проводите границу между приложениями (т.е. как вы определяете приложение), и какие варианты использования вы принимаете во внимание.
Хотя вы можете реализовать веб-браузер как объединение wget/ curl, анализатор HTML / XML, который будет вызывать простое приложение для каждого узла документа, автономный движок JavaScript, который будет взаимодействовать со всем этим, и «простой» инструмент отображения, который «просто» разместите вывод вышеупомянутого на экране (и верните входные данные обратно в какой-то основной координационный процесс), это будет еще более беспорядочным, чем (возможно, любой) другой сегодняшний браузер.
Что касается передачи данных во внешний процесс - это то, как он фактически начался . Если вас беспокоит размер среднего кода веб-приложения, да, они часто бывают большими (и часто потому, что они представляют собой слой, расположенный над платформой, написанной на интерпретируемом языке программирования, а не на «простом» приложении), но сравните его. к их эквивалентам. Почтовые клиенты, офисные пакеты ... вы называете это. Все они довольно сложны и имеют слишком много функциональности, чтобы быть реализованными в виде пары процессов, взаимодействующих через каналы. Для задач, для которых вы используете эти приложения, часто тоже сложны. Нет хороших простых решений сложных проблем.
Может быть, пришло время взглянуть на мотивацию под девизом UNIX «приложения, которые мало что делают, но у них это хорошо получается». Замените «приложения» на «общие модульные блоки», и вы получите один из основных хороших методов программирования: делайте вещи модульно, чтобы детали можно было повторно использовать и разрабатывать отдельно . Это то, что действительно имеет значение, ИМХО (и выбор языка программирования имеет к этому мало отношения).
ps (после комментария) : В самом строгом смысле вы в основном правы - веб-приложения не следуют философии UNIX (разделить на несколько небольших автономных программ). Тем не менее, сама концепция того, что представляет собой приложение, выглядит довольно мутной - sedвозможно, в некоторых ситуациях ее можно рассматривать как приложение , хотя она обычно действует как фильтр.
Следовательно, это зависит от того, насколько буквально вы хотите это воспринимать. Если вы используете обычное определение процесса - что-то, выполняемое как отдельный процесс (в том смысле, в котором это видит ядро), то, например, веб-приложение PHP, интерпретируемое модулем httpd модулем, является полной противоположностью. Загруженные разделяемые библиотеки все еще попадают в область действия одного процесса (потому что они используют одно и то же адресное пространство) или они уже являются чем-то более отдельным (неизменным с точки зрения программиста, полностью повторно используемым и взаимодействующим через четко определенный API)?
С другой стороны, большинство современных веб-приложений разделены на клиентскую и серверную части, которые выполняются как отдельные процессы - обычно на разных системах (и даже на физически разделенном оборудовании). Эти две части взаимодействуют друг с другом через четко определенный (обычно текстовый) интерфейс (XML / HTML / JSON over HTTP). Часто (по крайней мере, в браузере) есть несколько потоков , которые обрабатывают клиентскую часть приложения (JavaScript / DOM, ввод / вывод ...), иногда даже отдельный процесс, выполняющий плагин (Java, Flash, ... ). Это звучит точно так же, как и в оригинальной философии UNIX, особенно в Linux, где потоки являются процессами (почти) любой учетной записи.
Кроме того, серверные части почти всегда разбиты на несколько отдельных частей - отдельный механизм базы данных, выполняющий запрошенные операции со структурированными (или неструктурированными) данными, является каноническим примером. Просто не имеет смысла интегрировать базу данных в веб-сервер. Тем не менее, не имеет большого смысла разделять базу данных на несколько процессов, которые специализируются, скажем, только на синтаксическом анализе запросов, получении данных из хранилища данных, фильтрации данных ... Необходимо найти баланс между созданием всемогущего бегемота и рой почти нильпотентных рабочих, которые проводят большую часть своего времени, разговаривая друг с другом.
Что касается текстового интерфейса: обратите внимание, что то, что было верно для данных, обработанных 40 лет назад, не обязательно верно сегодня - двоичные форматы дешевле как по пространству, так и по мощности, необходимой для де-сериализации, а объем данных намного больше.
Другой важный вопрос также заключается в том, что на самом деле было целью философии UNIX? Я не думаю, что когда-либо имело место численное моделирование, банковские системы или общедоступные фотогалереи / социальные сети. Однако обслуживание систем, работающих с этими службами, безусловно, было и, вероятно, будет в будущем.