Выбор платформы: CMS или фреймворк?

Технически любой функционал может быть реализован как на CMS, так и на фреймворке. Однако некоторые проекты проще сделать на CMS, а некоторые — на фреймворке.

По сути, любой сайт или веб-приложение можно разрабатывать при помощи одного из трёх подходов:

Если провести аналогию со строительством дома, то подходы выглядят так:

  • Вы покупаете некий готовый дом, а потом его достраиваете / делает отделку.
  • Вы покупаете кирпичи и доски, а затем приступаете к строительству по своему собственному проекту.
  • Вы ищете и разрабатываете месторождение глины, делаете из неё кирпичи, параллельно с этим вырубаете лес для изготовления досок... Думаю, что можно не продолжать.

Разработку «с нуля» стоит сразу отбросить, так как этот подход может быть правильным только в том случае, если создание проекта — это основная задача компании, а ресурсов под эту задачу выделено очень много. Хорошие проекты «с нуля» пишутся очень долго, хотя этот подход позволяет создавать очень серьёзные решения.

Поэтому рассмотрим только создание сайта на базе платформ:

Разработка на CMS — наиболее правильный подход, если проект достаточно типовой. То есть в CMS уже есть все нужные вам модули, а те процессы, которые встроены в CMS, почти полностью соответствуют вашим ожиданиям.

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

Если возвращаться к приведенной выше аналогии, то «производство стройматериалов» — удел немногих, «покупка готового дома» оптимально подойдёт тем, кому эти готовые дома изначально нравятся, а «строительство из готовых материалов» лучше всего для тех, кто хочет что-то особенное. То есть нерационально как покупать готовый дом и разбирать его на стройматериалы, так и собирать из стройматериалов то, что на рынке уже есть в готовом виде.

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

  • Функционал, который встроен в CMS, дороже и дольше реализовывать на фреймворке, а разработка сложного функционала на CMS или переписывание базовых процессов CMS стоит дороже и занимает больше времени, чем та же работа выполненная сразу на фреймворке.
  • Добиться от сложного проекта на CMS высокой скорости работы стоит дороже, чем сделать это на фреймворке. Аналогично обстоят дела и с масштабированием. То есть при высоких требованиях к устойчивости к нагрузкам, производительности или к отказоустойчивости выбирайте решения на фреймворках (или закладывайте стоимость работ по оптимизации CMS в бюджет проекта).
  • Запуск первой пилотной (неполной) версии проекта на CMS всегда быстрее, чем запуск аналогичной версии на фреймворке. Если проект сложный, а сроки запуска «горят», то лучше либо выпускать «пилот» на CMS, а затем его затратно дорабатывать или параллельно с этим разрабатывать решение на фреймворке, либо расставлять приоритеты между сроками разработки и сложностью проекта (либо отказываться от сложного функционала, либо увеличивать сроки).

Простые проекты проще, быстрее и дешевле делать на коробочных CMS, а сложные проекты эффективнее разрабатывать на фреймворках