в чем разница между фреймворком и cms

CMS или фреймворк — что лучше?

Всем привет 🙂

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

Сегодня пришло время поставить логическую точку и ответить на вопрос, интересующий многих разработчиков и тех, кто желает иметь собственный сайт (заказчиков), что же в итоге лучше: CMS или фреймворк?

Типы движков – это понятия универсальные, не зависящие от того, на каком языке создаётся сайт.

PHP, Ruby, Python – на всех этих языках есть фреймворки и CMS, на которых, в свою очередь, разрабатываются сайты.

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

Конкретно о своём опыте, и о том, к чему пришёл в процессе, я расскажу в конце статьи.

А сейчас же мы поговорим, какой тип движка сайта лучше выбирать для разработки ресурса с точки зрения разработчика и заказчика: фреймворк vs CMS.

Фреймворк или CMS – что лучше для разработчика?

Для начала, я тезисно приведу основные особенности каждого типа движка, чтобы их сравнение было максимально объективным.

Начнём с любимых инструментов новичков, которые только задумываются над тем, с чего начать программировать – с CMS.

Что сулит работа с CMS для программиста?

Подробному обзору плюсов и минусов CMS уже была освящена отдельная статья по приведённой ссылке.

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

Итак, что хорошего в CMS для разработчика?

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

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

И немаловажным фактором является большое количество заказов на CMS, особенно на фрилансе, что показал мой недавний обзор востребованности PHP CMS и фреймворков на рынке труда.

А какие же минусы несёт использование CMS для программиста?

Два первых недостатка ведут к тому, что на базе CMS очень сложно запустить высоконагруженный ресурс. По этой же причине, а также из-за большой конкуренции, заработать на CMS серьёзные деньги вряд ли получится.

Исключением могут стать только «монстры индустрии» Magento и Drupal, у которых высокий порог входа, отсеивающий многих «ламеров» и достаточно хороший потенциал для создания highload сайтов, что обеспечивает соответствующих специалистов работой в серьёзных компаниях с серьёзной з/п.

И ещё… Указанные продукты – это не просто CMS, а CMS/CMF (Content Management Framework), чем объясняются многие их особенности.

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

Таким образом, мы плавно подошли к обсуждению особенностей фреймворков, работа с которыми очень отличается от передвижения разных блоков и менюшек в админке ЦМСок.

Достоинства и недостатки frameworks для разработчика

Если вы не в курсе, что такое фреймворк, и с чем его едят, то рекомендую прочитать статью по ссылке.

И так уж сложилось, что, поскольку, фреймворк – инструмент исключительно для профессионалов, то он обладает особенностями, противоположными «фишкам» CMS для разработчика.

Итак, какая же разница между фреймворком и CMS для разработчика?

К плюсам фреймворка относятся следующие:

Данные особенности фреймворков дают возможность программистам создавать на их базе сложные проекты, вплоть до highload и даже CMS.

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

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

Минусы framework для разработчиков следующие:

Более подробно о достоинствах и недостатков фреймворков вы можете прочитать в статье по указанной ссылке.

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

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

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

Ну, а теперь пришло время выяснить, что лучше: CMS или фреймворк для другой стороны процесса разработки сайтов – для заказчиков.

Фреймворк или CMS – что выбрать заказчику?

На самом деле, если вы являетесь заказчиком, то вам совершенно не обязательно ломать себе голову данным выбором.

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

Поэтому вам могут предложить сделать лендинг на Drupal или Интернет-магазин на 100 000+ товаров на WordPress. Или ещё того хуже – на самописном движке, с кодом которого никто кроме его разработчиков не разберётся, поэтому после прекращения сотрудничества вам попросту придётся переписать сайт заново на другую, более известную платформу.

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

Достоинства и недостатки CMS с точки зрения заказчиков

Итак, первые на очереди снова CMS.

И какие же плюсы использования ЦМСок на сей раз?

Как видите, преимуществ CMS для заказчиков больше, чем для разработчиков, однако, многие из них с оговорками.

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

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

Благодаря такой массе достоинств многие желающие обзавестись сайтом решают, что на CMS они могут создать сайт самостоятельно. Но я не зря выделил слово «типовые», когда говорил, что разработка ресурсов на CMS занимает меньше времени и обходится дешевле.

А определить, является ли требуемый функционал типовым для выбранной вами CMS или нет, вы самостоятельно не можете – это дело сугубо профессионала. Только он сможет вам ответить, есть ли интересующая вас фича «в коробке» у движка или нет.

К примеру, лендинг на WordPress. В случае выбора CMS придётся искать шаблон с соответствующей структурой, устанавливать его и настраивать, что по времени может быть дольше, чем сверстать его с нуля и натянуть на любой фреймворк (либо вообще обойтись без него).

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

Думаю, если подобное предложение поступил разработчику, который никогда до этого не был знаком с WP, он волей-неволей всё равно разработает на нём, т.к. это будет быстрее запуска аналогичного функционала на фрейме.

Мораль сей басни такова – не считайте себя умнее программистов и не тратьте своё время на вникание в премудрости движка. Лучше инвестируйте его в развитие своего бизнеса, а разработку веб-ресурса доверьте профессиональным разработчикам, это их хлеб 🙂

Тем более, что CMS – это ещё не лекарство от всех болезней, для заказчиков у них также есть ряд минусов:

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

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

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

Что это я всё о фреймворках, да о фреймворках… Ах да, я же их фанат 🙂

Но, тем не менее, свои особенности они имеют и для заказчиков. Давайте о них и поговорим.

Особенности фреймворков для заказчиков

Эх, люблю я фреймворки! На данный момент, по крайней мере.

Осталось теперь вас, как заказчиков, убедить в целесообразности их использования.

Итак, что же такого хорошего дают frameworks заказчикам?

Достоинств не много, но они очень весомые. Если ваш проект будет гарантированно HighLoad, то без фреймворка вам не обойтись никак.

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

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

И типичная отмазка CMS-разработчиков «Извините, но это всё, на что способен движок» здесь не прокатит 🙂

Ну а какие же минусы фреймворков для заказчиков существуют?

Минусы, естественно, есть, куда же без них? Все они сводятся к тому, что сайты на фреймворках будут разрабатываться дольше и стоить дороже CMS-ных творений. К тому же, расширять функционал самостоятельно не получится.

Но, это ни в коем случае не значит, что сайты на фреймворках не нужно создавать. Даже наоборот. Вспомните о плюсах framework.

Благодаря данному типу движков вы сможете получить абсолютно уникальный продукт, «handmade», ручную работу, сделанную настоящим профессионалом своего дела 1-в-1 по вашим пожеланиям, который при этом будет невероятно производительным и способным выдерживать большие нагрузки.

Как по мне, то вполне логично, что разработка таких сайтов обходится дороже допиливания CMS, за которое берутся все, кому не лень.

Финальные выводы по поводу выбора CMS или фреймворка

В качестве итога ещё раз повторю то, о чём я сегодня уже писал.

Если вы – разработчик, то для вас не имеет особого значения, что вы в итоге выберете: CMS или фреймворк – обе категории движков помогут вам зарабатывать хорошие деньги.

Так что на Ваш личный выбор должны влиять только эстетические предпочтения – с чем нравится работать, с тем и нужно работать 🙂

А чтобы понять, что больше нравится, в идеале нужно, конечно, поработать и с CMS, и с фреймворками.

И да, как показал недавний обзор востребованности PHP движков на рынке услуг, ссылку на который я уже размещал ранее, на итоговый выбор платформы должны влиять ваши предпочтения в плане места работы.

Если вам больше по душе фриланс, то освоение CMS будет правильным решением. А если нравится работать в команде, то лучше обратить внимание на фреймворки, т.к. они больше котируются в серьёзных IT-компаниях.

Я уже успел поработать с обоими категориями движков, что позволяет мне делать определённые выводы по поводу того, к чему у меня больше всего лежит душа – к фреймворку или CMS.

На данный момент мой выбор – это фреймворк, в частности, Laravel.

Хотя начинал я вообще с OpenCart, по которому нет абсолютно никакой документации: ни англоязычной, ни, тем более, русскоязычной, за исключением редких форумов и блогов, включая этот, где разработчики делятся своими наработками.

Если бы подобный вопрос выбора движка стоял бы передо мной сейчас, я выбрал бы WordPress без колебаний, т.к. он является ТОП-1 по количеству заказов на зарубежном и отечественном фрилансе и по количеству вакансий на сайтах поиска работы.

А это значит, что знания движка обеспечат вас работой в любом случае, т.к. он востребован везде и всеми.

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

Только, если вы не очень уверены в своих знаниях, не стоит браться за что-то серьёзное, типа Drupal, Magento или 1С-Битрикс. Попробуйте поработать с WordPress или Joomla, т.к. по ним достаточно много заказов, примеров кода в сети и большие сообщества, где помогут разобраться с вашими вопросами.

А уже потом, когда освоитесь, и даже разработка сайта с нуля на выбранной платформе будет не в тягость, можете задуматься о повышении своего уровня и з/п, соответственно.

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

Ну, и финальной точкой всего этого будут высокооплачиваемые фриланс-заказы или работа в серьёзной компании с серьёзной з/п.

По крайне мере, такой путь проходил я и ни о чём не жалею. За исключение того, что начал его слишком поздно…

Ну а вы решайте сами – прислушиваться к моему опыту или нет. Кроме того, что фактор везения ещё никто не отменял. Может, вы и без особых знаний будете получать дорогостоящие заказы и вакансии в серьёзных фирмах, перескочив таким образом несколько ступеней планомерного развития вас, как разработчика.

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

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

Так что лучше сразу обратись за помощью к профессионалам.

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

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

Не говоря уже о том, чтобы всё сделать самостоятельно. Установкой пары-тройки плагинов здесь явно не обойтись.

Да, разработка сайта на фреймворке обойдется дороже, чем на CMS, и будет сопряжена с некоторыми рисками в плане сложности поддержки проекта при потере связи с начальным разработчиком. Но, поверьте, оно того будет стоить.

Поэтому если вы считаете, что ваш сайт должен быть разработан на CMS за 600$, а разработчик говорит, что его нужно создавать на фреймворке, и цена будет 2000$, то не нужно сразу считать, что вас пытаются обмануть.

В таком случае лучше обратиться к нескольким разработчикам и принять решение, основываясь на мнении большинства.

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

На это всё. Надеюсь, статья была вам полезной и помогла определиться с тем, что же вам ближе – CMS или фреймворк.

Пишите о ваших мыслях и делитесь опытом в комментариях.

Уверен, что ваша информация будет для многих полезной.

P.S.: если вам нужен сайт либо необходимо внести правки на существующий, но для этого нет времени и желания, могу предложить свои услуги.

Более 5 лет опыта профессиональной разработки сайтов. Работа с PHP, OpenCart, WordPress, Laravel, Yii, MySQL, PostgreSQL, JavaScript, React, Angular и другими технологиями web-разработки.

Опыт разработки проектов различного уровня: лендинги, корпоративные сайты, Интернет-магазины, CRM, порталы. В том числе поддержка и разработка HighLoad проектов. Присылайте ваши заявки на email cccpblogcom@gmail.com.

И с друзьями не забудьте поделиться 😉

5 комментариев к статье «CMS или фреймворк — что лучше?»

Спасибо за полезную статью. Интересная тема, выбор движка сайта волнует многих. Заказчиков в том числе: нельзя целиком доверяться воле разработчика, нужно иметь хотя бы общее представление, на чём будет создан сайт.

Долго работал на разных cms и пришёл в решению перейти на фреймворк.
Пока выбрал и изучаю laravel.
Задача создать сайт с нужной мне функциональностью, а не с той, что удобна работающим на cms товарищам.
Если честно, то меня достала корявость решений, которые получаются методом допиливания и допинывания cms дополнительными модулям!
С годами пришёл к решению перейти на свои разработки и прямое изучение языков програмирования.
Но к этому реально прийти только методом проб и ошибок.
Автор прав, когда говорит нам об этом.
Спксибо за статью.
Она ещё раз убедила меня идти своей тернистой дорогой.

Спасибо Вам за отзыв 🙂 Приятно ощущать, что твой труд был кому-то полезен.

Laravel — классная вещь, которая меня пока что полностью устраивает и не вызвала желание уходить с неё. Но, на самом деле, хочу сказать, что в случае Laravel, как и с CMS, большую роль играет человеческий фактор. Если в ЦМС-ках он проявляется в корявых модулях, то у фреймворков это пакеты, на которые также забивают их авторы в плане развития и адаптации к новым версиям фрейма.

У фреймворков, кстати, дела в плане доработок чужого кода обстоят ещё страшнее, чем у CMS, благодаря возможности создания своей структуры кода. Я дорабатывал уже несколько сторонних проектов на Laravel, поэтому насмотрелся)

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

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

Спасибо за статью! Как я всё это понимаю! Была ситуация когда принял заказ на не совсем стандартный проэкт. Но т.з. начальное очень хорошо ложилось на возможности одной из CMS конечно же с довольно большими подпиливаниями, но тем не менее выбрал её так как нужно побыстрее было.

Начал создавать, показывать промежуточные варианты чтобы не увлечься и не уйти в другую сторону от требуемого функционала. И тут то посыпалась куча проблем: незначительные «хотелки» типа вывести вот это, скрыть это и т.п. привели к тому что мне пришлось переписать базовые компоненты на свой лад, так как некоторые хотелки даже базово не заложены в системе и пришлось дёргать нужные данные чуть ли не с ядра разными способами чтобы хотя бы ядро не менять.

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

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

В общем в своё время намучался.

Теперь вот опять появилась задача создать нечто не стандартное, но правда теперь и заказчиком и исполнителём являюсь я сам. И вот сижу голову ломаю: на cms писать и бояться что обламаюсь с определёнными специфическими функциями или потрать больше времени и написать на фреймворке. Хотя если cms при дальнейшем развитии будет противоречить некоторому функционалу, то времени больше потратишь.

Даже не знаю что лучше выбрать?

Ого 🙂 Спасибо Вам даже не за комментарий, а за целый рассказ. И особенно за то, что не поленились и не постеснялись поделиться своим опытом и данной историей.

Что касается сути… Я бы посоветовал не спешить с выводами и составить для себя подробное ТЗ: что ожидается от проекта, какие функции он должен выполнять, и насколько функционала CMS для этого хватит.

Знаю по себе, что данный этап — самый важный. Чем чётче будет представление, что нужно сделать, тем быстрее пройдёт процесс разработки и подберётся инструмент.

Взять к примеру данный сайт. Цель изначально стояла организовать стандартный блог без каких-либо наворотов и WordPress для этого подходил идеально. По всем своим хотелкам, по которым были сомнения, можно ли это сделать безболезненно в WordPress, я подготовился и погуглил заранее.

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

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

Если что-то будет больно сделать на CMS или помимо разработки самого ресурса будет стоять ещё и задача скилапа, то лучше сразу брать фреймворк.

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

А какого плана проект планируется? Возможно, смогу что-то подсказать конкретное. Да и просто Ваши мысли по поводу выбора конкретной платформы было бы интересно услышать 🙂

Источник