Cms или фреймворк что лучше
CMS или Фреймворк? Что выбрать?
Что выбрать для разработки фреймворк или CMS? Чем они вообще отличаются и какие преимущества и недостатки у фреймвоков и CMS.
CMS (Content Management System, система управления контентом)
CMS(ЦМС) – это, по сути, уже готовый сайт, который нужно донастроить под свои нужды.
CMS значительно ускоряет разработку простого шаблонного сайта. У сайта сразу готова админка и её не надо писать отдельно, в отличии от разработки на фреймворке. Однако это скорость создания сайта достигается за счёт шаблонности, ограниченности или излишней универсальности CMS.
При желании расширить функционал, добавить что-то эдакое, возможно, придётся прямо воевать с CMS или идти на какие-то компромиссы. В случае с фреймворком, таких проблем нет. Да разработку уходит больше времени, однако любая задумка осуществима без каких-либо костылей.
В фреймворках зачастую только самый необходимые функции и хороший, отлаженный, отрефакторенный код. В CMS, особенно, если она предполагает сторонние модули, можно встретить дикий ад в коде и даже вредоносный код, который может, например добавлять ссылки на левые сайты в твой проект.
Ведя разработку с помощью фреймворка, ты сам строишь взаимодействие пользователя с функциями и данными и сам решаешь как это будет выводиться в браузер. В CMS это всё решили за тебя. Вероятно, это и неплохо, ведь если у разработчика недостаточно опыта, то с фреймворком или чистым языком можно наворотить такого, что в итоге CMS окажется очень хорошим вариантом.
Используя CMS, мы привязываемся к структуре, созданной разработчиками, но в шаблонных решениях экономим время, а в нешаблонных, зачастую, прозябаем на форумах в поисках ответов на «как так».
А Framework даёт полную свободу действий. За нас написали основу, фундамент, а дальше бери и твори. Но для качественной разработки на фреймворке необходимо обладать достаточным уровнем, чтобы не создавать откровенной непотребщины или, что ещё хуже, дырявого продукта.
Буду подводить итоги.
Скорость. Шаблонное решение можно создать очень быстро.
Готовая админка. На многих популярных CMS достаточно удобная и понятная админка
Простота разработки. По большому счёту, чтобы создать простецкий сайт и навыками программирования и вёрстки обладать не обязательно.
Ограниченный функционал. Шаг влево, шаг вправо карается расстрелом. Функционал допилить возможно всегда, но, вероятно, это будет просто межгалактический костыль.
Избыточность. В погоне за универсальностью, разработчики CMS, чтобы угодить всем, закладывают столько функций, что скорее всего для одного проекта всё это не нужно. В итоге получаем много неиспользуемого кода.
Сложное ядро. Порой, чтобы чуть поправить или видоизменить какую-то часть сайта, приходится разбираться с устройством системы.
Сайт на CMS всегда уступает в производительности хорошо написанному сайту на фреймворке.
Сайт на CMS, фреймворке или собственная разработка — что лучше?
Егор Косолапов из Uplab сравнивает разные варианты: разработку на чистых языках программирования, фреймворках, самописных и массовых CMS.
Чего хочет заказчик, когда обращается в агентство? Чтобы ему сделали сайт. Каким образом — вопрос второстепенный. Главное, чтобы в бюджет уложились, всё работало как задумано, а идеально — ещё лучше. Как задумано — значит удобно для пользователей, легко в управлении и безопасно.
У подрядчика в ответ на запрос клиента масса предложений. Рассмотрим, в каких случаях есть смысл создавать сайт на массовой CMS, а когда лучше пойти по пути уникальности.
Все сайты делятся на два типа
Сайт состоит из внешней и внутренней части. Внешняя — это дизайн и контент, внутренняя — это база данных и административная панель. При разработке сайта на CMS необходимо создать только внешнюю часть — дизайн, сверстать его и «натянуть на движок». А при самостоятельной разработке придётся создавать и всю начинку.
Как продвинуть банк в регионах?
Основная проблема — перегретый аукцион. Но если грамотно выбрать соцсеть, формат и настройки таргетинга, всё получится.
Промежуточный вариант, который совмещает оба метода, — самописные системы управления контентом. В этом случае сначала с нуля создаётся скелет функций, а затем решение становится типовым, и уже на его основе создаются похожие сайты. Как правило, самописные CMS используются для решения довольно узких задач.
Проведём аналогию с автомобилем
По сути, мы видим переход от штучного продукта к рыночному, от индивидуального — к массовому производству. Причём у каждого варианта свои преимущества и недостатки.
Массовая CMS
Системы управления контентом, которые созданы компаниями-разработчиками, бывают как платными, так и бесплатными.
Бесплатные CMS ограничены по набору функций и технической поддержке, обычно используются для создания личных или небольших корпоративных сайтов. Нередко имеют проблемы с безопасностью, поэтому для создания серьёзных проектов не рассматриваются.
Коммерческие CMS — это мощные, универсальные системы для разработки разных типов сайтов с защитой и техподдержкой.
Когда подходит
На массовой CMS можно создать все основные виды сайтов. Большинство систем состоит из модулей. Наборы таких модулей составляют редакции сайтов: корпоративный сайт, визитка, каталог, интернет-магазин, блог, портал и так далее. Это самый распространённый и простой способ сайтостроения.
Преимущества
У готовых платформ, как правило, есть интерфейс прикладного программирования, который содержит много классов, структур, функций и прочих элементов. Всё это позволяет интегрировать ресурс с внешними программными сервисами.
Самописная CMS
Далее рассмотрим системы управления контентом, разработанные отдельным программистом или студией. Это аналоги массовых CMS, но имеют небольшое распространение, даже если продаются. Могут создаваться на заказ.
Если массовые CMS — это универсальные решения, то самописные версии — продукт индивидуальной разработки. Обычно заточены под решение конкретных задач.
Когда подходит
Самописные CMS чаще используют для специфических проектов, когда требуется повышенный уровень безопасности, гибкость или, наоборот, простота в работе. Примером могут служить движки, разработанные для онлайн-СМИ. Они лишены громоздкости массовых систем и при этом могут обладать функциями управления контентом, которых нет в обычных движках.
Такие CMS очень кастомизированные. Как правило, обладают специальным интерфейсом, который удобен для редакторской работы. В этом случае переделка обычной CMS обошлась бы дороже и велась бы дольше, нежели собственная разработка.
Преимущества
Недостатки
Разработка на фреймворках
В переводе с английского framework — каркас, остов, структура. В разработке это готовая надстройка над «чистым» языком программирования. Фреймворк выполняет две задачи: задаёт архитектуру и позволяет подключать дополнительные модули и пакеты, за счёт чего можно расширять функциональность проекта.
Фреймворк — это набор отлаженного кода для решения конкретных задач, которые чаще всего стоят перед разработчиками. Если при разработке на CMS вы отрезаете все лишнее, то здесь всё наоборот: «лепите» сами из готовых блоков. Во многих случаях такой подход является более эффективным и оправданным.
На основе фреймворков можно разработать отдельное веб-приложение, сайт и даже CMS. Фреймворки существуют для всех языков программирования, бывают самописными и студийными. Наиболее популярные представители: Yii, Zend Framework, Symfony2, Laravel, Phalcon, Codeigniter, Kohana.
Когда подходит
Разработка на фреймворках сложнее, чем на CMS, и требует высокой квалификации как от разработчиков, так и от заказчика. Необходимо подобрать специалиста, оценить его опыт и чётко поставить перед ним задачи. Гибкость разработки на фреймворках открывает массу возможностей, но между тем приносит определённые сложности.
Преимущества
Недостатки
Собственная разработка
Под собственной разработкой понимается создание сайтов на языках программирования, например, на чистом HTML или PHP. При этом вся функциональность прорабатывается с нуля.
Когда подходит
Преимущества
Недостатки
Чтобы владеть чем-то уникальным, нужно вложить много ресурсов. Без команды опытных программистов — никуда.
Идеально, если вы готовы держать собственный штат разработчиков, которые в любой момент смогут исправить ошибку, доработать функцию или внедрить новую.
Хорошо, если у вас есть бюджет на агентство. Однако в последнем случае процесс становится не столь гибким. К тому же агентств, которые готовы взяться за создание «велосипеда», на рынке не так много.
Лидеры рунета всё делают сами
В первую очередь — на цели проекта и ваши возможности. Давайте обратимся к опыту рынка. По данным Data Insight, в основе более чем половины крупных интернет-магазинов — собственная разработка.
Похожая ситуация с крупнейшими сайтами рунета — из топ-100 подавляющее большинство работает либо на самописных CMS, либо разработаны на фреймворках или языках программирования.
Лидеры рынка — это всегда высоконагруженные, нестандартные проекты с уникальной начинкой. Ещё один важный нюанс: большинству крупных сайтов уже много лет, и на момент их создания не было достаточно продвинутых массовых CMS.
Но это не значит, что массовые CMS проигрывают
Во-первых, подавляющее большинство сайтов — а их миллионы — всё же работают на CMS. Во-вторых, ещё недавно собственная CMS была у каждой студии. Даже мы в Uplab создавали собственную CMS, но по ряду рациональных причин перешли на Битрикс.
Мы уверены, что сделали верный выбор. Поддержка собственной CMS отнимала много сил, а результат не всегда радовал. Битрикс продолжает набирать обороты и сейчас занимает верхние строчки в рейтинге CMS Magazine.
Какой бы метод вы ни выбрали, делайте это осознанно, тщательно оценив риски, сроки и бюджет.
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 или помимо разработки самого ресурса будет стоять ещё и задача скилапа, то лучше сразу брать фреймворк.
А вообще, когда заказчиком и исполнителем является один и тот же человек, им всегда намного проще договориться 🙂 На крайнийи случай хотелку всегда можно либо отменить либо сделать её аналог стандартными средствами.
А какого плана проект планируется? Возможно, смогу что-то подсказать конкретное. Да и просто Ваши мысли по поводу выбора конкретной платформы было бы интересно услышать 🙂