17.08.2026 15:43
DevRoad 74 18000 Источник

Если бы в интернете вручали премию за количество мемов, в финал наверняка вышли бы Леонардо ДиКаприо, коты с осуждающим взглядом и язык PHP. Над последним разработчики шутят уже столько лет, что фразу «я пишу на PHP» лучше говорить шепотом или не говорить вовсе.

При этом язык, который регулярно объявляют мертвым, продолжает получать новые версии, обслуживать миллионы сайтов и оставаться востребованным в веб-разработке. Как появился PHP, чем он заслужил плохую репутацию и почему до сих пор не исчез — рассказываем в этой статье.

2026: многие по-прежнему говорят, что PHP умер. На самом деле он продолжает получать новые версии, обслуживать миллионы сайтов и игнорировать собственные похороны.
2026: многие по-прежнему говорят, что PHP умер. На самом деле он продолжает получать новые версии, обслуживать миллионы сайтов и игнорировать собственные похороны.

С чего началась история PHP

История PHP началась не в лаборатории крупной IT-компании и даже не с планов создать новый язык программирования. В 1994 году программист Расмус Лердорф написал несколько небольших серверных программ для собственной страницы с резюме. Они помогали ему отслеживать посещения сайта и собирать простую статистику. Набор инструментов получил название Personal Home Page Tools, или сокращенно PHP Tools. На этом этапе PHP еще не был полноценным языком — скорее личным комплектом утилит, созданным для решения конкретной задачи.

Постепенно возможностей обычного счетчика стало не хватать. Лердорф добавил обработку веб-форм и взаимодействие с базами данных, благодаря чему на основе проекта уже можно было создавать простые динамические веб-приложения. В июне 1995 года он опубликовал исходный код PHP Tools, а в апреле 1996 года после очередной переработки представил PHP/FI, где FI расшифровывалось как Forms Interpreter. В июне того же года проект получил статус версии 2.0. Именно PHP/FI 2.0 стал этапом, на котором набор отдельных инструментов начал превращаться в самостоятельный язык серверного программирования.

Мемов настолько много, что все в эту статью не поместятся. Но некоторые мы приложим, наслаждайтесь...
Мемов настолько много, что все в эту статью не поместятся. Но некоторые мы приложим, наслаждайтесь...

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

PHP хорошо подошел для таких сценариев. Код выполнялся на сервере, принимал данные из форм, обращался к базе данных, управлял пользовательскими сессиями и формировал ответ в зависимости от запроса. Это могла быть страница с сообщением об ошибке, персональный профиль, список найденных товаров, комментарии к записи или данные для обновления интерфейса. Браузер получал только результат выполнения программы — готовый HTML либо, позднее, структурированные данные, которые обрабатывал JavaScript.

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

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

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

И дело здесь не в том, что на ранних версиях PHP нельзя было создать безопасный и надежный сайт. Сам выбор языка не делал проект уязвимым. Конечно, старый PHP грешил такими механизмами, как register_globals и magic_quotes. Первый автоматически переносил параметры запроса в глобальные переменные, из-за чего при неаккуратно написанном коде пользователь мог повлиять на значения, которым приложение доверяло. Второй автоматически экранировал часть входящих данных, но делал это непоследовательно и создавал ложное ощущение, что ввод уже безопасен для работы с базой. Оба механизма впоследствии удалили в PHP 5.4.

Но какой язык того времени был абсолютно безгрешен? C и C++ допускали целые классы ошибок при работе с памятью, а в Java-платформе регулярно находили уязвимости в среде выполнения и стандартных библиотеках. PHP оказался особенно заметен из-за масштаба своего распространения: низкий порог входа сделал его доступным огромному числу начинающих разработчиков, а растущий спрос на динамические сайты превратил язык в один из основных инструментов веба. Так PHP стал одним из языков, которые сделали динамические сайты повсеместными, и одновременно заложил основу репутации языка, на котором слишком легко написать не только работающий, но и очень плохой сайт.

От PHP 3 до PHP 8.5: как менялся язык вместе с интернетом

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

1998 год — PHP 3 становится полноценным языком

К развитию проекта присоединились израильские программисты Энди Гутманс и Зеев Сураски. Им не хватало возможностей PHP/FI для интернет-магазина, над которым они работали в рамках университетского проекта, поэтому они полностью переписали механизм, разбиравший PHP-код. Вместе с Лердорфом разработчики создали PHP 3, официально выпущенный в июне 1998 года.

В новой версии появился более последовательный синтаксис, начальная поддержка объектно-ориентированного программирования и возможность подключать дополнительные модули. Благодаря расширениям PHP получил интерфейсы для работы с различными базами данных, сетевыми протоколами и API. К моменту официального релиза PHP 3 уже использовался более чем на 70 тысячах доменов.

2000 год — PHP 4 становится быстрее

По мере усложнения сайтов возможностей PHP 3 стало не хватать. Гутманс и Сураски снова переписали внутреннее ядро языка и назвали его Zend Engine — название составили из их имен, Zeev и Andi. На основе этого ядра в мае 2000 года вышел PHP 4, заметно повысивший производительность сложных веб-приложений.

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

2002–2004 годы — PHP становится основой будущих крупнейших веб-платформ

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

В январе 2002 года англоязычная Wikipedia перешла на новый движок, написанный на PHP и работавший с базой MySQL. Впоследствии из него выросла система MediaWiki, на которой Wikipedia работает и сегодня.

В мае 2003 года появилась первая версия WordPress — платформы для создания и управления сайтами, также построенной на PHP и MySQL. Изначально она предназначалась в первую очередь для блогов, но со временем превратилась в универсальную систему для новостных ресурсов, корпоративных сайтов и интернет-магазинов.

В 2004 году Facebook запустился как сравнительно простой сайт, страницы которого формировались на сервере с помощью PHP. Позднее, когда аудитория соцсети выросла до огромных масштабов, инженеры компании создали собственные технологии для ускорения и более строгой проверки PHP-кода. В итоге Facebook разработал HipHop и HHVM, а затем — Hack, отдельный язык с более развитой системой типов. В 2014 году компания сообщила, что почти вся ее прежняя PHP-кодовая база была переведена на Hack.

2004 год — PHP 5 учится работать с большими проектами

В июле 2004 года вышел PHP 5 на основе Zend Engine 2. Главным изменением стала серьезно переработанная объектная модель. Объектно-ориентированный подход позволяет разделять приложение на самостоятельные компоненты — например, отдельно описать пользователя, заказ, товар или платеж — и затем использовать эти компоненты в разных частях проекта.

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

Именно в эпоху PHP 5 сформировалась современная экосистема языка: появились крупные фреймворки, готовые библиотеки и общепринятые способы организации проектов. PHP все меньше напоминал набор отдельных скриптов, перемешанных с HTML, и все больше — полноценную платформу для серверной разработки.

PHP 6 — версия, которая так и не вышла

В 2005 году разработчики начали работу над PHP 6, главным изменением которого должна была стать нативная поддержка Unicode в ядре языка и во внутреннем представлении строк. В 2010 году проект прекратили из-за сложности этой реализации. Часть возможностей, не зависевших от новой Unicode-модели, позднее вошла в PHP 5.3 и 5.4, но стабильного релиза PHP 6 так и не появилось. Поэтому следующая крупная версия получила номер 7.

2015 год — PHP 7 получает второе дыхание

PHP 7 стал одним из самых важных обновлений в истории языка. Новое ядро Zend Engine 3 заметно сократило потребление памяти, а некоторые приложения могли работать до двух раз быстрее, чем на PHP 5.6. На практике это означало, что тот же сервер мог обработать больше запросов без покупки дополнительного оборудования.

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

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

2020 год — PHP 8 становится более строгим и современным

PHP 8 продолжил движение в сторону более предсказуемого кода. В языке появились объединенные типы, именованные аргументы, выражение match, атрибуты и более последовательная обработка ошибок.

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

2021–2025 годы — PHP 8 продолжает получать новые возможности

Ветка PHP 8 продолжила установленный ранее ежегодный цикл функциональных релизов.

  • В PHP 8.1 появились перечисления, readonly-свойства и fibers — низкоуровневый механизм приостановки и возобновления выполнения, который библиотеки могут использовать для построения асинхронных API.

  • В PHP 8.2 добавили целые классы только для чтения и начали отказываться от динамических свойств, которые могли появляться в объектах случайно из-за опечатки.

  • PHP 8.3 разрешил указывать типы констант классов и улучшил инструменты для работы со случайными значениями.

  • В PHP 8.4 появились хуки свойств, позволяющие задавать правила чтения и изменения данных прямо в классе, более гибкое управление доступом и обновлённые инструменты для обработки HTML-документов.

  • PHP 8.5, выпущенный 20 ноября 2025 года, получил встроенное URI-расширение для разбора и нормализации URI и URL, pipe-оператор |> и возможность изменять свойства непосредственно при клонировании объекта.

Получается, PHP давно перестал быть тем самым хаотичным языком из скриптов начала 2000-х. Но репутация меняется медленнее программного кода. Сам язык уже несколько раз серьезно обновился, а интернет все еще показывает коллегам его неудачную фотографию из 2003 года.

Так почему PHP стал главным героем программистских мемов?

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

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

Представим специалиста, который приходил поддерживать старый PHP-проект. Он открывал файл index.php и обнаруживал внутри сразу все: HTML-разметку, запросы к базе, проверку авторизации, расчет скидки, отправку писем и комментарий предыдущего разработчика: «Не удалять, иначе все сломается». Разумеется, раздражение начинало ассоциироваться не только с автором конкретного проекта, но и с языком, на котором этот проект был написан.

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

PHP в 2026 году: живее, чем кажется

Если судить по количеству мемов, PHP уже давно должен был уйти на заслуженный покой вслед за Flash Player и Internet Explorer. На практике язык не только продолжает работать, но и регулярно получает обновления. Сейчас актуальной стабильной веткой остается PHP 8.5, а актуальным патч-релизом — PHP 8.5.9. PHP 8.6 уже находился на стадии Beta 1 и был доступен для тестирования, но еще не предназначался для production-среды. Официально поддерживаются ветки PHP 8.2–8.5: для них продолжают выпускать обновления безопасности, а для более новых версий — еще и обычные исправления ошибок. Язык, для которого уже тестируют следующее крупное обновление, трудно назвать мертвым.

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

Живой остается и экосистема языка. В марте 2026 года вышел Laravel 13, а актуальной стабильной версией другого крупного фреймворка стал Symfony 8.1. Фреймворк — это готовая основа для приложения: он предоставляет инструменты для работы с адресами страниц, базой данных, авторизацией, проверкой информации и другими типовыми задачами. Благодаря Laravel и Symfony новые проекты не приходится собирать из случайных фрагментов кода, найденных на форумах: разработчики получают понятную структуру и общепринятые правила организации приложения.

Конечно, точное количество работающих на PHP сайтов определить невозможно. Однако, по данным W3Techs на август 2026 года, PHP обнаруживается на 70,3% сайтов, у которых удалось определить серверный язык. Это не означает, что ровно 70,3% всех страниц интернета написаны только на PHP, но хорошо показывает масштаб его присутствия. Один только WordPress, построенный на PHP, используется на 40,8% всех отслеживаемых сайтов.

Сегодня PHP продолжает работать в основе:

  • WordPress и интернет-магазинов на WooCommerce;

  • MediaWiki — платформы, на которой работает Wikipedia;

  • систем управления сайтами Drupal;

  • образовательной платформы Moodle;

  • интернет-магазинов, личных кабинетов, API и внутренних бизнес-систем, создаваемых на Laravel и Symfony.

Причем это не только поддержка древнего наследия. Современная MediaWiki работает с PHP 8.3–8.5, WooCommerce рекомендует PHP 8.3 и новее, а актуальные версии популярных фреймворков требуют современные ветки языка.

В общем рейтинге языков положение PHP выглядит скромнее. В августе 2026 года он занимает 13-е место в индексе TIOBE. Но этот рейтинг оценивает общую популярность языка по числу специалистов, учебных материалов, поставщиков и упоминаний в поисковых системах. Он не показывает, какая доля сайтов действительно работает на конкретной технологии, и тем более не определяет, какой язык «лучше».

Постепенно доля PHP в вебе все же сокращается: за год показатель W3Techs снизился примерно с 73,7 до 70,3%. Для новых сервисов разработчики все чаще рассматривают JavaScript или TypeScript на платформе Node.js, Python, Java, Go и другие технологии. Однако огромная база существующих сайтов, WordPress, интернет-магазины и активно развивающиеся фреймворки еще долго будут поддерживать спрос на PHP. Скорее всего, он уже не вернется в статус самого модного языка, но и внезапного исчезновения ждать не стоит.

Заключение

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

Комментарии (74)


  1. Dhwtj
    17.08.2026 16:11
    #30340398

    В защиту PHP скажу, что он стал более выразительным для развитой бизнес логики чем Go

    Бегство PHP программистов на Go за монетой плохо закончится для них. Бегство без смены компетенции. С учётом, что гоферов берут на работы, где нужен быстрый вход.

    Ну вот ты представь себе типичного пхп программиста с опытом 5+ лет, но без опыта на c++, Java, c# и ушедшего на Go. Кем он станет и сможет ли удержаться когда потребность в инфраструктуре сократится с взрывного роста до нормального?

    Что он уносит с собой из PHP: скриптовое мышление, процедурный стиль со структурами вместо модели, привычку к "запрос-ответ-умер", слабое представление о памяти, конкурентности, стоимости аллокаций. Go это не лечит, а легализует: язык сам по себе процедурный с минимумом абстракций, поэтому такой человек пишет на Go как на PHP, только без исключений и с go func(){} в случайных местах. И код проходит ревью, потому что идиоматичный Go от плохого Go отличить труднее, чем идиоматичный C# от плохого C#. Компилятор не мешает, ошибки возвращаются, всё "просто".

    Пик (судя по tiobe, он уже прошёл) спроса на Go совпал с миграцией всего подряд в k8s и микросервисы. Когда этот цикл закрывается, остаются две категории работы: эксплуатация написанного и новая разработка в узких местах (сети, observability, embedded-сервисы). Туда берут людей, которые понимают планировщик, профилирование, backpressure, сетевой стек. Наш гипотетический перебежчик этим не владеет (если не было опыта с более энтерпрайными языками) , он владеет "написать handler и задеплоить через готовый чарт". В нормальном (не взрывном) рынке он конкурирует с системщиками и проигрывает.

    Хотя, лично я предпочитаю C#, Rust


    1. Dhwtj
      17.08.2026 16:11
      #30340962

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


    1. DimNS
      17.08.2026 16:11
      #30341492

      Доводы у вас отличные, я согласен.

      C другой стороны, кто сказал что нельзя использовать go с дешевой ассинхронщиной как замену php, разве что отсутствие полноценного фреймворка, но как будто он и не нужен, например есть ogen и его достаточно если писать API+SPA

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


      1. Dhwtj
        17.08.2026 16:11
        #30342602

        Если слегка подпрыгнуть, то типизация есть и в пхп, а дженерики в пхп даже лучше, выразительней чем в го ;)

        Только дженерики придётся через PHPDocs лепить и Psalm / PHPStan или хотя бы на сообщения IDE посматривать 

        <?php

final class User
{
    public function __construct(
        public readonly int $id,
        public readonly string $name,
    ) {}
}

final class Order
{
    public function __construct(
        public readonly int $id,
        public readonly float $total,
    ) {}
}

interface EntityRepository
{
    /**
     * @template T of object
     * @param class-string<T> $class
     * @return T|null
     */
    public function find(string $class, int $id): ?object;

    /**
     * @template T of object
     * @param class-string<T> $class
     * @return list<T>
     */
    public function findAll(string $class): array;
}

final class InMemoryRepository implements EntityRepository
{
    public function find(string $class, int $id): ?object
    {
        return match ($class) {
            User::class => new User($id, 'Ivan'),
            Order::class => new Order($id, 99.50),
            default => null,
        };
    }

    public function findAll(string $class): array
    {
        return match ($class) {
            User::class => [new User(1, 'Ivan'), new User(2, 'Petr')],
            Order::class => [new Order(1, 99.50)],
            default => [],
        };
    }
}

$repo = new InMemoryRepository();

$user = $repo->find(User::class, 1);
// Psalm выводит тип: User|null
if ($user !== null) {
    echo $user->name; // анализатор знает, что свойство name существует
}

$orders = $repo->findAll(Order::class);
// Psalm выводит тип: list<Order>
foreach ($orders as $order) {
    echo $order->total; // type-safe для анализатора
}

        Такое в го невыразимо

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


        1. Free_ze
          17.08.2026 16:11
          #30342766

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

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


          1. Dhwtj
            17.08.2026 16:11
            #30342804

            Было голосование

            https://wiki.php.net/rfc/bound_erased_generic_types

            тут тип выглядит настоящим, но не проверяется. Gina Banyard прямо пишет, что большинство разработчиков, увидев Collection<User> в сигнатуре, ожидают рантайм-проверку, и узнав, что её нет, реагируют с недоумением

            Предлагают полноценные вместо стёртых в пхп 9 через год

            https://daily.dev/posts/vote-rfc-bound-erased-generic-types-19ahl5hl7

            Но пока можно и через тулинг

            Опять же, это будет лучше сравнивая с стёртыми типами TS, которых уже нет в рантайме

            Array<User> в рантайме TS это просто массив, положить туда Order вместо User можно через любую щель (any, as, внешний JSON), и движок не пикнет.


            1. Free_ze
              17.08.2026 16:11
              #30343026

              большинство разработчиков, увидев Collection в сигнатуре, ожидают рантайм-проверку, и узнав, что её нет, реагируют с недоумением

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

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

              any, as, внешний JSON

              Для этого программисту придется осознанно прицелиться в ногу и спустить курок.

              движок не пикнет.

              JS-движок обвалится уже на этапе попытки запустить “сырой” TS код с типами. А PHP комменты игнорирует и с радостью пойдет куролесить.


              1. Dhwtj
                17.08.2026 16:11
                #30344072

                Для этого программисту придется осознанно прицелиться в ногу и спустить курок

                Она откажется. Холмс: – Ей не придётся. Всё произойдёт само собой© в советской экранизации «Приключения Шерлока Холмса и доктора Ватсона: Сокровища Агры» (1983)


        1. gudron
          17.08.2026 16:11
          #30344802

          ну если это вы называете выразительно, то тогда лучше действительно оставаться в php и никуда больше не смотреть.


    1. ViskasSP1vom
      17.08.2026 16:11
      #30341884

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


    1. Void-Cowboy
      17.08.2026 16:11
      #30343122

      в чем то вы правы, но php уже давно не торт и по запутанности и возможности налепить костылей он уже давно где-то на уровне Java

      Go по крайней мере бьет по рукам за слишком уж широкую самодеятельность, а для всего остального есть кодестайлинг и прочие правила в проекте

      щарп и раст как раз плохи своей "широтой". на долгой поддержке чем проще тем лучше, собсвенно на этом php изначально и держался


      1. Dhwtj
        17.08.2026 16:11
        #30344096

        Java сложна не языком, а экосистемой: Spring, Hibernate, XML-конфиги, аннотационная магия, пул потоков, GC-тюнинг. PHP 8.x с readonly, enums, named args и атрибутами проще по конструкции. Запутанность PHP-кода обычно от легаси без типов, не от самого языка.

        Не понял за что там бьёт Go. Наличие компилятора ещё не признак ума© Это только у Rust есть поговорка "если компилируется, значит работает правильно". У Go такой поговорки нет. Вам рассказать, почему так?

        Так что статическая компиляция в Go это скорее про скорость, а не про гарантии.

        Можно писать простой C# без событий, без reflection, без LINQ-чудес. Но когда домен требует discriminated union, pattern matching, immutable record, readonly struct, то инструменты для них там есть. В Go их нет, и вы вынуждены изобретать велосипеды или писать лапшу. "Широта" плоха только если вы ее используете без нужды. Это лечится упрощённым кодстайлом в конкретной группе, проекте. Отсутствие широты плохо, когда нужда есть.


        1. Void-Cowboy
          17.08.2026 16:11
          #30345054

          упрошенный кодестайлинг чего-то стоит

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

          с Го ты не ставишь турбину от самолета когда тебе нужен только удобный интерфейс к вентилятору. Даже если в проект затягивается гигантский "швейцарский нож" (пакеты которых как раз насоздавали "мигранты" с php и прочих "удобных" языков) то все равно точка соприкосновения только там где используется и это все можно отследить, посмотреть по коду и отттраисировать без танцев с бубном

          Вон не так давно в Го дженерики добавили как раз из-за подобных воплей про "удобство". В итоге вместо использования явного генератора и контроля над сгенерированым кодом появилась точка отказа, так как "проще" использовать any а потом ловить проблемы на этом поприще или просадку латенси и-за гиганского if-else дерева для "безопасного" обслуживания этого дженерика

          А за Раст посмеялся) Завтра еще коллегам на созвоне расскажу, вместе посмеемся)
          Сколько же я по работе видел откровенного Г на расте не передать. Язык не спасет если пользователь идиот и/или не понимает что и как делать. Зато вместе с Растои идет эльфийский синтаксис который просто больно читать, зависимость от dll и прочего (из-за чего кроссплатформа для чего-то реально боевого, а не просто сайтики становится веселым квестом) а так же мое любимое это ручной контроль над памятью (80% кривизны как раз в этом, просто тому что среднестатический "вкатун" в Раст вообще понятия не имеет что это за зверь такой ваша память и в чем проблема что все ОК работает только на его последнем маке)


          1. Dhwtj
            17.08.2026 16:11
            #30345390

            Зато когда нужна турбина на Go приходится делать её из костылей. Go не универсальный язык, как впрочем и PHP. Узкая специализация. К пуговицам претензии есть? ©

            А вот C#, Java, Rust, C++ универсальные.

            эльфийский синтаксис

            Вы не можете переключиться? Синтаксис из ML, C++

            Язык не спасет если пользователь идиот и/или не понимает что и как делать

            Ничего не спасет. Гофер напишет кодосодержащий продукт через час после знакомства с синтаксисом. Идиотом он не перестанет быть.

            На уровне вкатуна на Rust просто втыкают.clone() и забывают про владение и время жизни. Ичсх, всё равно работает быстро


            1. Void-Cowboy
              17.08.2026 16:11
              #30347026

              ух сколько было столкновений за "быстро" и каждый раз как просишь показать класс для сравнения в одинаковых задачах начинается пук-пук-среньк

              в целом я согласен с тем что на расте можно строить в разы быстрее и оптимальнее по ресурсам в сравнении с Го, потому как прямое управление памятью, привязка к найтивным встраиваемым либам и этим все сказано

              но для реальной оптимальности с этим нужно уметь работать и понимать что ты вообще творишь и какой результат хочешь получить (и нейросети тут не помогут)

              мы проводили бесчеловечные эксперименты на джунах и при равных "нулевых исходных" кривая обучения-качества у Го выше на несколько порядков чем у раста.

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

              просто сейчас с Растом идет скорее эффект секты и "элитность" благодаря нейросетям, когда можно вайбкодить что то там рабочее и говорить что ты мега крутой разработчик на расте


  1. gudron
    17.08.2026 16:11
    #30340470

    Сколько картинок мемных не вставляя. а к PHP-шникам сейчас отношение рынка - их дохера и они дешевые и всегда можно уволить. Да и дальше админки на yii/laravel редко что-то уходит. Удачи.


    1. PiramidHead
      17.08.2026 16:11
      #30342152

      Мне кажется, утверждать такое может только человек, который никогда не искал в команду PHP разработчика. Именно разработчика, а не эникейщика.


      1. mitzury
        17.08.2026 16:11
        #30346994

        если Вы ищете, готов попробовать)


        1. PiramidHead
          17.08.2026 16:11
          #30347028

          На данный момент штат укомплектован, но можете скинуть CV в лс.


  1. MountainGoat
    17.08.2026 16:11
    #30340508

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


    1. TsarS
      17.08.2026 16:11
      #30340518

       Не вижу вообще ни одной причины начинать что-то новое на PHP.

      А на чëм видите?


      1. crama
        17.08.2026 16:11
        #30341026

        Go + templ + htmx

        Благодаря горутинам новые сессии дают ничтожное потребление RAM.

        Htmx даёт крутой опыт SPA приложения.

        Templ даёт дикую скорость генерации страницы.

        Реальная многопоточность и космическая скорость (доска объявлений с 4 запросами в бд отдает HTML за 5мс).

        Можно даже приложение для винды через wails сделать.

        Кто-то развивается, а кто-то защищает PHP, так как "на его век ещё хватит". Да и лень мозг напрягать на что-то новое. Проще мемасов накидать.


        1. sunUnderShadow
          17.08.2026 16:11
          #30341886

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


        1. ViskasSP1vom
          17.08.2026 16:11
          #30341902

          Изобрели серверный рендеринг заново и радуются. Поздравляю, вы открыли для себя PHP образца 2005 года, только с компиляцией в бинарник и модным баззвордом htmx


    1. vtal007
      17.08.2026 16:11
      #30340664

      так куча ж CMS, просто сайтов, да и фреймворков на пыхе. Куда он денется

      Заводишь сайт, в панели управления (ISP)- база пых. Но можно еще питон


    1. frt123
      17.08.2026 16:11
      #30341638

      программисты на Cobol грустно улыбнулись.


      1. Dhwtj
        17.08.2026 16:11
        #30344112

        программисты на Cobol грустно улыбнулись.

        Посмеялись, тряся седой бородой


    1. micronull
      17.08.2026 16:11
      #30341928

      Не вижу вообще ни одной причины начинать что-то новое на PHP.

      Не соглашусь. Стоит отдать должное, но PHP лучшее решение для CRUD панелей и админок.

      Сам гофер, когда-то давно свичнулся с php, но все еще тепло вспоминаю его.


      1. Spiritschaser
        17.08.2026 16:11
        #30342184

        CRUD панелей и админок

        Да вот как-то что-нибудь в стиле flask или вообще на c# по-приятнее будет...


  1. InsiderCrush
    17.08.2026 16:11
    #30340978

    Я вообще ничего не понимаю в PHP, но я радостью прочел статью и теперь что то знаю! Котики и другие мемы сработали :D


  1. HotFixer
    17.08.2026 16:11
    #30341094

    Пожалуй самый главный миф - "PHP медленный". Но если глянуть бенчмарки, из "большой тройки" скриптовых языков для веба (PHP, Python, Ruby) именно PHP является самым быстрым. Благодаря оптимизациям движка Zend и JIT‑компилятору в PHP 8, в сырых вычислениях и пропускной способности HTTP‑запросов PHP стабильно обгоняет стандартный CPython и Ruby.

    Уважаемый@MountainGoat, причин накидать прототип чего‑то нового на PHP и сегодня достаточно. А некоторые такие "прототипы" потом вырастают в весьма значимые проекты: Nextcloud, Tumblr, Badoo, BlaBlaCar, видеохостинг Dailymotion, Trivago.. И да, при росте масштаба вокруг PHP вполне могут появляться Java, Go, Node.js, Kafka, Elasticsearch и так далее - но это уже вопрос архитектуры.

    По поводу CMS. В нынешнее время особенно ЕС массово использует в своих правительственных и институциональных порталах Drupal. И, что интересно, это уже далеко не просто "старая CMS", а одна из самых активно развивающихся платформ. По данным из доклада на Пых.конф’25, за предыдущий год у Drupal было около 124 000 коммитов в ядро, 6 400 открытых PR и около 1 млн активных контрибьюторов, участвующих в ядре и связанных проектах.

    А ещё Drupal довольно интересно подошёл к AI. Причём речь не просто про "давайте прикрутим chatGPT" или очередной вайб‑кодинг. AI глубоко интегрируется в саму модель Drupal: агенты работают с контентом и конфигурацией, конфигурации представлены в YAML и могут проходить обычный Git/CI/CD workflow, а права агента можно ограничивать на уровне ролей и permission'ов самого Drupal. То есть AI может генерировать и изменять конфигурацию, но результат остаётся контролируемым, проходит ревью и деплоится обычным способом.

    В Drupal CMS 2.0, вышедшем в январе 2026 года, AI уже встроен в саму платформу, а не существует просто в виде внешнего чат‑бота.

    И есть совсем интересные проекты вроде Boson - runtime/toolkit, который позволяет писать кроссплатформенные desktop‑приложения на PHP с привычным HTML/CSS/JS, но без Electron и Node.js. PHP runtime, код приложения и необходимые компоненты собираются в единый исполняемый файл, который можно распространять без отдельной установки PHP. Есть интеграции с Symfony и Laravel.

    Интересный факт) А вы знали, что основа "той самой" Pornhub - это проверенная временем связка: Nginx, PHP, MySQL, Memcached и Redis? Вот интервью (от 2019 года) с разработчиком. Позже по мере роста нагрузки к этому стеку добавили ElasticSearch, Node.js, Go и Vertica.

    И это далеко не застой: PHP продолжает развиваться - улучшается производительность, типизация, обсуждаются generics, data classes, async и новые возможности рантайма. Так что хоронить его, похоже, ещё рановато.


    1. edogs
      17.08.2026 16:11
      #30341300

      PHP продолжает развиваться

      Это сильно зависит от того, что считать развитием. Мы начинали в 90-тых с ассемблера, потом паскаль, с, с++, ява. Потом подзанесло на пхп и на нем очень надолго застряли, т.к. веб, а потом старые проекты, легаси, сарафанное радио, в общем с этой иглы уже не слезть было. А игла была прикольная, т.к. то за что вечно ругали пхп - типа отсутствия строгих правил и типизации и прочего - позволяло писать лаконичнее там, где на альтернативных языках нужна была простыня.

      И таки вот что мы имеем сказать. Пхп3 был первой версией которую можно было серьезно использовать. Пхп4 расширил язык до очень многих нужных вещей не потеряв идеологии. Пхп5 стала версией в которой исправили много недостатков и добавили много важных вещей не изменяя сути и...
      .... тут язык стал сильно популярен и в него пришли профи "из взрослых языков", чьи языки для задач что решал пхп не очень подходили, но это не мешало профи критиковать пхп за то, что он "не их взрослый язык" (по типу прийти в чужой монастырь и удивляться недостатку в видео отсутствия телека с порноканалами).

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

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


      1. Sheti
        17.08.2026 16:11
        #30341566

        Для Java пойди найди программиста за разумные деньги. Плюсом память жрёт. С точки зрения бизнеса PHP выгоднее. Всегда найдёт человека на поддержку за адекватную з/п.


        1. edogs
          17.08.2026 16:11
          #30344914

          Нуууу, спорно.
          С точки зрения бизнеса вход в пхп действительно ниже, но прогера на серьезный проект на пхп найти сложнее чем прогера на серьезный проект на яве, т.к. как только речь идет о серьезности - все мигрируют с пхп. Поэтому тут надо разделять аудитории.
          Что касается пожирания памяти, то это опять же ситуационный вопрос. Базовый инстанс пхп запустить дешевле, но если речь об обработке больших данных нативно (без хаков, трюков, ручной работы и специальных либ), то у пхп такой большой оверхед, что как только заходит речь о big data то ява явно смотрится выгоднее по памяти чисто из-за меньшего оверхеда на хранение.
          То есть ситуация опять же сводится к тому, что если речь про простой проект (что было изначальной фишкой пхп) то пхп все еще бьет и яву и всякие питоны - потому что у него все еще есть в активе изначальное наследие, но в серьезных проектах он все же сливает (несмотря на все попытки дрифтовать в сторону явы), что по цене исполнителя, что по цене железа.


      1. ViskasSP1vom
        17.08.2026 16:11
        #30341910

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


        1. edogs
          17.08.2026 16:11
          #30344918

          Это как говорить, что матиз умер бы, если бы таксопарки начавшие с него перешли бы на мерседес, вместо попытки модифицировать матиз.
          Но по факту и таксопарки проигрывают (т.к. до Е-шки не дотягивают) и матиз потерял идентичность (т.к. стал дороже и сложнее).
          По нашему кругу - большинство мигрирует с пхп именно потому, что он стал избыточно переусложненным и зарегулированным, при чем мигрируют как раз на менее строгие языки.


      1. micronull
        17.08.2026 16:11
        #30341966

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

        Ровно тоже самое думаю и я. Они реально хотят сделать интерпретируемую яву, при этом сохраняя обратную совместимость! Зачем это все? Не проще тогда взять Java с её зоопарком JIT?

        Главная сильная черта PHP - можно взять коробочное решение и за пять минут развернуть на хостинге (даже не VDS). Форум (еще помните что это?), сайт, интернет магазин, админка с backend api... Как платные так и opensource. На любой вкус и цвет.

        Нет решения? Берем yii3, симфони, ларавел - один день и готово. Дальше напильником.


        1. gian_tiaga
          17.08.2026 16:11
          #30344038

          Php лучше java. Посмотрите на количество и качество решений которые есть в пхп. На выбор инструментов, в java такого нет.


      1. Dhwtj
        17.08.2026 16:11
        #30342658

        дрифт в сторону в попытке сделать из него нечто типа явы в упрощенном и убогом варианте

        В нормальном варианте, но die fast

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


        1. Free_ze
          17.08.2026 16:11
          #30343370

          не взял её главную цену: долгоживущее состояние, пул потоков с разделяемой памятью.

          Это зависит от реализации, тот же PHP-FPM работает на пуле процессов и после запроса воркеры у него не обязаны умирать, так что утечки всё еще возможны.

          Но нет, быстрый in-process кэш за это не получишь - будь добр какой-нибудь редис рядом затащить там, где Java обойдется ConcurrentHashMap.

          любой запрос поднимается в чистой среде, падение одного не роняет соседей

          Падение отдельных потоков не роняет соседей и хостовой процесс.

          деплой это замена файлов, а не перезапуск JVM с прогревом.

          Зато получили неочевидную проблему разъезда старого опкеша и новых файлов при деплое копированием.


        1. edogs
          17.08.2026 16:11
          #30344936

          В простых проектах - да.
          Но хоть сколько-нибудь в сложных проектах начинается вопрос о постоянных соединениях в БД, об опкеше, о запуске пхп-фпм, о постоянном процессе пхп для обработки текущих данных в очереди и в результате "дай фаст" идеология вырождается в скрипты, которые лишь обрабатывают входящий запрос от пользователя, с которым потом разбирается большой жирный бакэнд. И самое смешное, что даже мы, фанаты пхп с 20+ летним стажем, этот бакэнд предпочитаем обрабатывать на чем-то отличном от пхп. И не потому что пхп был изначально плох для этого, а потому что текущий пхп превратился в урезанную версию более навороченных языков.
          Последний наш проект это пхп на фрондэнде и банальный c# на бакэнде. Где роль пхп сводится к CRUD, а сложная обработка данных вся делается на C#.. Лет 10 назад нам бы такое и в голову не пришло. А сейчас это реализуется прямо таки сходу, т.к. банально php на бэке для нас ощущается как язык такой же сложный и ограниченный как C#, но при этом без функционала, либо и возможностей последнего.


      1. dad1
        17.08.2026 16:11
        #30343242

        т.к. а на фига писать на "упрощенной яве", если есть нормальная?

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


        1. Free_ze
          17.08.2026 16:11
          #30344602

          Сейчас полноценный VPS можно до ста рублей взять, а по цене чашки кофе уже предложат 4 Гб RAM. Туда небольшой проектик в докере влезет, не то, что джава. Копеечнее только бесплатно.


        1. edogs
          17.08.2026 16:11
          #30344938

          Не согласимся.
          Если у Вас посещаемый проект на пхп, то вирт. копеечный хостинг это в любом случае не для Вас. А если Вы купили хостинг подходящий для посещаемого проекта на пхп, то и ява там отлично заведется и будет чувствовать себя неплохо.


    1. Free_ze
      17.08.2026 16:11
      #30342308

      PHP продолжает развиваться

      типизация, обсуждаются generics, data classes, async

      Язык догоняет мейнстрим с добрым лагом в 10-20 лет по фичам, при том не предлагает ничего нового и уникального.


    1. becefi
      17.08.2026 16:11
      #30342760

      "PHP медленный"

      Где то видел, что PHP в 10 раз быстрее Python.


      1. GreenFox_2003
        17.08.2026 16:11
        #30343750

        ну, питон сам по себе достаточно медленный


      1. edogs
        17.08.2026 16:11
        #30344940

        Пхп начиная с 7-ки реально очень быстрый.
        Пожалуй самый быстрый среди интерпретируемых, а за счет по сути реалтайм компиляции - вполне конкурент и компилируемым языкам.
        Единственное что ему портит эту скорость, это манера некоторых либ и цмс встраивать исполняемые куски кода на ходу, компиляцию которых эакэшировать невозможно. Но это встречается все реже и реже.


  1. alexhu
    17.08.2026 16:11
    #30341496

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

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

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


    1. leshchev-artem
      17.08.2026 16:11
      #30341822

      В php типизация не строгая.


      1. alexhu
        17.08.2026 16:11
        #30344620

        В php типизация не строгая.

        Могу немножко поспорить, только это уже не важно. Динамической типизации хватает.

        И по поводу того что типизация не строгая - ну можно же включить строгий режим declare(strict_types=1) ? Только всё равно получим "условно строгий" режим, который не всегда срабатывает.


    1. edogs
      17.08.2026 16:11
      #30344952

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

      Вооот, типичная точка зрения яваиста, которая и привела текущий пхп к его проблемам.
      То что многие называют пороками пхп - является его плюсами и особенностями, попытка в 7 и 8 версии от них избавится - убивает сейчас сам пхп делая из него жалкое подобие явы. Это как взять хаски, посадить его в квартиру и заявить что большое количество его энергии это недостаток:)

      То что там есть cms - на них язык и выехал.

      Вот только тут другая причина следствие. Именно благодаря особенностям пхп (которые Вы называете пороками) и стало возможно большое количество (в т.ч. качественных) цмс на нем. ЦМС на яве не не появлялись не потому что "так сложились звезды", а потому что ява был язык не особо для этого годный.
      Язык пхп выехал не за счет цмс, цмс появились за счет особенностей пхп.


      1. alexhu
        17.08.2026 16:11
        #30347618

        типичная точка зрения яваиста

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

        Я не сравнивал php ни чем, кроме самого php. PHP разрабатывался транслировать код в html и всё. Потом уже начали его дорабатывать до языка общего назначения - практика показала, что этот язык почти всегда используют для веба.


        1. edogs
          17.08.2026 16:11
          #30348182

          Вычисления на php делать очень неприятно из - за динамической типизации

          А в чем конкретно тут проблему Вы видите? Ну не складывайте строки с числами и всего делов, к тому же ситуация всяко лучше чем в том же яваскрипте:)
          А если про большие и точные вычисления, так есть же стандартный модуль BCMath.


          1. alexhu
            17.08.2026 16:11
            #30348344

            А в чем конкретно тут проблему

            Язык php не позволяет однозначно описать инструкцию по выполнению кода.


  1. francyfox
    17.08.2026 16:11
    #30341568

    Основная причина жизни пыха Лара и вордпресс, пока они не сдохнут, трухлявый слоник будет жить. headless cms и nodejs могли бы заменить, но везде принцип "Не трогай, если работает"


    1. dad1
      17.08.2026 16:11
      #30343480

      1) Что мешает делать headless cms  на php? Read only классы удобны для DTO, сериализуй в Json и отдавай их в асинхронный JS.
      2) Медианная посещаемость среднестатистического сайта(не запаркованный домен) - ~10 хитов в час. Не в секунду. На такой нагрузке не будет никакой разницы между веб-ресурсом, работающем на Go и на PHP c OPcache и Redis. Совсем никакой с учетом сети(десятки мс) и БД(дестяки мс).
      И напомните, сколько там папка node_modules весит?
      Делать SPA, конечно, стильно-модно-молодежно, но зачастую - это стрельба из пушки по воробьям, учитывая реальные нагрузки веб-ресурсов.


      1. francyfox
        17.08.2026 16:11
        #30345168

        1) мне никак, скажи это остальным) я сейчас посмотрел, есть к примеру craft cms на php, но узнал про него сейчас из гугл запроса, а не из описания вакансии. Пару лет назад я вообще не мог найти ничего похожего на strapi в мире php. На пыхе только одна
        нормальная админка, все остальные платные. И то ее нужно сильно допиливать.

        2) node_modules весит от 500 мб, да это плохо (забавно, но ничего хорошего нельзя сказать и про композер, который отваливает деплой ларавел). Но для прода она нам не нужна, все упаковывается в dist. Я сказал про nodejs, потому что это реально альтернатива для быстрого входа, конечно rust намного лучше
        Помимо SPA есть еще SSG (он же тот же режим пререндера что у php, аля получаем статику) и SSR.

        Проблема в массовом потребителе языка php, а не в самом php. Мне нравится Symfony и Drupal, но увы их редко встретишь, а встречаешь везде сраный вордпрес и ларавел. Не спорю, у nodejs тоже беда, express и nestjs. На nodejs я хотя бы буду уверен что чувак слышал про openapi и поделиться типами, а среднестатистический пыхер чувак пускающий пузыри из носа, ломает деплои и у него вечная нехватка памяти при генерации фидов


  1. Artem1980
    17.08.2026 16:11
    #30341844

    Потому что куча легаси кода...кому то ж его надо поддерживать


  1. ViskasSP1vom
    17.08.2026 16:11
    #30341858

    Большинство хейтеров пыхи последний раз видели ее на версии 5.3 в виде самописной админки. На современном Symfony или Laravel писать сейчас приятнее, чем на половине модного js-стека, где зависимости ломаются каждую пятницу)


    1. PiramidHead
      17.08.2026 16:11
      #30342210

      Не соглашусь. Есть ещё те, кого, видимо, задевает, что бизнес не очень хочет платить за разработку 100500 денег просто потому, что она ведётся на Java/Go/etc. А также есть те, кто почему-то отталкивается от инструмента, а не от задачи.


    1. Free_ze
      17.08.2026 16:11
      #30342470

      Большинство фанов повторяют мантру о том, что PHP уже не то говно, что было раньше. Но если объективно: что уникального может предложить PHP в 2к27?

      • Языковые возможности? Так PHP едва догоняющий.

      • Убийственную производительность? Нет, определенно: тут уже Go. Если логика сложная - Spring Boot или ASP.NET Core.

      • Невероятный DX? Fullstack-фреймворки на JS зарулят.

      • Ошеломляющее количество специалистов на рынке? Джаваскриптизёров всё равно больше.

      Единственная суперспособность - программирование в стиле “Как раньше”: кастомизация готовых CMS, правка скриптов на проде голыми руками.


      1. Dhwtj
        17.08.2026 16:11
        #30342636

        Тулинг он может предложить

        Смотри выше


        1. Free_ze
          17.08.2026 16:11
          #30342692

          Если вы про этот коммент, то это ж буквально мимикрия под JSDoc. Мой вопрос был про киллер-фичи, которых (еще) нет у мейнстримовых технологий, что заставило бы выбрать именно PHP.


          1. Dhwtj
            17.08.2026 16:11
            #30342710

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

            Я уже потыкал в недостатки Go, которых нет в PHP. Могу потыкать в другие языки.

            И, да, с нуля я бы PHP не выбрал. Но бежать переписать старые 15 летние системы я не собираюсь. Среди них имеются и денежные, с нормальными стабильными бюджетами


            1. Free_ze
              17.08.2026 16:11
              #30342924

              Ценны эти возрастные системы, а не PHP. Если для таких проектов никто больше не будет выбирать этот язык, это и есть смерть.


              1. Dhwtj
                17.08.2026 16:11
                #30344044

                Нет

                Я могу сделать приличный рефакторинг PHP систем и будет вполне себе DDD.

                Вот на Go было бы больше мороки

                Ну а если какой-то дурак на микросервисы порезал не по границам доменов, то вообще геморрой


                1. Free_ze
                  17.08.2026 16:11
                  #30344226

                  Ну что ж сразу с синтаксическими инвалидами-то мериться в DDD? Берите Java или C#.


      1. gian_tiaga
        17.08.2026 16:11
        #30344064

        Назовите чего в пхп нет?

        Скорость? Есть, берете не умирающий родранер или вообще свуль.

        Количество инструментов - больше чем где либо.

        Количество специалистов, полно.

        DX и рядом не стоял с пхп решениями.

        Так в чем пхп догоняющий?

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

        Так что попипшите на пхп потом вернитесь на свой стек и тогда поговорим


        1. Dhwtj
          17.08.2026 16:11
          #30344144

          Кеширования состояния между запросами нет.

          Ну, то есть можно редиску прицепить, не пробовал...

          А если вдруг надо держать состояние объекта,а не просто данных, то ещё грустнее


        1. Free_ze
          17.08.2026 16:11
          #30344260

          Зачем строить монстра из инфраструктурных костылей, если можно не строить?


  1. MrShnaider
    17.08.2026 16:11
    #30344850

    По моему мнению, живучесть и популярность PHP объясняется очень просто. Это единственный язык, который работает из коробки с web'ом.

    Этот язык точно знает "кто он" и "для чего будет использоваться". Сразу после установки программисту доступны: dev сервер, интерфейсы для работы с HTTP, шаблонизатор для HTML, плагины для СУБД и т.п. И всё это интегрировано в язык, и поддерживается языком на уровне синтаксиса.

    Вам не нужны никакие дополнительные библиотеки или фреймворки, чтобы начать писать web-приложение. И на такой крепкой основе сделать обёртку, по типу Laravel или Symfony, намного легче, чем для языков общего назначения.

    То же самое было и с языком C, пока не появился Rust. C тоже знал "кто он" и "для чего он". Его используют как замену ассемблера, для доступа к железу, но со структурной парадигмой. Он популярен по той же причине, что и PHP. И смещает его сейчас язык, который позиционирует себя точно так же.

    Исходя из этого мой прогноз: PHP продолжит жить, пока не появится новый улучшенный язык, заточенный под web


    1. edogs
      17.08.2026 16:11
      #30344956

      Это единственный язык, который работает из коробки с web'ом.

      Ну вообще-то нет. Го, питон и ноде достаточно спокойно работают из коробки с вебом. При чем питон/джанго сейчас больше продвигается в массы (в том числе в школах/колледжах), а ноде/яваскрипт имеет бОльшую "совместимость" с фрондэндом, поэтому пхп сейчас для веба выбор уже отнюдь не однозначный.


      1. MrShnaider
        17.08.2026 16:11
        #30347936

        Максимум, что могут сделать эти языки из коробки - это обработать HTTP запрос. У них нет нормальной поддержки механизма сессий, драйверов для СУБД, у Python и Node нет HTML шаблонизаторов, а обработка HTTP запросов и ответов донельзя низкоуровневая.

        Так что из коробки PHP их всех обходит.

        Единственное, что Node/Deno действительно используют JS/TS, что позволяет писать и фронт и бэк на одном языке. Это большущий плюс