Челендж на 2026

Смотря что подразумевать под API: классические JSON-эндпоинты или просто любые маршруты в целом.

Тут речь про любые маршруты которые в ответ отдают HTML. Т.е. например "по классике"   мы имеем объект Response который в мидлварах "насыщается" теми же заголовками . И я подразумеваю, что может быть полезно дать гибкости для случая когда ответ отдается в HTML.   На примере симфони (если я правильно понимаю) у него есть вебпрофайлер, который подписан на событие ответа и если ответ text/html, то ищет закрывающий боди и докидывает туда свой кусок html. Так же бывают решения в проектах когда в head дописывают что либо.  Тут предполагаю что не будет необходимости "искать" ни head ни закрывающий body.

Будет:

- контент (все что будет вставлено в body)

- список js файлов которые нужно подключить на странице

- список css файлов которые нужно подключить на страницы

- "произвольные" строки для head

- дополнительно коллекции атрибутов для тега body и head

И все это будет жить по частям до момента отправки ответа.

Т.е. потребовался нам вывести отладочную информацию: модулю не надо искать body: добавил стили/скрипты в список и добавил к свой кусок к body.  Подключение счетчиков поисковых систем, можно оформить в виде мидлваров, и они будут докидывать все что нужно.

Ну а далее уже перед отправкой все это собирается в целый html: генерится полноценный html-head-body. Где нет дублей например скриптов. (например когда есть шаблонизатор, на странице в разных частях шаблона положили некий компонент (возможно с разными данными), но который хочет подключить свой скрипт и стили. Т.е. он зарегал, а этот билдер обеспечит чтобы этот скрипт и стили были подключены только один раз, переложит их в доступное из-вне пространство, если он еще не кешировался и не был изменен с прошлого копирования). возможно так же проверит нет ли min версии файла. (тут есть еще полет для мысли - можно минимифицировать на этом этапе, склеить, и т.п.)

так же , например скрипты можно будет добавлять в head или вниз страницы (указывать при добавлении куда его надо)

Это рационализаторское предложение можно каким-то образом монетизировать?

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

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

ЗЫ. А монетизировать можно только созданные продукты, например форум который он хочет сделать на своём этом фреймворке.

Создавайте на моем фреймворке CMS платную и вперед :)

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

По поводу XML точно нет.

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

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

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

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

На первом этапе (тут все же я хочу успеть сделать форум, а идей в голове даже на ядро уже накопилось дофига - но для реализации форума они не нужны. Это скорее про то, какой функционал нужен фреймворку для широкого диапазона проектов):  анализ метки времени файла для понимания что файл в публичной зоне протух (если ты про статику). Если про генерацию самой страницы. То задача шаблонизатора и системы кеширования.  Шаблонизатор я уже ранее тут публиковал. Его разработка на паузе (нужны были изменения в ядре). текущее состояние на github.  Он отдельным модулем. (все же фреймворк рассчитан и на проекты где может и не быть фронта). Ну и будет скелетон (рабочее название joke-site) где этот модуль будет сразу в комплекте.

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

Вопрос отложено вызвал такие мысли "по поводу" :)

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

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

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

Возвращаясь к моему проекту: любая фича - это как миниму попытка сделать удобнее и быстрее разработку конечному пользователю. (а пользователь в данном случае разработчик)

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

ЗЫ. Интересно взглянуть как такие объекты примерно будут выглядеть 😊

Я прошу прощения - и вперед что? :) Вперед смотреть, вперед ходить, вперед бегать? :)

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

Без УТП и маркетинга ничего не продаётся, а с учётом того, что уже давно существуют бесплатные CMS, которых развивают целые сообщества, думаете у частника есть против них хоть какие-то шансы?

По-моему никаких "вперед" в коммерческом плане тут нет... 

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

А ещё одна неизвестная платная CMS - по-моему без шансов.