Комментарии

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

По моему 5+ летнему опыту две трети усилий по разработке тратятся на не особо нужные хотелки. «хотим тут чтобы футер менял цвет». «хотим чтобы можно было выбирать фото и видео одной кнопкой». «хотим кнопку удаления сущности вот в этом подменю вот этой подсущности» — и все, архитектура не выдерживает, код пачкается, и т.д.

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

Разработка мобильных приложений. Большинство платформ low-code/no-code, таких как Bubble, предоставляют возможности адаптивного пользовательского интерфейса, другие предлагают встроенную поддержку ведущих мобильных OC (iOS и Android). Thunkable – пожалуй, лучший пример low-code/no-code платформы для разработки мобильных приложений.

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

Другие категории платформ нацелены на определенные области или ниши приложений:

— E-commerce и онлайн-магазины: лидирующим примером здесь является Shopify.

— Управление рабочим процессом: отличный пример – Monday.com.

— Приложения ERP (планирование ресурсов предприятия): в качестве интересного примера (также указанного в MQ Gartner) можно привести Zoho. Еще одна важная и впечатляющая платформа для ERP и CRM – это Salesforce.

— Блокчейн и Интернет вещей: Atra.

— Искусственный интеллект: сейчас мы начинаем наблюдать появление таких инструментов, как C3 AI Ex Machina.

Челленджи low-code/no-code

Платформы low-code/no-code имеют множество преимуществ, но в то же время создают определенные трудности и требуют обучения для работы с ними. Многие передовые практики только появляются и относительно незрелы, и следовательно, растет ответственность при их использовании. Что касается традиционного программирования, здесь накоплен огромный опыт, существуют сильные сообщества, а передовые практики задокументированы. Во многих отношениях low code/no-code находится в зачаточном состоянии даже несмотря на то, что разработка на основе моделей существует уже давно (особенно платформы BPM).

Вот некоторые из наиболее серьезных проблем:

1. Необходимость изменения культуры: low-code/no-code требует изменения культуры организации, будь то корпорация или стартап. Изменить культуру для избавления от лишних процессов непросто, это требует схожего видения и одобрения руководства, а также выделения бюджета и полномочий для центра компетенций по цифровой трансформации low-code/no-code.

2. Время и усилия на изучение платформ: low-code/no-code увеличивает скорость и производительность, но инструменты и платформы нетривиальны, и для развития необходимого уровня владения ими требуется время. Это один из наиболее неправильно понимаемых аспектов low-code/no-code. Сложные программные конструкции, такие как вложенные циклы, не так уж и просты на любой платформе.

3. Необходимость использования нескольких платформ: одни платформы имеют более полную функциональность, другие нет. Unqork и Bubble, например, предназначены для любого сценария использования и поэтому предлагают множество вариантов интеграции с корпоративными системами. Кроме того, они могут взять много полезного из других компонентов, специализирующихся в определенных областях; например, Bubble вместе, скажем, с Parabola или плагином Zapier можно использовать для автоматической интеграции. С возможностями управления данными и интеграциями в Parabola или Zapier работать легче, чем с нативными от Bubble. Существуют и другие плагины или технологические компоненты, дополняющие платформы low-code/no-code: посмотрите, например, список технологических партнеров Unqork или полный список плагинов для Bubble.

4. Недостаточность ресурсов и поддержки сообщества: в мире существуют миллионы, или даже десятки миллионов разработчиков обычных языков программирования, множество онлайн-курсов, а также книги и материалы, доступные для таких языков, как Java или C#, есть множество сообществ и ресурсов для аутсорсинга. Совсем иначе дела обстоят для low-code/no-code, особенно для более новых платформ.

5. Сбивающее с толку ценообразование: корпоративные low-code/no-code платформы, как правило, неоправданно дороги. Платформы для среднего и малого рынка менее затратны, но, как правило, менее масштабируемы. А использование нескольких платформ для создания комплексного решения еще больше усложняет вопросы ценообразования.

Это лишь некоторые из основных проблем. Они ясно дают понять, что low-code/no-code не панацея. Тем не менее, такой подход остается серьезной тенденцией для разработки инновационных решений как для действующих предприятий, так и для стартапов.

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

Gartner дает платформе low-code (LCAP) следующее определение: «Это платформа, которая поддерживает быструю разработку приложений, одноэтапную раскатку, выполнение и управление с использованием декларативных абстракций программирования высокого уровня, таких как языки программирования на основе моделей и метаданных.»

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

Неудивительно, что многие платформы low-code являются платформами управления бизнес-процессами. BPM уже давно поддерживает разработку на основе моделей (Model-driven Development), где нужно нарисовать диаграммы, объясняющие, как должно работать программное обеспечение, прежде чем его создавать. Эта схема похожа на процессный подход BPM, при котором для задания бизнес-процесса необходимо в правильном порядке расположить блоки, представляющие собой подпроцессы. (Самым популярным стандартом отображения процессов, поддерживаемым большинством BPM-платформ, является BPMN). Поэтому процессно-ориентированные решения достаточно популярны. Примерами low-code/no-code платформ для BPM являются Appian, Pega, Outsystems.

Но существуют и другие примеры под эгидой low-code/no-code:

Веб-платформы для использования предприятиями любого размера. Ведущими конкурентами являются WordPress, Wix, Squarespace и WebFlow.

Платформы управления базами данных, начиная от таких, как Mendix, и заканчивая такими, как Airtable. Существуют также low-code/no-code платформы баз данных NoSQL, например, KgBase, предназначенная для построения графов знаний.

Платформы с автоматизированной интеграцией, среди которых несколько новых и интересных, например, Zapier, Parabola и Integromat. С помощью них вы можете быстро разрабатывать мощные и сложные схемы интеграций. Вот пример рабочего процесса Parabola, в котором данные извлекаются из API, с ними выполняются некоторые действия, а затем данные отправляются в другой API. Процесс можно запускать по запросу, по расписанию или через вебхуки.

Все мы в последнее время довольно много слышим о платформах low-code/no-code. Платформы без кода обещают сделать разработку программного обеспечения столь же простой, как использование Word’а или PowerPoint’а, чтобы обычный бизнес-пользователь смог продвигать проекты без дополнительных затрат (денег и времени) на команду инженеров. В отличие от платформ без кода, low-code по-прежнему требует определенных навыков программирования, однако обещает ускорить разработку программного обеспечения, позволяя разработчикам работать с предварительно написанными компонентами кода.

Согласно Gartner, к 2024 году 65% разработанных приложений будут относиться к low-code.

Еще в 2017 году я участвовал в сравнительном тестировании производительности традиционной разработки (с использованием Java) и проектом low-code/no-code, основанном на моделях. Результаты были впечатляющими: при использовании метода low-code/no-code производительность увеличивалась в 5-7 раз. Опрос, проведенный компанией No-Code Census в 2020 году, показал прирост производительности в 4,6 раза по сравнению с традиционным программированием.
Low-code/no-code: Фрагментация платформы

Область low-code/no-code довольна сложна и включает в себя многочисленные решения, платформы и субрынки. Например, существуют субрынки, ориентированные на крупные, средние и малые предприятия. Корпоративные платформы low-code/no-code обеспечивают высокую масштабируемость, производительность, безопасность и интеграцию с приложениями предприятия. Они, как правило, дороже остальных. Ниже представлен Магический Квадрант Gartner для корпоративных low-code платформ:

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

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

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

Так, Bit решает важную проблему современного веб-конструирования, предоставляя изолированную среду для проектирования, разработки и тестирования компонентов Angular. Nx, в свою очередь, предлагает эффективные генераторы для упрощенного создания компонентов, сервисов и модулей Angular, в то время как Angular DevTools позволяет отлаживать и профилировать приложения Angular в браузере.

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

Так, Bit решает важную проблему современного веб-конструирования, предоставляя изолированную среду для проектирования, разработки и тестирования компонентов Angular. Nx, в свою очередь, предлагает эффективные генераторы для упрощенного создания компонентов, сервисов и модулей Angular, в то время как Angular DevTools позволяет отлаживать и профилировать приложения Angular в браузере.

Исключительно в свете полемического задора отмечу, что скрам может быть легко разделим с agile, так как не скрам наследует философию agile, а наоборот. Исторически agile возник как квинтэссенция XP (eXtreme Programming), Scrum, FDD (Feature Driven Development – разработка, управляемая функциональностью), DSDM (Dynamic Systems Development Method – Метод разработки динамических систем) и Crystal – именно авторы и последователи этих методик (+ еще несколько независимых, но близких по духу людей) собрались и договорились о принципах, которые и выразили в agile-манифесте.

Я вообще не большой фанат agile-манифеста. Возможно, в 2001 он и звучал как “вызов системе”, но сегодня… от него может даже больше вреда, чем пользы. Мне кажется, что самая большая заслуга манифеста – это как раз то, что авторы разных методик смогли собраться и создать этот зонтичный бренд, что позволило продвинуть концепцию, несмотря на внутренние войны сторонников разных веток.

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

Вы описали скрам для скрам-мастеров. Но не для бизнеса, не для инженеров, не для PO. Оперируя абстракциями «ценность», «доверие» и т.д. вы описываете концептуальную полноту философии, которая неразделима с agile, наследуя все.

Т.е. чтобы построить то, что вы описываете нужно проанализировать и перестроить все бизнес-процессы под принципы agile, постоянно заниматься их тюнингом, а все сотрудники компании должны поддерживать культуру agile и тем более не саботировать. Топ-менеджмент, средний менеджмент — все должны следовать общей культуре. И вот в этой ситуации получится скрам-комнада. Часто видим такие компании?)

Скрам, как фреймворк итеративной разработки — это лишь способ выстроить процесс взаимодействия разработки с бизнесом. Для большинства на этом все закончится. Меньшинство вспомнит про «гибкость» выкинет дейлики и будет успешно работать по схеме планинг-груминг-ретро, адаптируя свою процессы под бизнес, которому глубоко пофигу на agile. А скрам для большинства: это щит от бизнеса.

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

Но, спасибо за философию. Это полезно.

К сожалению, должен признать, что ваша точка зрения не то, чтобы справедлива (ваши выводы неверны), но она понятна и более того небезосновательна. Это существенный недостаток гайда: он слишком сфокусирован на философии. Настолько, что именно Руководством его назвать сложно, хотя я думаю любой, кому всё-таки доводилось участвовать в работающем Скраме, согласится, что в гайде написаны справедливые вещи: и про прозрачность-инспекцию-адаптацию, и про их связь с событиями, и даже про — не побоюсь это слова — ценности. Хотя я отлично понимаю, что абсолютное большинство людей, услышав словосочетание «ценности скрам», тут же подумают: «ну вот, сейчас опять будут с**ть в ищи». Так что я могу согласиться, что гайд слащавый, но суть скрама и взаимосвязи в нем там описаны действительно классно. Ну а эта статья и видео как раз являются кратким содержанием гайда.

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

Короче, скрам — это за всё хорошее, против всего плохого, и ничего конкретного.

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

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

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

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

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

ASP.NET состоит из нескольких ключевых компонентов, которые помогают разработчикам создавать мощные и масштабируемые веб-приложения. Рассмотрим основные из них:

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

Razor Pages — это упрощённый подход к созданию веб-приложений на ASP.NET. Он позволяет разработчикам создавать страницы с минимальным количеством кода и конфигурации. Razor Pages идеально подходят для небольших приложений и прототипов, где требуется быстрое создание и развертывание.

Razor Pages используют синтаксис Razor, который позволяет смешивать HTML и C# код в одном файле. Это упрощает разработку и делает код более читабельным. Razor Pages также поддерживают привязку данных и валидацию, что упрощает работу с формами и пользовательскими вводами.

ASP.NET Web API позволяет создавать HTTP-сервисы, которые могут быть использованы различными клиентами, включая браузеры и мобильные приложения. Web API поддерживает стандартные HTTP-методы (GET, POST, PUT, DELETE) и позволяет легко создавать RESTful сервисы.

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

SignalR — это библиотека для ASP.NET, которая упрощает добавление функциональности в реальном времени в ваши приложения. Она позволяет создавать приложения, которые могут мгновенно обновлять данные на клиенте без необходимости обновления страницы. SignalR поддерживает WebSockets и другие транспортные протоколы, что делает его гибким и производительным решением для приложений в реальном времени.

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

А какие основные компоненты ASP.NET?

Я довольно плохо знаком с веб и в частности JavaScript. Однако работаю с .Net постоянно. Также я полагаю, что знать JavaScript и всякие разные фреймворки на нем, которых сейчас как грязи это стильно, модно и молодежно. Но чтобы пощупать очередную либу обычно нужно кучу всякого устанавливать, чтобы она впринципе заработала.

Обычно требуется сервер (через node.js), npm, и что-то типа Webpack-а (Для работы Less или какого-нибудь шаблонизатора/минификатора). Я немного ковырял ASP.NET (Не Core, а обычный) и примерно представляю как быть с серверной частью, но фронтенд для меня темный лес.

Пробема в том, что технологии в вебе обычно не ориентируются на ASP.NET, а больше на node.js, php и прочий мейнстрим. И примеры в документации тоже всегда на этом всем базируются, и для человека непосвященного не так то быстро получается это все с нуля настроить под ASP.NET.

— npm — Нужен для установки различных библиотек в JavaScript, требуется повсеместно.
— Webpack — Нужен если JavaScript и другой контент нужно упаковывать, минифицировать, использовать Less вместо ванильного CSS, шаблонизаторы HTML, использовать транспиляторы JavaScript и тому подобное.
— TypeScript — Его можно использовать как транспайлер из новых версий JavaScript в старые. Также можно использовать сам язык TypeScript. Два в одном получается, плюс грех не использовать так как в Visual Studio сделана неплохая его поддержка.

Умея быстро создать такое приложение дальше уже можно смело изучать любые веб-технологии (включая сам npm, Webpack и TypeScript), при этом сервер будет на родном дотнете.

На данный момент в ASP.NET и так уже встроены механизмы похожие на те, что есть в Webpack, а также студия из коробки (Во всяком случае 2017-ая) работает с TypeScript и компилирует его автоматически, если создать файл конфига для компилятора TypeScript-а.
Но все эти вещи поддерживаются разработчиками ASP.NET, а не веб-сообществом.

Казалось бы, если фреймворк — это всего лишь набор библиотек, а CMS — это уже почти сайт, то к чему вообще этот глупый выбор? Но ведь если бы всё было так просто, то, очевидно, не было бы этой статьи и ты её не читал бы.

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

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

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

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

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

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

Буду подводить итоги.

Плюсы CMS:

Скорость. Шаблонное решение можно создать очень быстро.

Готовая админка. На многих популярных CMS достаточно удобная и понятная админка

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

Минусы CMS

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

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

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

Сайт на CMS всегда уступает в производительности хорошо написанному сайту на фреймворке.

Плюсы фреймворка

Гибкость.Можно реализовать любую задумку без «войны» с движком

Производительность. Повторю: сайт на CMS всегда уступает в производительности хорошо написанному сайту на фреймворке

Минусы фреймворка

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

Отсутствие административной части. Раздел редактирования сайта нужно писать самому, а это, считай, ещё целый сайт.

Время. Разработка занимает больше времени, чем разработка с помощью CMS

Минусы решаются переиспользованием ранее написанного кода.

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

Когда лучше подойдёт CMS

Шаблонное решение, которое покрывается возможностями CMS

Быстрое, временное или недолгосрочное решение

Для клиентов с небольшими бюджетами

Сайт ради сайта. Клиенту просто нужен сайт и он не знает зачем

Недостаточно опыта у разработчка

Когда лучше использовать фреймворк

Нетиповой нешаблонный проект

Активно изменяющийся или подстраивающийся под тренды проект Достаточно опыта, чтобы написать качественно на фремворке

Как мы видим CMS не проиграла это сравнение в одни ворота.

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

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

Казалось бы, если фреймворк — это всего лишь набор библиотек, а CMS — это уже почти сайт, то к чему вообще этот глупый выбор? Но ведь если бы всё было так просто, то, очевидно, не было бы этой статьи и ты её не читал бы.

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

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

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

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

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

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

Буду подводить итоги.

Плюсы CMS:

Скорость. Шаблонное решение можно создать очень быстро.

Готовая админка. На многих популярных CMS достаточно удобная и понятная админка

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

Минусы CMS

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

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

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

Сайт на CMS всегда уступает в производительности хорошо написанному сайту на фреймворке.

Плюсы фреймворка

Гибкость.Можно реализовать любую задумку без «войны» с движком

Производительность. Повторю: сайт на CMS всегда уступает в производительности хорошо написанному сайту на фреймворке

Минусы фреймворка

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

Отсутствие административной части. Раздел редактирования сайта нужно писать самому, а это, считай, ещё целый сайт.

Время. Разработка занимает больше времени, чем разработка с помощью CMS

Минусы решаются переиспользованием ранее написанного кода.

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

Когда лучше подойдёт CMS

Шаблонное решение, которое покрывается возможностями CMS

Быстрое, временное или недолгосрочное решение

Для клиентов с небольшими бюджетами

Сайт ради сайта. Клиенту просто нужен сайт и он не знает зачем

Недостаточно опыта у разработчка

Когда лучше использовать фреймворк

Нетиповой нешаблонный проект

Активно изменяющийся или подстраивающийся под тренды проект Достаточно опыта, чтобы написать качественно на фремворке

Как мы видим CMS не проиграла это сравнение в одни ворота.

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

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

Выбор между фреймворком и CMS зависит от конкретных потребностей проекта.

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

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

При выборе также стоит учитывать опыт команды разработчиков и бюджет проекта.

Выбор между фреймворком и CMS зависит от конкретных потребностей проекта.

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

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

При выборе также стоит учитывать опыт команды разработчиков и бюджет проекта.