Хватит оправдывать архитектурный абсурд: как простые задачи стали заложниками сложных фреймворков
Блог Киберэтика | 04.11.2025
«Чтобы скрыть кнопку, я должен перезапускать сервер, чистить кэш, пересобирать статику и лезть в шаблоны? Вы там в своём Django совсем больны?»
Когда-то создание кнопки было делом пары строк HTML и CSS. Сегодня же, даже для того, чтобы скрыть элемент, ты обязан обойти лабиринт шаблонизаторов, серверной магии, пересборки, а иногда и костыльного JavaScript. Добро пожаловать в мир "масштабируемых" решений, где простота приносится в жертву надуманной абстракции.
Простой кейс, обросший жиром технологий
Есть кнопка, которую надо скрыть. Вот HTML:
<div class="headeractions">
<button class="headerbutton button accent_button">
<span class="headerbutton-text">Загрузить поздравление</span>
<img src="/static/main/img/icon.svg" alt="Иконка кнопки" class="headerbutton-icon">
</button>
<a href="/videos/" class="headerbutton button accent_button">
<span class="headerbutton-text">Загрузить поздравление</span>
<img src="/static/main/img/icon.svg" alt="Иконка кнопки" class="header__button-icon">
</a>
</div>
Цель: скрыть первую кнопку, у которой нет href, оставить вторую. Казалось бы:
.headeractions > button {
display: none;
}Но если ты используешь Django + Jinja2, простая правка может потребовать:
- редактирования шаблона,
- пересборки проекта (особенно при
collectstatic), - перезапуска сервера (
runserverилиsystemctl restart), - очистки браузерного кеша.
И всё это — чтобы скрыть элемент.
Почему индустрия (и ИИ) выбирают сложность?
«Фреймворки нужны для командной разработки и масштабируемых решений!» — говорят они. Но это — миф.
Вот что реально происходит:
- 90% веб-проектов можно реализовать на статическом HTML + JS, и они будут:
- работать быстрее,
- обслуживаться проще,
- внедряться без DevOps-ритуалов.
- Шаблонизаторы полезны лишь при генерации на основе данных, но даже это решается проще — статической сборкой.
- Архитектура становится самоцелью: компоненты, провайдеры, CI/CD, микросервисы... всё это заменяет суть надстройками.
Пример: альтернатива на Astro
Вместо Django можно взять Astro — он генерирует чистый HTML, поддерживая компоненты:
---
import Button from '../components/Button.astro';
---
<div class="headeractions">
<Button href="/videos/" text="Загрузить поздравление" />
</div>Результат: никакой серверной логики, никаких шаблонов. Просто HTML, готовый к продакшену.
Почему даже ИИ ведёт себя как корпорация
Интересно, что даже искусственный интеллект, обученный на гигабайтах кода и документации, часто идёт тем же путём усложнения. Почему? Потому что он обучен на данных, которые генерируют и крупные корпорации, где сложность — норма. Он впитывает не только рабочие решения, но и тренды, привычки и архитектурные догмы.
Когда ты спрашиваешь ИИ, как скрыть кнопку, он может сначала предложить «рекомендуемые» подходы с шаблонами, перезапусками и best practices, вместо того чтобы просто сказать: display: none.
ИИ — зеркало индустрии. Он даёт тебе ответ, который чаще встречается в продакшене, а не обязательно самый простой. Но стоит задать вопрос по-человечески — и он вполне может сказать правду, которую не скажут менеджеры и архитекторы.
Выводы без маркетинговой мишуры
- Не всё должно быть \"масштабируемо\". Иногда проекту не нужно масштабироваться — ему нужно работать.
- Динамика ради динамики — это обман. Если ты не используешь API, формы или логин — зачем тебе Django?
- Если правка кнопки требует больше трёх шагов — ты в архитектурной ловушке.
- HTML/CSS/JS — по-прежнему лучшая технология для 80% сайтов.
- Инструменты должны служить задаче, а не диктовать тебе, как жить.
Пусть каждый фреймворк получит по мозгам
Сложность — это не признак зрелости, а зачастую результат страха: страха быть \"немодным\", \"некомандным\", \"немасштабируемым\". Но ты не корпорация. Ты не обязан использовать Jinja2, Django, Webpack, PostCSS и CI/CD, чтобы скрыть мать его кнопку.
Программирование должно быть инструментом, а не ритуалом.
Не усложняй. Убирай лишнее. Работай по-человечески.
- Комментарии