Юрий Ярош: При подготовке к тестированию я просто сел и прочитал документацию за один вечер. Самое сложное для меня было это репликацию настроить, потратил ещё 1 вечер.
В интернете можно даже найти русскоязычную версию. Всё проще некуда.
Проще и дешевле? Чем это MySQL проще? И уж точно не дешевле, т.к. PostgreSQL можно продавать со своим продуктом, а компьюнити версию MySQL нельзя. Придётся покупать.
Павел Соловьёв: похоже вы до сих пор не понимаете что конструкция $this->getContainer()->get('myService') это почти тоже самое что global. Или слепое использование паттернов без их понимания сейчас считается писком моды?
Павел Соловьёв: прохладные истории. Есть zope.interface. Это ваш унылый PHP деревянный из-за своей убогой системы инклудов и идиотской системой автоподгрузки. Вот уж где нет гибкости так этот тут.
Посмотрите Pyramid и поймёте, что ваши larvel и Symfony 2 жалкие попытки сделать что-то хорошее и простое.
Pyramid гибче, проще и удобнее при наличии всех остальных возможностях.
President42: есть несколько подходов. Один из подходов(самый распространённый), что сервер исключительно БД для clientside. Соответственно на клиенте тоже должны быть model и view
President42: производительность не самое важное.. К тому же нужно понимать что производительность разится от браузера к браузеру. Нужно смотреть на скорость/удобство разработки и возможности.
Polymer, например, в IE(скорее всего и в спартане) просто катастрафически медленный, да и к тому же у него polyfill который реализует все необходимые возможности для браузеров, ещё не до конца дописан.
ReactJS же можно использовать на NodeJS и строить клиентскую часть на сервере.
p.s.
прочитал предыдущий комментарий свой. Хочу уточнить. Подходят для сложных серверных приложений именно React и Polymer, а вот Angular, Ember не очень, т.к. сильно формализуют систему моделей и работы с ними.
Ramallah: Можно заовнокодить всё что угодно, но :) Но инструмент должен ограничить возможности писать говнокод и дать возможность всё сделать наиболее читаемо и понятно. Это можно делать, поставив жесткие рамки при разработке (frame work - работа в рамках).
Когда слишком много возможностей модифицировать клиентскую часть, то получается, что логика приложения уезжает в отображение: https://github.com/tastejs/todomvc/blob/gh-pages/e...
President42: Пока сами не попробуете, то вы и не поймёте на чём остановиться. Вообще на чистом jQuery лучше не делать приложения, т.к. в любом случае получите смешивание логики и отображения.
ReacJS и Polymer позволят вам отделить отображение от логики. Многих не устраивает то что некоторые решения строго формализуют того, как нужно создавать модели. Особенно если вы строете приложение со сложной логикой на сервере, то данные решения как никогда отлично подходят. Т.к. вы можете конструировать отображение в зависимости от прав и т.д. и т.п.
Ramallah: AngularJS - он был. Именно был, потому что его больше не разрабатывают. И Angular 2 не будет иметь ничего общего с ним. Он не используется в больших проектах из-за ужасно размазанной логики, получаемой в результате. Можно конечно углубиться в "размазывание" логики, но я не вижу в этом смысле, если уже разработчики признали фиаско.
В интернете можно даже найти русскоязычную версию. Всё проще некуда.