PHP мёртв? Разбираем мифы цифрами

Каждый год появляются статьи с очередным заголовком: «PHP умер». Через год выходят новые материалы с тем же тезисом. За это время меняются фреймворки, растут новые языки, разработчики спорят о стеке в соцсетях, но реальный рынок веб-проектов движется намного спокойнее.

PHP редко становится героем громких технологических дискуссий. Его чаще встречают в работающих продуктах: корпоративных сайтах, интернет-магазинах, CRM, личных кабинетах, CMS, маркетплейсах, B2B-порталах и legacy-системах, которые годами обслуживают бизнес.

Origami работает с PHP-проектами с 2008 года и при этом использует другие технологии, включая Python, когда задача этого требует. Поэтому для нас выбор стека не строится вокруг «любимого языка». Сначала идут продукт, ограничения, команда, бюджет, срок жизни системы и требования к развитию. Потом выбирается технология.

Разберём, откуда взялся миф о «смерти PHP», что показывают цифры и в каких проектах современный PHP остаётся рациональным выбором.

Откуда появился миф о смерти PHP

Репутация PHP во многом сформировалась в эпоху PHP 5 и старых проектов, которые писались без нормальной архитектуры, тестов и процессов. Тогда язык действительно позволял многое: смешивать HTML и бизнес-логику, держать огромные файлы, добавлять функции без структуры, быстро запускать сайт и годами откладывать технический порядок.

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

Потом рынок получил новые яркие технологии. Node.js сделал JavaScript серверным языком. Python стал стандартом для Data Science, машинного обучения и аналитики. Go закрепился в инфраструктурных сервисах. Rust стал символом системной надёжности и контроля памяти.

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

Из-за этого создаётся ощущение, что рынок давно ушёл с PHP. Данные показывают другую картину.

Что показывают цифры в 2026 году

По данным W3Techs на 9 июля 2026 года, PHP используется на 70,8% сайтов, у которых известен серверный язык программирования.

Для сравнения, в той же выборке:

• Ruby — около 6,9%;
• JavaScript на сервере — около 6,7%;
• Java — около 5,5%;
• Scala — около 5,0%;
• ASP.NET — около 4,3%;
• Python — около 1,2%.

У методики W3Techs есть ограничения. Она считает сайты, где удалось определить серверную технологию, и один сайт может использовать больше одного серверного языка. Часть доли PHP связана с WordPress и другими CMS. Но даже с этими оговорками разрыв остаётся заметным.

Если смотреть на динамику, доля PHP постепенно снижается: по историческим данным W3Techs, с июля 2025 по июль 2026 показатель опустился примерно с 74,0% до 70,8%. Это говорит о зрелом рынке и перераспределении долей, но не о исчезновении технологии.

Отдельно стоит смотреть на версии. W3Techs показывает, что среди сайтов на PHP версия 8 используется у 61,6% таких сайтов. Версия 7 ещё занимает заметную долю, а старые версии 5 и 4 остаются в хвосте. Это важный сигнал: рынок постепенно обновляется, но legacy никуда не пропадает мгновенно.

Почему PHP до сих пор так распространён

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

CMS и коммерческий веб

WordPress, Drupal, Magento и множество корпоративных CMS связаны с PHP. Через них язык десятилетиями попадал в сайты компаний, медиа, e-commerce, образовательные проекты, каталоги, лендинги и порталы.

Для бизнеса это означает простую вещь: вокруг PHP уже есть инфраструктура. Разработчики, плагины, библиотеки, готовые интеграции, документация, хостинг, подрядчики и специалисты поддержки доступны на рынке.

Большая база работающих проектов

Многие компании годами развивают PHP-системы, которые уже решают бизнес-задачи: принимают заявки, продают товары, ведут пользователей, интегрируются с CRM, ERP, 1C, платёжными сервисами и внутренними кабинетами.

В такой ситуации вопрос редко звучит как «перейти с PHP или остаться». Чаще бизнесу нужно понять другое: насколько текущая система здорова, сколько стоит её развитие, какие модули мешают росту и где нужна модернизация.

Зрелая инженерная экосистема

Современная PHP-разработка давно ушла от образа хаотичных файлов без структуры. В рабочих проектах используются Composer, Laravel, Symfony, PHPUnit, PHPStan, Psalm, Docker, CI/CD, миграции, очереди, кэширование, статический анализ и нормальные процессы разработки.

PHP 8 добавил в язык атрибуты, promoted properties, union types, match expression, nullsafe operator, улучшения типизации и обработки ошибок. Это не превращает PHP в универсальный ответ для любой задачи, но делает современный код намного безопаснее и выразительнее по сравнению со старым наследием эпохи PHP 5.

Где PHP действительно силён

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

Корпоративные сайты и порталы

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

Интернет-магазины и маркетплейсы

В e-commerce PHP остаётся сильным вариантом благодаря готовой инфраструктуре: каталоги, корзины, заказы, платежи, скидки, интеграции с учётными системами, складом, доставкой и маркетингом.

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

CRM, ERP и внутренние системы

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

В таких проектах решают качество архитектуры, модели данных, API, безопасности и процессов поддержки, а название языка остаётся только частью решения.

Поддержка и развитие legacy

Огромное количество PHP-проектов уже существует. Их нельзя остановить на год ради полного переписывания. Часто выгоднее провести аудит, обновить зависимости, вынести проблемные модули, закрыть риски безопасности и постепенно привести систему к нормальному состоянию.

Полная миграция оправдана не всегда. Иногда она создаёт новые риски: потерю бизнес-логики, рост бюджета, заморозку развития продукта и длинный период параллельной поддержки двух систем.

Где PHP может быть слабым выбором

У PHP есть свои границы. Это нормально для любой технологии.

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

Если требуется сервис с особыми требованиями к конкурентности, сетевому взаимодействию или низкоуровневой производительности, команда может рассматривать Go, Rust или другие специализированные стеки.

Если продукт строится вокруг real-time сценариев, стриминга, WebSocket-нагрузки или событийной архитектуры, PHP может остаться частью системы, но не всегда должен быть главным инструментом.

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

Почему шум в соцсетях не равен рынку

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

Язык может быть менее модным в обсуждениях и при этом оставаться практичным для огромного количества задач.

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

Проблема начинается, когда бизнес принимает решение по шуму в информационном поле. «Все уходят с PHP» звучит убедительно, пока не посмотреть на реальные проекты, бюджет миграции, риски переписывания и состояние текущей кодовой базы.

Когда стоит оставить PHP и развивать проект

Существующий PHP-проект имеет смысл развивать, если:

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

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

Когда стоит подумать о миграции

Миграция на другой стек может быть оправдана, если:

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

Даже в таком сценарии решение лучше принимать после технического аудита. Он показывает, какие части можно сохранить, какие модули стоит заменить первыми и как избежать переписывания ради самого переписывания.

Мифы о PHP, которые мешают принимать решения

Миф 1. На PHP пишут только старые сайты

На PHP действительно работает много старых сайтов. Но это не отменяет современные проекты на Laravel, Symfony, WordPress, WooCommerce, Magento и кастомных фреймворках.

Возраст языка не делает проект устаревшим автоматически. Устаревает код без архитектуры, поддержки, тестов и обновлений.

Миф 2. PHP медленный

Старые версии PHP и плохо написанный код могли создавать проблемы с производительностью. Современный PHP 8 заметно отличается от PHP 5: язык получил JIT, улучшения типизации, работу с ошибками и более зрелую экосистему.

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

Миф 3. На PHP нельзя строить серьёзные продукты

Серьёзный продукт определяется требованиями, архитектурой и командой. На PHP работают крупные CMS, медиа, коммерческие сайты, каталоги, сервисы, порталы и внутренние платформы.

Если проект требует сложной бизнес-логики, ролей, интеграций, админки и поэтапного развития, PHP может быть вполне зрелым выбором.

Миф 4. Любой legacy на PHP нужно переписывать

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

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

Как выбирать стек без религиозных споров

Нормальный выбор технологии начинается с вопросов:

• какой продукт нужно построить;
• сколько лет система должна развиваться;
• какие интеграции обязательны;
• какие требования к нагрузке и безопасности;
• кто будет поддерживать проект после запуска;
• насколько быстро нужно выйти на рынок;
• сколько стоит найм команды;
• есть ли существующий код, который нужно учитывать.

После этого PHP сравнивается с Python, Node.js, Go, Java, .NET или другим стеком через требования задачи, команду, бюджет и срок жизни продукта.

Для одного проекта PHP будет правильным выбором. Для другого лучше подойдёт Python. Для третьего нужна гибридная архитектура, где разные части продукта пишутся на разных технологиях.

FAQ

PHP правда умирает?

Нет. Доля PHP в вебе постепенно снижается, но по данным W3Techs на 9 июля 2026 года язык всё ещё используется на 70,8% сайтов с известным серверным языком. Это не похоже на исчезновение технологии.

Почему тогда многие говорят, что PHP устарел?

Часть репутации связана со старым legacy, особенно проектами эпохи PHP 5. Ещё одна причина — информационный шум вокруг новых языков. Но старый плохой код и современная PHP-разработка отличаются очень сильно.

Можно ли начинать новый проект на PHP в 2026 году?

Да, если задача подходит под сильные стороны PHP: веб-приложение, корпоративный сайт, интернет-магазин, портал, CRM, личный кабинет, CMS или кастомная бизнес-система. Перед выбором стека стоит оценить требования к продукту, команду, сроки и стоимость поддержки.

Когда PHP лучше заменить другим стеком?

Если продукт строится вокруг машинного обучения, интенсивной аналитики, низкоуровневой производительности, сложной конкурентности или real-time сценариев, стоит рассмотреть другие технологии. Иногда PHP остаётся частью системы, а ключевые сервисы выносятся в отдельные компоненты.

Что делать со старым PHP-проектом?

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

Почему PHP всё ещё занимает такую большую долю?

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

Вывод

PHP давно перестал быть тем языком, из-за которого появились старые мемы. Он не является универсальным решением для каждой задачи, но разговоры о его «смерти» годами расходятся с реальной картиной коммерческого веба.

Для бизнеса главный вопрос звучит практичнее: подходит ли PHP конкретному проекту, сколько стоит развитие текущей системы и какие риски есть у миграции.

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

Обсудить задачу с Origami