Дархан

Для начала почитайте что такое SAPI. Затем представьте что apache + mod_php разделили на web-сервер, который проксирует запросы на php-fpm и отдает статику, и собственно отдельный web-сервер который имплементит SAPI и выполняет запросы связанные только с php. То есть статику отдавать мы можем только через php. Суть примерно та же что и у apache2 + prefork + mod_php но оптимизированный только для работы с php. Так же можно поставить на фронт более быстрый и легковесный сервер который умеет проксировать запросы.

То есть php-fpm это эдакий fast-cgi сервер который постоянно держит готовые для работы пул-процессов (сколько в пуле процессов настраивается, так же как и от какого пользователя их запускать и все такое прочее). Каждый новый запрос уходит в какой-либо процесс из пула, запрос отрабатывает, возвращаем результат тому кто попросил (web-серверу обычно). Если процесс падает (fatal допустим) - поднимаем новый.

Принципиальной разницы между apache2+mod_php нету, просто упрощается инфраструктура. Наш web-сервер должен только уметь проксировать запросы и отдавать статику, а php-frpm вообще может быть на разных машинах (балансировщиком можно раскидывать запросы). Ну и сами понимаете, nginx + php-fpm будет быстрее обрабатывать запросы чем apache2+mod_php какой бы мы менеджер процессов не использовали в апаче. Минусов по сравнению с apache+mod_php я даже не могу предложить.

А php-runtime не зависит от этого. Он один на всех, CLI, FPM, mod_php...

И тот и другой инструмент под свой круг задач вполне подходит.
Livewire - как вам ответили выше, хорошо подходит mvp, небольших сайтов, где нет большой нагрузки и грандиозных планов.
Хотя кто-то берет на себя риски и делает все на нем. Из подводных камней, это у вас связаны руки в js, так же на каждое действие, он будет слать запрос на сервер. То есть написали букву в input, запрос на сервер(хотя можно оптимизировать, но тем не менее), в итоге получается такой оверхед на все.
Стоит иметь в виду о смеси ответственностей, точнее livewire будет вас постоянно склонять к этому, так как в классах php у вас постоянно логика фронта.
Еще могут быть не очевидные проблемы, при синхронизации данных, и вам надо будет подставлять задержки.
У меня была проблема с загрузкой файла, в кратце есть две настройки в вашем php.ini и отдельно в файле livewire, в каждом стоит свое максимальное значение размера файла.
Так вот- грузил я картинку по событию change, после загрузки была написана валидация, в кратце файл не грузился и в блок с валидации было пусто.
Проблема заключалось в том, что livewire не как об этом не сообщал и не намекал, просто не грузил файл и валидация не проходила.
Так что будьте готовы решать такие нюансы.
Мой субъективный опыт получился двоякий, с одной стороны мне понравилась скорость, с другой стороны что-то не работает, возможно это временно пока все шишки не набьешь.

С Inertia опыт пока только теоретический, но он уже ближе к нормальному стеку. Просто вам не надо думать о роутинге, api, вывода ошибок.
Врать не буду, ибо фраза:

В теории нет разницы между теорией и практикой. А на практике есть

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

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

PHPStorm 7
Preferences (или Settings) > Секция Project Settings > Пункт Code Style > Подпункт PHP > Вкладка Other > Чекбокс Align key-value pairs

Я сталкивался. Решение проблемы - берете и пишете видео (прямо на устройстве через запись экрана), приаттачиваете, посылаете. Если косяков нет, вам вскоре одобрят релиз.
На каждый релиз писать видео не придется, во всяком случае у меня такое было только раз (а обновлений после того случая было много)

Для Debian или Ubuntu попробуйте установить libpq-dev.

Можно, но не нужно.
Ваш громкий "опыт работы 3 года", далёк от реалий. Да и на плюсах не так много заказов

Зачем нужны машины, если есть трамваи?

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

Макет класса, в свою очередь, можно принимать в параметры методов и сам макет предназначен что бы изолировать часть класса и не создавать лишних зависимостей. Зависимость на Абстракциях. Нет зависимости на что-то конкретное.

Представь, у тебя есть класс А с методами M1 и M2, с которым работают 3 других класса. Первый класс использует только метод M1, второй только метод М2, третий M1 и M2. Если ты просто передашь им в параметры класс А, то первые 2 класса будут зависеть от методов которые они не используют. Какой выход? Создай 3 интерфейса - для каждого класса и передавай их. Тогда классы использующие класс А не будут зависеть от того что не используют.

Я знаю два способа:

1. Простой:
   
   1. Создаёте переменную loading.
      
   2. Перед отправкой запроса выставляете значение loading = true.
      
   3. После отправки в секции finally выставляете значение loading = false.
      
   4. В самом шаблоне смотрите на этот переключатели и отображаете загрузку
      
   
   
   
2. Сложный, но более надёжный
   
   1. Используете xstate для управления состояниями вашего компонента.
      
   2. В самом шаблоне смотрите на текущее состояние и отображаете загрузку
      
   
   

UPD
Очень советую этот доклад по теме

У каждого своя причина. Кто-то выгорел, кто-то просто устал. Со временем понимаешь что зп это не главное, да и зарплата в IT не такая уж и большая. И что ты каждый день сидишь по 14, 16 а иногда по 18 часов в день перед монитором. Никакой физической активности. Решаешь какие-то странные хочухи клиентов. Результат твоей деятельности мало кто увидит, большая часть твоего кода уйдет на помойку. Что каждый день выходят новые языки, фреймворки. Что количество данных, которые нужно пропускать через мозг, растет с каждым днем. А мозги только стареют. Помнишь Ваас рассказывал про безумие? Так вот, это оно. Каждый день ты залипаешь перед монитором, пытаясь решать кем то придуманную проблему. У тебя уже искривление позвоночника, зрение -5, туннельный синдром где-то не за горами. А ничего, кроме как пялиться в монитор, ты не умеешь.

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

1. Фрилансер - это черная дыра. Нет никаких гарантий, что вы с первого раза найдете хорошего специалиста. Вы потратите массу времени походив по рукам как портовая путана, потеряете массу времени и сил. В итоге скорее всего специалиста вы найдете, но какой ценой?

2. Нет слово бесплатно. Бесплатно будут работать только молодые специалисты, которых вы воспитаете. И то не долго, постепенно их интерес и отеческие симпатии пропадают, люди имеют свойство развиваться.

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

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

const routes = [
...
  { 
		path: '/404', 
		name: '404', 
		component: NotFound, 
	}, { 
		path: '*', 
		redirect: '/404' 
	}
]

единственный надёжный вариант - слать скриншоты низкого качества.
всё остальное не спасет от ушлых.

а вообще, есть золотое правило: "не работать с мудаками". правда вырабатывается оно не сразу.