Владислав Безенсон: соль в том что повсюду в бутстрапе активно используется концепция блоков и модификаторов, пусть и с отсутствием элементов (хотя и это дело местами просматривается). Введение же BEM в проект типа бутстрапа оттолкнет большую часть пользователей. Не всем бэм подуше.
Владислав Безенсон: минимизация использования каскада, разделение на элементы и модификаторы, по сути многое взято из BEM. То что они не приняли конвенцию по именованию классов и не настолько впадают в крайности - другой вопрос. Это обсуждалось уже на гитхабе. Идея БЭМ-а вся таки сохраняется, и если сравнивать с другими методологиями то все же они пошли ближе к БЭМ.
Insayt: лямбды уже поддерживаются в хромах и ноде, и они так же неявно возвращают значения, и так можно накосячить с обычным JS. Так что... не в трансляторах дело а в головах и в богомерзском JS который может вернуть из конструктора что угодно.
Кирилл Туровников: это проблема не фреймворка, а реализации. Бутстрап тоже стики футеры пока не умеет, а на флексбоксах делать сложные лэйауты довольно просто.
Я много на чем пишу, основной мой стэк - PHP и JS, в частности на ноде обычно у меня отдельные маленькие микросервисы которые занимаются всякой ересью вроде обработкой задачь из очередей, их маршрутизацией или же доставкой на клиент через websocket (что не говори, а socket.io удобный).
ГЛЕБ ГЛЕБОВ: PHP медленнее, но потребляет меньше памяти и умирает, что означает что он ооочень легко горизонтально масштабируется. Нода быстрая, жрет больше памяти и однопоточна, что значит что вы можете все запороть случайно сделав выполнив синхронную операцию, и всеравно придется поднимать на одном сервере по инстансу на ядро.
Вывод - PHP норм. А еще есть штуки вроде reactphp, которые по сути та же нода но на php (в основе тот же event loop что и у ноды, причем есть и биндинг для работы с i/o - libuv, который используется внутри ноды). Ну или вариант попроще, при котором не нужно переделывать архитектуру приложения - php-pm, который невилирует расходы на бутстрапинг приложения или другими словами делает так что php больше не умирает.
amatory10: начну с того что в Angular2 уже не будет такой вещи как $scope, привыкайте.
Вообще $scope это весьма специфичная для ангуляра штука, роль которой - привязка данных. Прежде чем инджектить скоуп куда либо кроме link директивы, стоит пару раз подумать зачем мы это делаем. Ну и да, это защищает нас от такой идеи как "повесить ватчер в контроллере".
Если от него избавиться, то:
- код становится чище, поддерживаемость приложения повышается
- мы проще достигаем старого доброго MVC
linux0uid: ой ну вот ненадо, сфинкс только индекс строит быстрее, и то я думаю что это так себе преимущество с учетом того что эластика не медленнее и по возможностям сильно лучше, по потреблению памяти ES может в каких раза полтора жирнее, все зависит от количества данных. И тому и другому нужно в памяти индексы хранить что бы быстро работать, и в итоге они могут и вовсе сравняться.
Ну и да, для эластики решений готовых намного больше, и сама реализация отработана в куче проектов.
Егор Мокеев: решил погуглить как эту проблему решают другие... и оказалось что никак. Либо вообще не используют юнит тесты, либо пытаются изолировать AR от кода приложения (по сути репозиторий). По сути единственный способ нормально использовать юнит тесты в контексте тестирования модели - persistence ignorance, а на данный момент это хорошо работает только в доктрине (ну и может еще в пропел 2 когда-нибудь).
Егор Мокеев: репозиторий отделяет вас от того, что вы используете для персистинга, AR или что-то другое. У вас скажем может быть inmemory репозиторий который просто в массивчике сохраняет на время теста.
Единственное что, от необходимости что-то делать с save методами мы ничего поделать не можем, ибо либо мы тогда перекладываем это на репозиторий (что без UoW не удобно), либо страдаем с кастылями.
я вообще против бандлов... только если это реально нужно (например какой-то компонент реюзать). Но если в бандле есть сущности или контроллеры - то это как по мне плохо (хотя есть и исключения).
