Есть некоторые не логичные пункты сравнения. Например Кастомизация компонентов. Противопостваляется "у лары нет компонентов и нет проблем" у "битрикс сложно". Соответственно тут вообще нельзя по этому критерию сравнивать. В то же время ни кто вообще не мешает написать свой компонент с ноля. Причем, при желании, вполне можно использовать хоть лару хооть симфони (главное что б в этом был действительно практический смысл). Лучше пожалуй сифони, т.к. некоторые ее сущности есть в битриксе (но это так, незначительный плюс в торону выбора сифони против лары в рамках проекта битрикс :)
По БД тоже такое себе сравнение. Для узких мест ни кто не мешает создать свою архитектуру в бд. и работать с ней через АПИ битрикс (позволит использовать, например, событийную модель, ну и прочие "плюшки") В т.ч. будет работа именно с объектами, а не с массивами. (включая данные)
Вопрос про то что если модуль кастомизирован и его потом сложно... Тут скорее вопрос как раз в том, что "требования к специалисту ниже". Если вменяемый человек кастомизировал - все ок.
В общем очень много проблем именно из-за квалификации.
Тут многие пункты относятся больше к сравнению классов инструментов универсальна CMS vs Framwork.
Если оставить сравнение исключительно только Битрикс vs лара. что статья получилась бы меньше.
По этому гораздо правильнее сначала клиенту дать сравнение решения на CMS и на Framework
После того как выбран класс инструмента. Уже вторым этапом сравнивать решения на разных CMS (или на разных фреймворках). Но это, как правило, уже сводится к тому, какой инструмент лучше знает данная команда веб разработчиков. :)
В целом со статьей скорее согласен. но :)
Есть некоторые не логичные пункты сравнения. Например Кастомизация компонентов. Противопостваляется "у лары нет компонентов и нет проблем" у "битрикс сложно". Соответственно тут вообще нельзя по этому критерию сравнивать. В то же время ни кто вообще не мешает написать свой компонент с ноля. Причем, при желании, вполне можно использовать хоть лару хооть симфони (главное что б в этом был действительно практический смысл). Лучше пожалуй сифони, т.к. некоторые ее сущности есть в битриксе (но это так, незначительный плюс в торону выбора сифони против лары в рамках проекта битрикс :)
По БД тоже такое себе сравнение. Для узких мест ни кто не мешает создать свою архитектуру в бд. и работать с ней через АПИ битрикс (позволит использовать, например, событийную модель, ну и прочие "плюшки") В т.ч. будет работа именно с объектами, а не с массивами. (включая данные)
Вопрос про то что если модуль кастомизирован и его потом сложно... Тут скорее вопрос как раз в том, что "требования к специалисту ниже". Если вменяемый человек кастомизировал - все ок.
В общем очень много проблем именно из-за квалификации.
Тут многие пункты относятся больше к сравнению классов инструментов универсальна CMS vs Framwork.
Если оставить сравнение исключительно только Битрикс vs лара. что статья получилась бы меньше.
По этому гораздо правильнее сначала клиенту дать сравнение решения на CMS и на Framework
После того как выбран класс инструмента. Уже вторым этапом сравнивать решения на разных CMS (или на разных фреймворках). Но это, как правило, уже сводится к тому, какой инструмент лучше знает данная команда веб разработчиков. :)