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

Поспорить о чем ты с чатом жопити предлагаешь?

Каким образом ты привязал маркетолога к вордпрессу? А почему не бухгалтершу? Не кладовщика? Бухгалтерши и кладовщики тоже наслышаны про битрикс, opencart и wordpress.

Я пару раз пересекался. Один раз вирус вычищал, другой данные с него забирал. Не уж то там смогли жостко ограничить все и запретить пользоваться теми или иными методами PHP :) Может быть конечно, но прям как то сомнительно... (впрочем мне не интересно - у меня по битрикс задач выше крыши, т.е. читать не буду, но вот прям по принципам построения веб CMS не верится, что нет нормальных точек расширения)

Это одна из двух основных "предъяв" в к нему в любом споре от "трупрограммистов" :)  

Ну т.е. если я напишу цикл с 10 вложенными циклами где на каждом уровне будут запрашиваться данные (с сложными рандомными условиями и без ключей миллиарды записей и без кеширования) - фастапи все порешает? :)

Тут, на мой взгляд, все та же история с вопросом на сколько низкий уровень выбирать при разработке. Согласись - самый быстрый результат (в плане быстродействия работы) может дать именно "разработка с ноля" :)  причем писать забив на всякие паттерны, лапшой и с дублированием кода. Универсальность это всегда дополнительные расходы. Только вот скорость разработки и внедрения....

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

Вообще я подобные споры уже проходил (и тут на Битрикс очень многие катаят, правда  большинство просто "как все" не имея аргументов). И в основном когда более-менее грамотные предьявы - предъявяющий занимается в проектах чуть ли не типа ВК :)  Т.е. в проектах где совсем другие критерии нагрузок, чем на среднестатистическом сайте

Да верно. Это совершенно распространенное решение. "Headless" режим. Тоже кстати, знаю потому, что к Битрикс тоже предъявляют, что он так не умеет. (хотя тоже делают, и даже не то что какие то под проект решения, а даже на маркете готовые шаблоны для ИМ есть, где фронт на ноде)

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

Так же дополню.

Для начала по самим языкам. Тут чисто по памяти в этом году видел несколько бенчей которые показали что PHP8.* быстрее чем Питон

Тыц 1  Тыц 2 

Далее FastApi не совсем корректно сравнивать с CMS

Тогда надо например брать RoadRunner + фреймворк какой либо . Как вариант Laravel Octane.  

Так же есть FrankenPHP.  А еще есть kPHP.  

Ну а далее (скажу честно лень было гуглить спросил у ИИ расклад)

• FastAPI ~ 50-100k req/s (на мощном железе).
• Laravel Octane ~ 20-50k req/s.
• kPHP может легко делать 100k+ req/s на том же железе,

Ну и далее технический момент который привносит в проект использование FrankenPHP, RoadRunner и, полагаю судя по принципу, FastAPI  - появлется вопросы к которым надо ответственнее относится. Я про те же утечки памяти, т.е. надо внимательнее к коду относиться, причем некоторые вещи на уровне понимания должны быть, т.к. отладить их сложнее.  

Про фаст апи сам я не знаю, потому спросил у ИИ:

В Python (FastAPI / Uvicorn):

1. Циклические ссылки: Python использует подсчет ссылок + GC. Если объект A ссылается на B, а B на A, они не удаляются сразу. В долгоживущем процессе это накапливается.
2. Глобальные переменные модулей: Аналог static в PHP. Данные, записанные на уровне модуля, живут весь жизненный цикл процесса.
3. Незакрытые соединения/ресурсы: Если не использовать async with для баз данных или HTTP-клиентов, соединения могут висеть в пуле или утекать.
4. Event Loop блокировки: Хотя это не утечка памяти, но "утечка" производительности. Тяжелые синхронные операции в async-коде тормозят весь поток.

Я правильно понимаю - Вы предлагаете заниматься ручной работой в век когда всё пытаются автоматизировать? И это ради чего? Чтобы в тот же век 5g сетей и 5-ти гигабайтного интернета сократить fttb на миллисекунды?

Просто ради интереса спрошу - скольким проектам из 1000 понадобиться описанные Вами "преимущества"?

Я так же мог описать преимущества PHP перед Python, про быстродействие и тд. но это уже всё жёвано-пережёвано и не раз. Всё и так очевидно.

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

ЗЫ. Sly32, ты как школьник реально, у тебя есть лишь какие-то свои фантазии и ты хочешь чтобы другие люди поверили в них. Но это так не работает(я знаю, тоже наступал на эти грабли). Если ты уверен, что FastApi лучше и тд. продемонстрируй это, создай свой продукт и покажи. Тогда к тебе будут прислушиваться, а так ты только воздух сотрясаешь.