Современные веб-системы стали неотъемлемой частью нашей жизни. Поэтому не удивительно, что уже существует огромное количество систем управления контентом и web платформ.
Однако, создаются они, в большистве своём, по следующему сценарию:
Всё логично - такие шаги действительно продиктованы экономической целесообразностью. Но есть ли проблемы у этой схемы?
Оказывается, да.
Расплата за удобство интерпретируемых языков - низкая скорость их работы, что никак не соответствует масштабам совеменного web'а. Лёгкий вход зачастую оборачивается низкой квалификацией разработчиков. А удобство редактирования играет злую шутку в случае взломов.
Готовые фреймворки - это, конечно, хорошо. Но разработку они ускоряют не просто так, а ценой повышения нагрузки на аппаратные ресурсы: растёт расход оперативной памяти, нагрузка на процессор, увеличивается время отклика.
Попытки удешевления разработки тоже приводят к дополнительным жертвам. Чаще всего это, опять же, производительность - ей просто некогда заниматься. Наскоро принятые технические решения снижают качество результата. В худшем случае жертвой становится безопасность.
Кэширование позволяет в какой-то мере замаскировать эти проблемы. Однако, и у этой медали обнаруживается обратная сторона: появляется дополнительный код для поддержания кэша в актуальном состоянии, сложность системы растёт, требуется и дополнительная память для хранения кэша.
Но можно ли что-то с этим поделать?
Эксперимент, по сути, пытается ответить именно этот вопрос.
Поскольку сложившееся положение напрямую следует из экономики и рациональности, очевидно, что любой коммерческий проект обречен следовать проторенной дорожкой с закономерным результатом.
Неужели с этим совсем ничего нельзя поделать? Похоже, всё не так мрачно.
Я попробовал подойти к проекту не как к коммерческому продукту, а как к произведению искусства.
Отбросив требование обязательной окупаемости можно получить некоторую свободу для творчества.
Раз так, попробуем перевернуть всю схему, устранив основные фундаментальные проблемы: