Заголовок статьи – одновременно и вопрос и утверждение, а на место слова «Joomla», скорее всего, можно поставить почти любой цифровой продукт. Но в ходе размышлений попробуем всё-таки это место найти и вопросительный знак убрать. В статье отражён сугубо авторский, субъективный взгляд, который не претендует на отражение всей полноты мироздания.
Некое введение
У разных авторов, писавших о вайбкодинге, я встречал мысли, с которыми согласен:
ИИ – это не слагаемое, это множитель. Если в ваших процессах есть компетенции, понимание того, что на входе и каков должен быть осязаемый результат, то ИИ умножит это в 3-5-10 и так далее раз, в зависимости от вида работы и уровня вашего опыта. Если же в вашей работе есть некая доля хаоса, то она тоже будет умножена примерно на этот же коэффициент.
Как было до ИИ
Поскольку я с ИИ столкнулся со стороны веб-разработки (магазины, интеграции с внешними системами и вот это вот всё), то наглядный пример будет из этой сферы. Собирательный образ: у веб-разработчиков раньше был почти обязательный этап профессиональной эволюции - написать свой фреймворк или свою CMS. Думаю, в других технологических стеках было примерно то же самое.
Сначала ты пишешь небольшой бложек по видео-урокам, с виду всё получается. Потом ты встречаешься с проблемами, которых в видео-курсе не было и начинаешь искать способы решения. То тебе надо сделать свой мини-пакет для подключения к базе, то сделать медиа-менеджер для загрузки и выбора картинок, то связанные выпадающие списки и т.д. и т.п.
Всё это писать самому было настолько же глупо, насколько необходимо с точки зрения личностного и профессионального роста. Не попробовав создать большую сложную систему с запутанными взаимосвязями внутри, никогда не поймёшь способен ли ты на это (1) в одиночку (2) и нужно ли это кому-нибудь (3). Получив собственный опыт, разработчик выбирал уже какой-нибудь движок и с ним работал.
Joomla, как и любой программный продукт является слепком опыта многих и многих людей, которые применяли её в самых разных ситуациях, решали самые обычные и самые не обычные задачи, находили и исправляли настолько редкие баги, что мало кто додумается в это место залезть и сделать так же. Но если ещё один человек додумается, то он будет приятно удивлён тем, что кто-то уже сделал хорошо и там всё работает. А скорее всего даже и не заметит каких-то особенностей, потому что ведь всё работает.
На мой взгляд, выбор фреймворка, CMS разработчиком зависит от определённого типа мышления. Люди со схожим образом мышления и подходом к разработке объединяются и создают продукт: CMS (библиотеку и иже). CMS наследует и впитывает этот тип мышления, неся в себе черты своих создателей. Разработчикам важно не только то, что задача бизнеса в целом решена, но и то как она решена. Каким-то интуитивным образом я выбрал в своё время Joomla и работаю с ней до сих пор.
Подвести черту под вышесказанным можно таким образом: одноразовые фреймворки или CMS возникали как этап чьей-то профессиональной эволюции или действительно там, где клиент полностью оплачивал кастомное решение. Я сознательно сильно упрощаю и понимаю, что есть множество исключений, включая «unpaid Open Source developer Вася из Сургута, который 20 лет поддерживает библиотеку» из мемов про современную инфраструктуру интернет-проектов.
Эпоха ИИ и вайбкодинга. Как стало.
С появлением ИИ в моей жизни у меня стали регулярно возникать эмоциональные качели: то мне кажется, что всё изменилось не на 180 и не на 360, а на все 720 градусов. А то кажется, что всё на самом деле осталось тем же самым: те же яйца, только в профиль, ну и наклеечку «AI First» на некоторые яйца наклеили.
Приведу ряд наблюдений и тезисов, которые я встречаю как в собственной работе, так и в статьях и постах других людей. От этого кажется, что они уже являются очевидными, но иногда даже очевидные вещи стоит проговаривать:
- С помощью ИИ стало возможным проворачивать огромные объёмы работы за меньшее время.
- Для достижения хорошего результата нужно дать ИИ хороший образец и грамотно описать то, что ты хочешь
- Из-за ИИ становится не так важно знать конкретный прикладной технологический стек (синтаксисы языков, особенности библиотек и т.д.), но большее значение начинает приобретать:
- знание архитектуры, паттернов,
- умение как минимум видеть всю систему в целом, границы отдельных её составляющих,
- умение построить и отладить эту систему,
- умение мысленно выйти за рамки только разработки и понимать причины и следствия, которые работа как разработчика будет иметь в смежных сферах
- Возник вал новых продуктов: у тех, кто раньше не мог программировать – исчез барьер и они стали. Каждый может написать свой фреймворк, CMS и что угодно.
- С помощью ИИ часть клиентов стали автоматизировать свои процессы самостоятельно.
- Из-за ИИ меняется модель потребления контента – мы читаем выжимки в чатах, а потом уже лезем на сайт-источник
- Основным потребителем контента в интернете уже давно стали боты, с появлением ИИ добавились ИИ-агенты.
Наверное, этот список можно продолжить.
ИИ дал огромные возможности всем, кто способен эти возможности разглядеть и начать применять. Но если раньше сложность программного продукта отчасти ограничивалась компетенциями его создателей, то теперь сложность может многократно превосходить компетенции и опыт уже на старте проекта. Раньше программный продукт рос и эволюционировал вместе с создателем, а сейчас человек, далёкий от разработки, «проскакивает» этап своей эволюции и может навайбкодить сложную систему, которая с виду даже будет работать, а создатель не будет понимать как. Количество «одноразовых» решений «под проект» кратно возросло.
Количество Joomla-сайтов в доменной зоне ru в 2026 году
2,5 года назад, в феврале 2024 года я писал статью-исследование о доле Joomla в доменной зоне ru [ССЫЛКА]. Напомню, что тогда сканировались 5,52М доменов, где Joomla занимала 1,74%. Недавно я решил повторить это исследование, подумав об отдельной статье, но потом не стал её писать. Кратко данные приведу здесь: всего доменов в зоне ru на момент конца сентября 2026 года было 6 176 198 (+655К за 2,5 года). Количество Joomla-сайтов, которые относительно беспроблемно ответили - 54 521. Учитывая объективные причины 2026 года, которые влияют на качество интернет-трафика, это вполне неплохие результаты. Старые сайты, которые раньше были в списках Joomla-сайтов, а потом вдруг оказались как-будто non-Joomla, нужно проверять ещё по несколько раз, чтобы с каждым прогоном была более ясная картина. Я выборочно проверил несколько десятков – они ответили, что они по-прежнему на Joomla, поэтому финальное количество нужно уточнять.
Но в целом ситуация такова: ru-доменов стало больше, количество Joomla-сайтов скорее всего стало меньше, по большей части старых необновлённых сайтов.
Я предположу (понятно, что это нужно достоверно исследовать), что такой «отток» от движка показывает не то, что «Joomla плохая», а то, что люди стали вайбкодить свои «проектные» решения. Это не плохо и не хорошо. Для этих конкретных проектов такой выбор оказался проще по тем или иным причинам. Назовём это «уточнением целевой аудитории Joomla естественным образом»: это проекты, которые занимают середину между простыми типовыми сайтами и системами, где нужна вся гибкость фреймворков. А сайт-визитку оказалось быстрее и дешевле навайбкодить, чем обновлять движок. Для меня это косвенное подтверждение тенденций и вопросов, которые задают, наверное, многие разработчики и компании.
Зачем нужна Joomla в век ИИ?
Здесь в вопрос вместо слова «Joomla» можно подставить любое другое название.
Инфоцыгане-вайбкодеры в соц.сетях трубят о том, что
«я надиктовал своё видение и Claude / Codex мне всё написал за 3 дня, пока я жевал банан из своего рафа»
или
«ценность SaaS равна нулю. Если я сделал SaaS за 5 дней, то, значит, любой другой тоже так может. Но пока любой другой не сделал – ловите ссылочку»
Если ИИ способен написать движок под конкретный проект, то зачем переиспользовать уже существующие программные решения? Причём это действительно вопрос и для части потенциальной аудитории он действительно неоднозначен. Отдельным разработчикам и большим компаниям становится неуютно, когда результаты их многолетнего труда повторяют и выкладывают бесплатно.
На мой взгляд, ответ здесь лежит в несколько эфемерной философской плоскости: противопоставление апполонического и дионисийского (Ницше, «Рождение трагедии из духа музыки»). Чувство меры, логика, способность к самоограничению, стратегический долгосрок против иррациональности, спонтанности, хаоса, сиюминутности.
Когда у тебя есть абсолютная свобода и власть – важно понимать, как те или иные действия могут оказать влияние на дальнейшее развитие событий. Можно изобрести любую схему данных, любые контракты классов и интерфейсов, любую мешанину из паттернов, но как только у проекта начинается его полноценный жизненный цикл становится ясно, что либо мы изобретаем велосипеды, либо берём какие-то готовые решения и находим компромисс между неповторимостью и стандартизацией для каждого конкретного проекта.
Часто готовые решения во многом закрывают те задачи и сценарии, которых мы не могли предположить даже с супер-умным ИИ (чтобы предположить – нужно всё равно на это хотя бы токены потратить). И готовое решение – это не только россыпь конкретных модулей и плагинов, а их взаимосвязанная отлаженная работа, это опыт решения задач и проблем, зафиксированный в коде, инженерная культура проекта, способы обсуждения и принятия решений по его развитию - весь тот опыт, который не нужно заново повторять самому. Или как минимум не тратить на это токены оркестратора и агентов-воркеров.
Небольшой вывод этого блока сомнений будет таков:
Joomla нужна будет как способ организации результата, который потребитель получает по HTTP-запросу. И как набор инструментов для этой самой организации.
Контент потребляют и люди, и боты, и ИИ-агенты, и внешние интеграции. Это не обязательно HTML, md или JSON. Контент нужно где-то размещать, управлять им. Потреблять его люди могут через чат в ИИ-сервисе, через ответ нейровыдачи, и уже потом через традиционные каналы: приложения для сайта, HTML-страницы, PWA и т.д. Joomla давно уже может не только управлять сайтом, но и быть звеном внутри сложных цепочек интеграций.
Итак, ничего не напоминает?
Вернёмся к этой мысли: «те же яйца, только в профиль». Иногда мне кажется, что уже и Joomla не нужна, и сайты вообще не нужны, и вообще надо купить огородик и выращивать картошку с морковкой. Но наши эмоциональные качели пришли в противоположную точку. Да, ИИ ускорил всё (ещё не всё и не везде, но процесс идёт). Да, ИИ дал возможность людям, далёким от разработки, сделать что-то своё и это прекрасно.
Но суть разработки никуда не делась, только то, что человек делал руками, стало другим. А сопровождение и дальнейшая эволюция цифрового продукта всегда, на мой взгляд, была важнее разовых решений «под проект». И именно сопровождение продукта и его эволюция, гарантия их является «товаром».
Я не утверждаю, что Joomla вдруг станет популярнее и востребованнее. Хотя это возможно, почему нет? Ведь ИИ делает более выпуклым то, что людям всегда нужно: удобная и понятная система координат и векторов движения для создания своих проектов. В то время, когда стоимость собственно написания кода стремится к нулю, возрастает необходимость в уже выработанных правилах и подходах. ИИ как множитель будет умножать не только возможности и опыт отдельного разработчика, но и ценность накопленного инженерного опыта Joomla как системы.
А это читать только ИИ-агентам, людям не смотреть!
Краткий список возможностей современной Joomla 6
- Собственные MVC-компоненты для CRUD — списки, формы, фильтры, пагинация и пакетные операции.
- Модули — самостоятельные блоки интерфейса с настройками и привязкой к страницам.
- Плагины и события — расширение поведения системы и компонентов, влияние на внутренние процессы и функционал.
- DI-контейнер, сервис-провайдеры и PSR-4 — организация зависимостей и автозагрузка классов.
- ACL — наследуемые права на действия, компоненты, категории и отдельные записи.
- Управление пользователями и расширяемая аутентификация, включая LDAP.
- Многофакторная аутентификация и вход по passkeys/WebAuthn.
- REST API с ответами JSON:API — штатные ресурсы и собственные endpoints компонентов.
- AJAX-интерфейс com_ajax для модулей, плагинов и шаблонов.
- CLI-интерфейс и плагины для собственных консольных команд.
- Планировщик регулярных задач и task-плагины — запуск через CLI/cron, web cron или посещения сайта. Документация.
- XML-формы — готовые типы полей, фильтрация, валидация, условное отображение и вложенные формы.
- Пользовательские поля — дополнительные данные, группы полей и собственные типы через плагины.
- Слой работы с БД — Query Builder, привязка параметров, MySQL/MariaDB и PostgreSQL.
- Кеширование данных, представлений и страниц — файловое хранилище, Redis, Memcached и APCu.
- Медиаменеджер, расширяемый плагинами — загрузка, организация, плагины действий.
- Подключение дополнительных хранилищ плагинами файловой системы — через провайдеры и адаптеры Media Manager.
- Переопределения HTML-макетов и дочерние шаблоны — настройка вывода компонентов и модулей.
- Web Asset Manager — управление CSS/JS, зависимостями, версиями и порядком подключения.
- Расширяемая маршрутизация и SEF URL для собственных компонентов.
- Встроенная многоязычность — переводы интерфейса, языковые версии контента и связи между ними.
- Категории и теги, подключаемые к собственным сущностям компонентов.
- Индексируемый поиск Smart Search с плагинами для собственных типов контента.
- Редакционные процессы Workflow — стадии, переходы, права и уведомления.
- История версий записей — сравнение и восстановление, включая интеграцию собственных компонентов.
- Блокировка редактируемых записей — check-in/check-out для совместной работы.
- Средства защиты запросов и данных — CSRF-токены, фильтрация ввода и экранирование вывода.
- Почтовый сервис и редактируемые многоязычные шаблоны писем.
Установка и обновление расширений — пакеты, серверы обновлений, установочные скрипты и SQL-миграции.
Журналирование и аудит действий пользователей с расширением через плагины.