Синдром фреймворка: почему у нас есть 3+ млн библиотек, но так мало полезных продуктов?
У каждого разработчика рано или поздно появляется это чувство. Ты открываешь код фреймворка и думаешь:
«Почему здесь столько ненужного?»
«Это же можно сделать проще!»
Сначала ты терпишь. Потом ищешь альтернативы. А потом открываешь пустой репозиторий и пишешь первый коммит…
Рождён новый фреймворк
Так случилось с PHP в его ранние годы. Каждый второй разработчик создавал свою версию MVC, потому что CodeIgniter был «слишком простой», Yii — «слишком сложный», а Zend Framework — вообще «монстр».
В результате вместо единой экосистемы появился хаос: у каждого проекта — своя маршрутизация, своя ORM, своя архитектура и логика, понятная только автору.
Node.js пошёл дальше. Там анархия стала философией. Express казался «тяжёлым» — и появился Koa. Koa вдруг оказался «слишком минималистичным» — и родился Fastify.
В NPM сейчас сотни роутеров, десятки логгеров и три популярных библиотеки для дат — выбирай, что душе угодно.
И вот что интересно…
Я знаю это чувство, потому что каждый раз прохожу через это сам.
Я могу работать с любым фреймворком, но рано или поздно появляется голос:
«А что, если сделать свой? Чистый. Лёгкий. Без чужих ошибок»
Этот голос — не просто мой. Это почти инстинкт каждого разработчика. Жажда контроля. Желание переписать мир с нуля, чтобы сделать его идеальным.
Но есть парадокс
Есть другая сторона — языки вроде Go и низкоуровневые экосистемы. Там подход обратный: фреймворки и готовые решения — это слабость. Если ты новичок и спрашиваешь: «Где взять библиотеку для этого?» — старожилы пожмут плечами:
«Всё есть в стандартной библиотеке — собери сам. Ты же программист»
Я столкнулся с этим, когда работал с вебсокетами в Go. Для этого есть популярная библиотека (4+ тысячи звезд на GitHub). Всё выглядит минималистично и «идиоматично», как принято в сообществе Go.
Только вот одна проблема: в реальных проектах она периодически просто крашилась вместо того, чтобы сделать реконнект — потому что так задумал автор. Это было «правильно» с точки зрения философии Go, но совершенно нелепо с позиции продукта, который должен просто работать.
Получается, что в одной экосистеме хаос из фреймворков, а в другой — болезненная строгость, где даже базовые вещи тебе предлагают писать самому.
И в обоих случаях можно заблудиться:
- В первом — потому что слишком много вариантов
- Во втором — потому что тебе говорят, что варианты тебе вообще не нужны
А что, если дело вообще не в инструментах?
Что если дело — в мышлении?
Разработчик часто думает: «Я могу сделать лучше».
Предприниматель думает иначе: «А это решает мою проблему?».
Чем дальше я двигаюсь в сторону бизнеса, тем чаще заставляю себя не открывать новый репозиторий, а взять готовое решение и просто двигаться вперёд.
Чем больше мы создаём фреймворков, тем запутаннее становится экосистема. Мы боремся за минимализм, но плодим хаос.
И тут интересно взглянуть на предпринимателей. У них другой рефлекс: они не создают — они используют.
Им неважно, насколько изящен код. Они возьмут что угодно — даже ноукод, SaaS, «грязные» API — лишь бы быстрее достичь результата.
И вот главный вопрос, который я теперь себе задаю:
Я действительно решаю проблему — или просто хочу сделать по-своему?
Иногда настоящий прогресс — это не новый фреймворк, а умение принять чужой инструмент и выйти из этого бесконечного цикла создания с нуля.
Особенно если ты хочешь сделать продукт, который принесет пользу людям.
Поэтому сейчас я стараюсь больше думать не о том, как написать какой-то код, а зачем. Но у меня пока что плохо получается 😅
А вы замечали за собой подобное? На каком этапе находитесь сейчас сами? Делитесь в комментариях!
Если вам интересно не только пользоваться техникой, но и разбираться, как всё это устроено — в моём блоге «Код без тайн» я рассказываю о науке, технике и разработке простым языком: