История изменений

Внезапно, «сайтики на php» тоже состоят из сервера и клиента. :)

Я с этим не спорю. Только логика у вас будет в html-генерации, а не собственно в том, что нужно сделать. И какие модели вы не будете использовать, MVC и прочие абстракции при таком подходе у вас всегда будет только законченная версия продукта - html код. Ниже я поясню в чем разница.

Если вы мне объясните, каким таким образом вы обойдете HTML как конечный результат генерации веб-страницы (а никакой не js), я вам памятник поставлю (метафорический).

А не надо мне ничего, спасибо. Объясню нынешнее и многими проверенное решение как можно делать приложения для всех типов устройств:

• Серверная часть. Ключевой момент выбор API: json, json-rpc, rest.
  
• Клиент, готовый работать с этим API: js, qt, perl, c, c++, c#, вобщем какой язык не возьми, все они смогут общаться по этому апи.

Основная тенденция в том, что эту модель начали переносить даже в systemd. И в ближайшие полгода появятся готовые инструменты для работы с этим. Даже на локалхосте данная архитектура себя оправдывает, хотя и не без потерь производительности (они несущественны). Red Hat, если смотреть за их софтом по настройке того же iptables (в rhel и gui'шка своя, в федорке 19 некий firewalld), активно впиливает и продвигает данные методики. Т.к. это дает огромный скачек в развитие приложений: сервер пишется один раз и можно написать 100500 клиентов под все виды платформ от вебовской, до межсерверной (демон-демон). А поскольку текущий JS сильно завязан на html-коде, то поверх этого простого API вешается HTTP. Отвязаться от HTTP очень легко, точно также как и привязать его (по крайне мере в перле). Конечно для максимум перформанс тут подойдет решение типа CORBA, но увы, веб его никак не собирается поддерживать.

Внезапно, «сайтики на php» тоже состоят из сервера и клиента. :)

Я с этим не спорю. Только логика у вас будет в html-генерации, а не собственно в том, что нужно сделать. И какие модели вы не будете использовать, MVC и прочие абстракции при таком подходе у вас всегда будет только законченная версия продукта - html код. Ниже я поясню в чем разница.

Если вы мне объясните, каким таким образом вы обойдете HTML как конечный результат генерации веб-страницы (а никакой не js), я вам памятник поставлю (метафорический).

А не надо мне ничего, спасибо. Объясню нынешнее и многими проверенное решение как можно делать приложения для всех типов устройств:

• Серверная часть. Ключевой момент выбор API: json, json-rpc, rest.
  
• Клиент, готовый работать с этим API: js, qt, perl, c, c++, c#, вобщем какой язык не возьми, все они смогут общаться по этому апи.

Основная тенденция в том, что эту модель начали переносить даже в systemd. И в ближайшие полгода появятся готовые инструменты для работы с этим. Даже на локалхосте данная архитектура себя оправдывает, хотя и не без потерь производительности (они несущественны). Red Hat, если смотреть за их софтом по настройке того же iptables (в rhel и gui'шка своя, в федорке 19 некий firewalld), активно впиливает и продвигает данные методики. Т.к. это дает огромный скачек в развитие приложений: сервер пишется один раз и можно написать 100500 клиентов под все виды платформ от вебовской, до межсерверной (демон-демон).