Челендж на 2026

Ну все идет от понимания, что такое фреймворк. (мне кажется я уже писал тут свое представление)

Фреймворк - инструмент разработчика. Да на этом уровне нужны хотябы минимальные знания php и документация по фреймворку.

Фреймворк + шаблонизатор. В принципе, если подготовлен костяк сайта, здесь уже не нужен php. все решается на уровне шаблонов. Т.е. пользователь должен знать html, css, если ему нужно js плюс язык шаблонизатора (примерно как и у тебя)

CMS - строится на основе фреймворка, имеет и шаблонизатор и панель управления. Т..е все по классике. Пользователю надо ее знать, знать html если нужно, но уже возможно все в интерфейсе делать не залезая в файлы

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

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

В моей классификации твой фреймворк это смесь фреймворка и CMS.  И именно смесь. На моем можно создать Rest API сервис в котором не будет ни какого html и шаблонизатора, не будет работы с БД.... т.е. будет легкое ядро.

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

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

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

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

Какие, например, ты имеешь ввиду?

Согласны с глупостью? Фреймворк так и переводится - рамки. Это как и четкие паттерны при разработке, так и рамки желания. Вы ограничены архитектурой. Посмотрите на ларавель. Вот, во что превращается универсальное средство. Сколько классов и кода тянет для простого запроса. Если вы пишите с нуля, то это явно либо лёгкий фреймворк, либо с нуля без него. Если вы пишите средний проект для продажи, то есть ларавель и этого с головой. Под него есть даже админка магическая и прочие ускорители написания. На нем реально проект за пару недель можно сделать. Идеально для прототипирования, но никогда бы не использовал в долгосрок. Техдолг все плюсы быстрого старта перекроет

Тут скорее по принципу "какой вопрос такой и ответ". Ведь если присмотреться внимательнее к теме речь не про монетизацию.  Основная цель изначально была заявлена  и там нет ни слова о том, что это проект про какую либо коммерческую выгоду. Человек зашел и спросил про монетизацию, ну я и предложил вариант монетизации. Таким образом "вперед" = "вперед монетизируйте" 

Такс. понятно. читать ни кто не любит? Специально для таких случаев в документации есть отдельная статья зачем этот проект

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

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

ЗЫ. У меня это всё прописывается в XML инструкции к странице. У тебя я так понимаю будет php файл с подключением классов и в объектах указыватся параметры, настройки.

Не считаю глупостью.

Ну а чем это входит в противоречие с написанным?

Ну хорошо, а теперь сравните ситуацию с WP? Или ещё лучше - с Elementor на WP.

Заказчик не будет оплачивать месячные бдения, максимум - неделю, вот мы возвращаемся к Laravel или CI, или к JS фреймворкам.

Нужен проект шире - Симфони.

Всё познаётся в сравнении. 

Ну нет, по моим наблюдениям совсем обратный вывод. Причем вариант более жесткий. Битрикс это вам не ларавель в плане лишнего. :)  И тем не менее вот мой проект (тот что с монетизацией). САПР это модуль к битриксу. Там работы дохрена. Нужно ли мне переписывать функционал предоставляемый битриксом? (в модуле он конечно в минимальных количествах)  Если переписывать то что бы что?:

Для пользователя (тот что на уровне шаблона уже) это будет выглядеть так

<!-- стили конкретного шаблона конкретного компонента -->
%include styles.css%
%include styles.js defer%
<button>%caption%</button>

%layout public%
%include /main/style.css%
<div class="some_block">
%component vendor.super.button%
</div>

Конечный синтаксис еще не утвержден, но примерно как то так

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

$response->builder->addHeadScript(__DIR__.'/script.js');
$response->builder->addCss(__DIR__.'/custom.js');
$response->setBody('<div class="desiogn">Hello Alex</div>');

А это как-то так, будет движком интерпретатором обработчиком %команда% будет?

$response-> по моему более лучший вариант для тебя