Это – одни из самых популярных JavaScript-библиотек в мире. Взгляните на этот список, посмотрите их репозитории на GitHub.

А зачем нужны 5 классов «встроенного autoload» если в конце он все равно вызывается spl_autoload_register?

Давайте рассуждать. У нас есть spl_autoload_register который позволяет нам сделать цепочки автозагрузчиков. Почему нам важны цепочки? Потому что разные модули нашего проекта, не важно наши они или third-party, могут иметь свои правила автозагрузки (например у вас есть старый модуль из эпохи php5.0 бэз нэймспейсов и новый красивый из эпохи 7.0). Это упрощает использование модулей. Мы просто подключаем автозагрузчик модуля и "едем дальше" вместо того что бы каждый раз вкручивать его в проект.

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

Что мы можем сделать с composer за одну минуту. Описать PSR-4 автозагрузку или прописать инклуды, и вызвать команду composer dump --optimize --no-dev --classmap-authoritative. Что дает нам эта команда:

• опция --optimize и --classmap-authoritative позволит нам составить классмэп (какой класс в каком файле искать), что бы не нужно было вычислять это каждый раз и трогать лишний раз файловую систему. Максимально эффективный способ.
• опция --no-dev выкинет все зависимости которые нам требуются для разработки (phpunit например или тэсты) из мэпы классов.
• если у нас миллион зависимостей и узким местом становится инициализация классмэпа, есть другая стратегия, которая позволяет использовать apcu и кэш в рантайме. Для маленьких проектов это не самый эффективный вариант, а вот для большших может быть спасением.

И все это вы получаете… просто так из коробки. Подходит как для маленьких так и для больших проектов. Эфортов разработчика — минимум. Так почему бы не юзать?

Но в чем круть от писанины автора: «return new JsonResponse(...)», вместо return json_encode(...) ?!

скорее вместо:

header('Content-Type: application/json');
echo json_encode($data, JSON_HEX_TAG | JSON_HEX_APOS | JSON_HEX_AMP | JSON_HEX_QUOT);
fastcgi_finish_request();

Раз уж вы о производительности заботитесь. Что будет быстрее, записать в поток 2 раза по 100 байт или 1 раз 200? И сколько это по времени если сравнивать с инстанцированием объектов?

ну и опять же, JsonResponse хэндлит еще и варианты для jsonp (вдруг кто-то тут еще под ie6 пишет), что руками делать уже ой как не удобно.

А если этот никчемный класс (JsonResponse) порождается 100 раз в секунду?

разница между простым вызовом json_encode будет ажно целый порядок, 10^-4 ms vs 10^-5 ms. Экономия на спичках.

ЗЫ. Давайте не забывать, что PHP — язык рожденный умирать! А OOP — это всегда медленно…

рожденный ползать летать не может? С тех пор как PHP родился его нутро пару раз переписывали уже. В данный момент он вполне себе может не умирать. Да, пока плохо с инфраструктурой, но если у нас например запросы на чтение (а их обычно большинство), выборки какие-нибудь, можно взять react или php-pm и радоваться жизни.

Некоторые для этих целей берут nodejs например (то есть запись происходит в php, там формируется набор событий. строится проекция на какую-нибудь монгу или эластику, а node через graphql отдает данные).

А OOP — это всегда медленно…

Не совсем так. Медленно — динамическая диспетчеризация, когда вам надо в рантайме соответствия искать кто кого вызывает. Эти вещи решаются различными инлайн кэшами на уровне интерпретатора (JIT, который обещают впилить в php8, вполне способен на подобные оптимизации). А все остальное — не отличается по производительности.

А хайлоад… это надо быть в top 100 по нагрузкам ресурсов что бы "ООП" стало узким местом. Намнооого чаще узким местом становится кривая архитектура.

Это смотря какое приложение. Да и фреймворки разные есть. Тут больше важно что нужно знать современные концепции и стандарты современного веб приложения. Вот composer — да; PSR'ы; Неймспейсы; Автолоадинг; Система контроля версий; Единая точка входа; Паблик директория; Роутинг; Шаблонизация; Query builder. Остальное имхо опционально.

И если уж говорить о самой статье, то замените symfony на laravel и react на vue. И статья выйдет короче)

semanage fcontext -a/-d -t httpd_cache_t "/srv/http/cache(/.*)?"

chcon ...

restorecon -R /srv/http/cache

foo@kopoba~/go/src/github.com/fattyproject$ go build; ls -la fattyproject 
-rwxrwxr-x 1 foo foo 13409025 Feb 28 17:18 fattyproject


foo@kopoba~/go/src/github.com/fattyproject$ go build -ldflags "-s -w"; ls -la fattyproject 
-rwxrwxr-x 1 foo foo 8939968 Feb 28 17:18 fattyproject

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

вопрос с софтом закрыт

"telemetry.enableTelemetry": false,
"telemetry.enableCrashReporter": false