Сергей Протько

А при чем тут индексация, robots.txt и внешние js файлы?

stackoverflow.com/questions/2358253/php-streaming-mp3

Еще один плюс Twig - если разработчик хочет сделать что-то там, где этому нету места, то у него будут с этим проблемы.

Не следует делать этого в шаблонах. Вообще. Если очень хочется то можно так:

<script>
window.location = {{post.link | json_encode()}};
</script>

Почему именно так? Потому что иначе пришлось бы возиться с буфером вывода, а это уже явно не то место где это следует делать. Если же у вас хоть один байт лета запроса просочился в stdout, то заголовки менять уже нельзя.
но по хорошему это следует делать в контроллере.

Ну а почему только PHP или Java? Можно взять Hack как компромисс: сочетает в себе плюсы php и привносит в него строгость java.

Ну а если серьезно... в плане безопасности разницы особо нету. В плане производительности java быстрее, но есть не нулевая вероятность что разницы особо вы не почувствуете. В плане поиска рабочей силы... Java имеет свое преимущество, ибо шансы найти разработчика который пишет ногами чуть ниже чем в случае с PHP. И последний жирный плюс в сторону Java и против PHP - инструменты разработки, библиотеки и фреймворки и хорошая культура разработки среди джавистов. В PHP все это только зарождается. Некоторых инструментов нету, некоторые пока сырые или кривые... В основном это относится к тестированию кода. Но ситуация с каждым днем улучшается.

Но вернемся к нашим баранам. Что мы имеем из задания:
1000 пользователей, пускай и активных, выдержит нормально написанный сайт что на php что на java. Это не хай-лоад.

безопасность - зависит от настроек сервера. в плане PHP - при использовании PDO, prepared statements и/или нормальной ORM которая в свою очередь все это внутри использует, вероятность sql инъекций равна нулю. При использовании шаблонизаторов типа Twig вероятность XSS стремится к нулю (зависит от опыта разработчика, но экранирование вывода по умолчанию снижает вероятность ошибки). Для генерирования репортов: проще будет взять node.js, phantom.js и репорты генерить в этом добре, связав с основным приложением через какой rabbitmq/zeromq/Resque. Явно будет эффективнее и круче.

Запомните, все то что происходит в браузере делается только на HTML + Javascript. PHP - на сервере и предоставляет данные или тот же HTML.

Что до вашей задачи - AJAX.

strtotime(strtr('20 августа 2014', [
    'августа' => 'august',
    ...
]);

суть вы поняли.

Да, если вы прописываете массив реквестов, Guzzle будет пытаться все это дело отправлять через curl_multi собственно как и в примере.

Так же почитайте вот это:
guzzle3.readthedocs.org/en/latest/batching/batchin...

самый оптимальный вариант с точки зрения производительности - websockets. Можно реализовать на ReactPHP (+libav например) или node.js с шиной данных на zeromq/rabbitmq с основным приложением (в любом случае нужно будет организовывать).

Можно Канта почитать. Ницше так же неплох, но может не пойти.

Для REST будет идеален фреймворк основанный на Symfony/HttpKernel (имплементящий HttpKernelInterface). Это даст вам возможность абстрагироваться от запросов, применять реверс-прокси кешеры а так же возможность модифицировать запросы/ответы по слоям, этим упростив архитектуру. В частности быстро прикрутить CORS, сделать авторизацию на уровень выше и т.д. можно будет за счет http middlewares и в частности stackphp. Есть JMSSeializer (который можно будет заменить на свой сериализатор, если будет стоять вопрос о производительности), который позволит вам декларативно описать правила сериализации/десереализации ресурсов и вынести все это дело на слой выше, абстрагируясь таким образом от всего этого в коде вашего приложения. Так же возможность быстро прикрутить версионизацию апишки.

Если у вас кучи связей и вопрос производительности не стоит остро (только поддерживаемость кода) - Doctrine ORM. Если производительность - острый вопрос, стоит смотреть в сторону использования DBAL и оберточек. Если у вас все будет сделано по уму (код напрямую с репозиториями не работает и вообще ничего не знает о Doctrine), то заменить слой работы с базой на что-то пошустрее будет не проблема.

По интернационализации так же проблем особо не должно возникнуть. Есть экстеншены для doctrine, есть symfony/translation и кучи других либ.

Если вам нужна гибкая система аутентификации и авторизации, разграничение прав гибкое и все такое - symfony/security удовлетворит все юз-кейсы и позволит все это покрыть тестами.

Так что из перечисленных вами вариантов - Silex. Но если хочется еще и меньше бойлерплейт кода писать, то Symfony. Учитывая что по времени вы сильно не ограничены, то будет время разобраться как делать все правильно. Вопросы производительности стоит решать по мере возникновения проблем, вообще у REST с этим не так много проблем. Узкие места можно переписать на чем-то другом, например на go, можно оптимизировать persistance-layer, сериализацию (при простых запросах JMSSerializer дает большой оверхэд по времени, так что можно в особых случаях написать свой оптимизированный под определенный response сериализатор) и т.д.

Но в целом вы можете использовать отдельные компоненты в связке с тем же Silex. Вообще все упирается больше в количество бойлерплейт и сервисного кода. В целом если вы будете подходить грамотно к построению архитектуры приложения можно на чем угодно написать нормально. Вопрос только в том что какие-то вещи где-то правильно сделать сложнее.