Зачем еще одна CMS?

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

Однако, создаются они, в большистве своём, по следующему сценарию:

  1. Берется удобный интерпретируемый язык программирования, такой как PHP или python. Редактировать удобно и учебы требуется самый минимум.
  2. Сверху нагромождается массивный фреймворк, в котором "уже всё есть" - к чему "изобретать велосипед"?
  3. Коммерческий подход требует дальнейшего сокращения затрат - работы в сжатые сроки, поиска разработчиков подешевле
  4. Когда конструкция неизбежно начинает тормозить, используется кэширование готовых страниц

Всё логично - такие шаги действительно продиктованы экономической целесообразностью. Но есть ли проблемы у этой схемы?

Оказывается, да.

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

Готовые фреймворки - это, конечно, хорошо. Но разработку они ускоряют не просто так, а ценой повышения нагрузки на аппаратные ресурсы: растёт расход оперативной памяти, нагрузка на процессор, увеличивается время отклика.

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

Кэширование позволяет в какой-то мере замаскировать эти проблемы. Однако, и у этой медали обнаруживается обратная сторона: появляется дополнительный код для поддержания кэша в актуальном состоянии, сложность системы растёт, требуется и дополнительная память для хранения кэша.

Но можно ли что-то с этим поделать?

Эксперимент, по сути, пытается ответить именно этот вопрос.

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

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

Я попробовал подойти к проекту не как к коммерческому продукту, а как к произведению искусства.
Отбросив требование обязательной окупаемости можно получить некоторую свободу для творчества.

Раз так, попробуем перевернуть всю схему, устранив основные фундаментальные проблемы:

  1. Возьмём максимально эффективный компилируемый язык (в моём случае это C++)
  2. Используем ограниченное количество библиотек (рост нагрузки будет несколько скомпенсирован эффективностью языка)
  3. Поставим приоритетом эффективность и качество - вместо традиционного time to market. Дадим техническим решениям вызреть перед реализацией.
  4. Используем кэширование с умом
    (К примеру, можно кэшировать только шаблоны, совместно используемые множеством страниц - при минимальных ресурсах такой подход может оказаться даже быстрее чтения готовых страниц с диска)