Почему люди не используют готовые cms, но ищут тех, кто будет писать с нуля?
==============================================================================

 Недавно знакомый рассказывал, что изучил 10 cms и делает многие сайты даже не копаясь глубоко, те же сайты, что и получаются вёрсткой. Возникает вопрос, почему тогда работодатели нанимают за высокую плату много программистов, чтобы они копались в коде, но не тех, кто будет делать тот же продукт, прибегая к помощи к cms? 

 Чистый php, фреймворк и cms - это 3 уровня абстракции.  

  

Предположим, домохозяйка решила приготовить пирог - пошла в магазин, купила готовое тесто, испекла пирог.  

Временные и трудовые затраты минимальны. Вкусовые качества пирога - заурядные, сойдет для школьной столовой, но не более. Так вот, это CMS.  

  

Предположим, домохозяйке не нравится магазинное тесто, она купила муку и яйца, замесила тесто, испекла пирог. Вкусовые качества пирога на порядок улучшились, а временные и трудовые затраты повысились. Это фреймворк.  

  

Предположим, домохозяйке не нравится качество магазинной муки и магазинных яиц. Она засевает поле, сеет рожь/пшеницу, пашет, собирает урожай, перемалывает урожай в муку, заводит кур, собирает яйца и из всего этого делает пирог. Временные и трудовые затраты феноменальные, зато пирог вкуснейший. Это чистый PHP.  

  

Чем ниже уровень абстракции, тем выше квалификация специалиста.  

  

PS Как и любая аналогия, эта весьма условна и предполагает, что домохозяйка во всех 3 случаях работает на совесть и является профессионалом. В реальной жизни часто бывает, что на чистом php делают гораздо больший хардкор, чем собирают на CMS.  

  

По итогу: в зависимости от сложности задачи и уникальности фукционала, специалист должен выбирать, какой уровень из этих 3 уровней абстракции ему использовать. Хоть они и пересекаются, но не очень сильно, и конкуренции друг для друга почти не представляют. Далеко не факт, что ваш знакомый, который "изучил 10 cms", сможет эффективно решать те задачи, которые ставят работодатели, нанимающие "много программистов что бы они копались в коде" 

> Возникает вопрос, почему тогда работодатели нанимают за высокую плату много программистов что бы они копались в коде а не тех кто будет делать тот же продукт прибегаю к помощи к cms?

  

На это есть много причин, в том числе:  

а) CMS (большинство) гораздо медленнее большинства фреймворков, обычно в 10-50 раз  

б) CMS - не редко так же построены на фреймворках, например Drupal 8 - построен на Symfony. Получается, что CMS это уже продукт. Делать продукт из продукта (или продукт поверх продукта) в этой цепочке - не очень разумно. Это всё равно, что пытаться сделать гоночный болид из жигулей 6-ой модели, вместо того, что бы спроектировать и создать его заново.  

в) CMS предназначены для быстрой разработки сайтов. Скорость разработки достигается за счёт ущерба качеству буквально всего. В среднем CMS генерирует 100-1000 SQL-запросов на создание страницы, аналогичный проект на фреймворке тратит на это 5-20 запросов (примерно). У нас например, есть проект сделанный на фреймворке - база технических изделий, среднее кол-во запросов на страницу - до 20шт. и с учётом объёмов данных (деталей там несколько тысяч, а их параметров - несколько десятков тысяч) - это всё довольно неплохо нагружает сервер. Аналогичный проект на CMS потребовал бы просто аховых затрат на хостинг и генерировал бы по 500-700 запросов на страницу (мы проверяли).  

г) Из CMS гораздо сложнее сделать именно то, что хочется, а не то, "что получилось".  

д) CMS налагает свои правила на работу, а ФВ обычно ограничиваются некоторыми рекомендациями (в большинстве случаев).  

е) и так далее...  
  

Так происходит по тому, что CMS созданы для решения шаблонных задач, а проекты на ФВ пишутся обычно, для решения вполне конкретных задач.  
  

P.S. Очень крупные проекты, типа FaceBook, VK и пр. пишутся даже не на CMS, а на чистом PHP например. Т.к. CMS в таких проектах - так же даёт избыточную нагрузку, с учётом масштабов этих самых проектов.  
  

P.P.S. Недавно настраивал небольшой корпоративный сервер, там 4-х ядреный процессор, 8Gb RAM и обычно HDD 7200/rpm. "Голая" Joomla 3.6 с демо данными, генерировал страницу за 250-400мс., чуть более крупный по масштабам проект, сделанный на ФВ, так же с авторизацией и пр. плюшками, генерировал страницу (сложнее) за 20-50мс. 

 Добавлю:  

> Компания Sucuri, специализирующаяся на web-безопасности, опубликовала отчет за третий квартал 2016 года по самым взламываемым CMS. По результатам анализа за подотчетный период было скомпрометировано 7937 сайта. Чаще всего злоумышленники успешно взламывали сайты под управлением WordPress, Joomla и Magento.  
> 
> Согласно отчету, 74% скомпрометированных сайта работали под управлением WordPress, 17% под управлением Joomla и 6% под Magento.

  

UPD: из свежих уязвимостей: [https://blog.sucuri.net/2017/02/content-injection-...](https://blog.sucuri.net/2017/02/content-injection-vulnerability-wordpress-rest-api.html)  

UPD\_2018: В платформе WordPress CMS была обнаружена простая, но очень серьезная уязвимость, связанная с атаками типа «отказ в обслуживании» (DoS) на уровне приложений, которая позволяет любому пользователю приводить в нерабочее состояние большинство веб-сайтов WordPress даже с помощью одной машины. Происходит это без необходимости задействовать огромное количество компьютеров для переполнения полосы пропускания, как это требуют DDoS-атаки, но с достижением того же результата.  

Поскольку WordPress Foundation отказали в исправлении проблемы, уязвимость (CVE-2018-6389) остается без патча и затрагивает почти все версии WordPress, выпущенные за последние девять лет, включая последнюю стабильную (WordPress версия 4.9.2). 

 Никакой из вариантов не лучше и не хуже.  
  

Просто на сложных проектах доведение функционала плагинами и костылями на CMS требует большего времени и денег, чем написание на фреймворке. В наши дни качественный сайт будет скорее написан с использованием фреймворка, нежели самопис. Во многих случаях самописный сайт хуже CMS — он давно не поддерживается, привязан к конкретной студии и не обновляется годами, работая, к примеру, на медленном PHP 5.2. Рефакторинг такого старья выйдет дороже переделки с нуля, иначе говоря игра не стоит свеч.  
  

CMS/CMF тоже решают определенные проблемы. Например, при создании несложных сайтов нет смысла делать это на фреймворке. Но, как писал выше, при разрастании сложности сайт на CMS начинает тормозить. На популярные CMS обращены взоры хакеров, поэтому вероятность что вас взломают — чуть выше. Правда этот вопрос решается регулярным обслуживанием.  
  

Итого: фреймворки и CMS рулят. Самописы — это чаще всего неподдерживаемый говнокод с малофункциональной админкой. 

 Респект автору за сравнение труда создателя сайта с домохозяйкой, но, зри: - нужно грамотно выбрать сорт зерновых для засева; определиться: использовать или нет удобрения при взращивании; технологию борьбы с плевелами; способ сбора урожая; технологию помола. Как любитель кулинарии скажу - это не реально... С другой стороны: покупатель продукта скажет мне: я тоже этим премудростям не научен - дай мне достойный результат. Вот тут о и собака порылась! А что же надо заказчику? "Я хочу, чтобы все было хорошо". Я, например, как только слышу такую сентенцию, начинаю более дотошно уточнять у заказчика: "Что же ему надо?". Если он отвечает по-простецки: "Ты что, дурак? Надо, чтобы у меня все было хорошо!", то плавно отказываюсь от дальнейшей работы (даже если заказ денежно или по иному интересен), пока у заказчика не появится (а тут надо и самому старание приложить), более осмысленное пониамние, а что же ему надо... 

 Потому, что CMS могут не иметь того функционала, который попросил заказчик. Опытный программист же сможет и эту CMS написать и допилить если надо 

> Возникает вопрос, почему тогда работодатели нанимают за высокую плату много программистов что бы они копались в коде а не тех кто будет делать тот же продукт прибегаю к помощи к cms? 

  

Причина одна, и она простая: так выгоднее.  
  

Сравнивают расходы на проект с импользованием CMS и без неё.  

В итоге 90% делают на CMS (это самые простые дешёвые и короткоживущие проекты), а 10% без них. 

> Почему все не используют cms а ищут тех кто будет писать с нуля?

  

CMS - чаще всего создается для решения вполне конкретной бизнес задачи. WP - блог (да, я знаю, что на нем и эл. магазины пишут, но это не целевое применение), MODx - под визитки идеальна, Majento - под эл. магазины и т.д.  

Все это конечно же очень круто и здорово, но выходя за целевое применение CMS с большой вероятностью вы начнете с ней воевать. Если например выдвигать требования к качеству кода, [типа таких](https://toster.ru/q/276441#answer_item_723827) - от большей части CMS в принципе ничего не останется своего.  
  

Фреймворки (этот подход вы в вопросе не учли) - предоставляют гибкий каркас, для построения приложений. Например: ваш проект - убийца twitch, под это направление cms особо нет, даже решений мало. Под свою бизнес модель вам на много дешевле будет подобрать фреймворк, на базе которого будет вестись разработка. Грубо говоря это значит: делегировать часть разработки (фреймворк) сообществу.  
  

Голый php: за него стоит браться, если в принципе задача на час - два. Так же стоит браться в случае, если ни один фреймворк под вашу задачу не подходит, либо никак вам не помогает. Пример: вы пишите некую библиотеку для взаимодействия с сервером N, для таких проектов, как правило - чем меньше зависимостей - тем лучше. 

 В первую очередь потому, что термин "сайт" ничего не говорит о сложности веб-приложения.  

Если вам нужен "сайт-визитка" (тоже не вполне определённый термин, но всё же), или блог, или даже стандартный интернет-магазин - берёте СУК, возможно, слегка увешиваете плагинами - и получаете результат. Это не 90% случаев, конечно, но где-то половина, +/-.  

Но если вам нужен достаточно сложный веб-сервис (который тоже как бы сайт, но таки совсем другой) - Тостер, ВК, Ютьюб, Авито - СУК будет полезен очень недолго, а потом придётся либо перепиливать СУК, либо писать своё. 

 CMS CMSу рознь. CMS используют, когда нужно сосредоточиться на функционале проекта, а не на написании сервисных функций типа юзер логина или проверки прав доступа к определенному ресурсу. Это экономит до 90% времени на разработке. 

> и делает многие сайты даже не копаясь глубоко, те же сайты что и получаются вёрсткой

 **Вы ничего не путаете?** Верстать надо и под CMS.  
  

> почему тогда работодатели нанимают за высокую плату много программистов что бы они копались в коде а не тех кто будет делать тот же продукт прибегаю к помощи к cms? 

Наличие CMS не исключает и не уменьшает необходимость работы с кодом. Какая разница в каком коде будут копаться программисты в своем или в чужом? 

 зависит от работы  

1) к примеру это веб студия, которые делают все сайты на одной cms. (к примеру UMI CMS), конечно же им плевать на тех кто круто знает Yii или laravel и т.д. Им нужен программист который будет знать их CMS, а не тот кто на фреймворке сможет создать что угодно.  

2) а если это стартап к примеру какой-то, который нанимает программистов, чтобы делать проект с нуля и сами еще не определились на чем они будут делать - такие уже ищут программиста, которой на фреймворке сможет реализовать все их безумные идеи. 

**Потому, что CMS и фронтенд в целом - разные вещи**  
  

А вообще, используют, только не CMS. Да что там врать, чуть ли не на каждом объявление "требуется знание React/Angular/т.п." 

 на вершине цепочки *чистый PHP - фреймворк - CMS* есть ещё самый нетрудозатратный шаблонный вариант - визуальные конструкторы сайтов. 

 Долго работал на чистом PHP + JS + базы данных, да и сейчас работаю. Но некоторое время назад озадачился поиском работы. К сожалению, как я выяснил, наиболее вкусные вакансии требуют знания каких-либо фреймвоков: Symfony, Laravel и т.п. и т.д.  

Посоветуйте, какой перспективнее в плане поиска работы. Заранее признателен. 

 Все популярные CMS написаны на PHP, а значит в них много ошибок, грязный код, плохое комьюнити и они очень медленно работают.  

Успешный проект на таком не сделаешь. 

 Помимо минусов "кода с нуля" (например, зависимость от разработчика), существуют порой и важные плюсы:  

- движок будет работать так, как надо клиенту, а не в рамках выбранной CMS  

- зачастую (если разработчик хороший), свой двиг с нуля более защищен, чем публичные CMS (под которые обычно есть не мало эксплоитов, позволяющих их взломать).  

- CMS с нуля обычно работает быстрее (опять же, если разработчик хороший), чем публичная CMS (которая вынуждена "тянуть" тонны ненужного функционала).  

- расширять функциональность двига с нуля намного проще и быстрее, чем делать это в рамках выбранной CMS (где костыли и кастомы ставят крест на обновлениях CMS). 

 CMS - это коробочные решения. Где обычно, решаете проблемы самой CMS, а не разрабатываемого проекта. Там есть куда ненужного функционала, багов и прочего говнокода(да, да. куда же без этого.). Да и архитектура, обычно, тоже не блещет элегантностью. В общем, CMS - это по большому счёту, удел говносайтов и прочих дешёвых проектов с фриланса.  
  

Серьёзные проекты(в здравом уме) - не используют CMS. Всё пишется под конкретные задачи проекта. Фрамеворки - несут в себе некий каркас, который ускоряет немного разработку и не даёт совершить некоторых ошибок. 

 Все сложно и не так однозначно, есть достаточно много крупных проектов которые работают на CMS, те же интернет магазины очень часто используют в нашей стране Битрикс, за рубежом Magento. И говорить что для больших проектов не подойдет CMS не совсем правильно и что это удел гавносайтов и дешевых фрилансеров.   

Немного статистики [https://w3techs.com/technologies/overview/content\_...](https://w3techs.com/technologies/overview/content_management/all) 

 А ещё есть понятие бизнес инструмента.  

Google и прочие часто делают бизнес инструменты под себя.  

Их сайтики не волнуют. 

 Здесь всего одна причина, как по мне - всегда лучше сделать с нуля под себя, чем тысячу раз перелопачивать уже сделанное не понятно под что) 

 В моём случае - сложный проект, ориентированный на контент с функционалом интернет-магазина. Изначально выбрал Magento (знаком с ним по версии 1.0, но установка 2.2 и последующих отняла много времени и нервов). На нём контент можно разместить, но это переделка модуля (или добавление нового), что чревато тем, что composer пошлёт привет... и с ним возни больше чем с установкой всего пакета... Увы, зависимость компонентов не для обывателя, готового "сделать и забыть". Пришлось переделать на Zend. Хочется, конечно, избавиться от лишних библиотек и "навязывания" правил кода, но framework - достойный инструмент для создания даже сложного проекта