Блог веб-программиста

Много лет назад, когда появилились первые фреймворки для PHP, мир веб-разработки стал лучше. Фреймворки стандартизировали типовые операции, предоставляли единые библиотеки для разработки приложений. Они объединили одиночных веб-разработчиков в сообщества. Фреймворки уменьшили порог вхождения в веб-разработку, т.к. для них появилась структурированная документация охватывающая весь начальный этап веб-разработки. Они брали на себя реализацию многих действительно сложных операций, и это делало создание сайтов и веб-приложений быстрее. Фреймворки научили нас применять на практике паттерны проектирования, и это сделало код сайтов лучше. Это было золотое время для фреймворков.

Оно прошло. Популярные фреймворки стали "жирные". Они стали потреблять много ресурсов сервера. На многих фреймворках, даже простой сайт, уже не может нормально работать без кеширования. Документация по фреймворкам стала настолько объемна, что порог вхождения в некоторые современные PHP фреймворки просто огромен. Фреймворки привели к ~~деградации~~ профессиональной деформации веб-разработчиков, многие кто работает постоянно на каком-то фреймворке, уже не представляет себе нормальную веб-разработку без него.

Фреймворки порождают множество проблем, связанных с самим фреймворком. В один момент вы можете обнаружить что ваш фреймворк удаляет $_POST, не поддерживает $_GET параметры в генерации адресов, имеет свой механизм для работы c $_SESSION, по-умолчанию где-то кеширует все запросы к базе данных и забивает этими данными всю свободную память, запоминает не актуальные состояния связанных ActiveRecord объектов .., и вам приходится много времени тратить на решение всех этих проблем, а не на разработку логики вашего скрипта. Это не выдуманные примеры, хотя сейчас некоторые из них уже нет, но обязательно есть другие. Многообразие существующих фреймворков говорит о том, что каждый из них в отдельности не идеален, иначе он бы уже вытеснил с рынка все остальные.

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

Фреймворки навязали нам свою игру, их разработчики увлеклись разработкой самих фреймворков. Регулярно выходят новые версии, не совместимые со старыми, и каждый сайт сделанный на фреймворке устаревает через несколько лет. Его код становиться не актуальный, а программисты которые на полную ставку работали над сайтами на старых версиях, становятся невостребованными на рынке труда.

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

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

Типовой микро-сервис не взаимодействует с пользователем напрямую. Ему не нужна сложная валидация данных и работа с формами. Ему не нужен роутниг, фронт-контроллер, тяжелый ORM, и куча библиотек "на все случаи жизни". Ему не нужен тяжелый фреймворк. Даже те фреймворки, которые позиционируют себя как "легкие" на практике могут оказаться избыточными. Микро-сервису не нужна игра навязанная фреймворками. Он не хочет устаревать и становиться не актуальным. Он не хочет чтобы его переписывали каждые несколько лет под новые версии фреймворков. Разработчик микро-сервиса не хочет решать проблемы связанные с фреймворком.

Похожие статьи: