Alex

Только не Yii2) это жуть, а не фреймворк.
Laravel и Symfony норм вполне.
И советую выучить хотя бы поверхностно любой язык где есть вебсокеты.
Тот же Node.js или Go довольно востребованы

инструменты разработчика в google chrome

см. также blisk

Все атрибуты надо индексировать / фильтровать поисковой машиной.
sphinxsearch.com/docs/current.html#attributes

Юзаю axios)) если у Вас грамотно написан код, то думаю за httpRequest ругать никто не будет. Кроме того если юзать fetch и dynamic import то у Вас будет возможность загружать полифил только там где fetch не поддерживается))

Можете. Только есть шанс, что Windows не загрузится. Всё зависит от загрузчика, если используется GRUB или иной линуксовый, нужно будет перезаписать MasterBootRecord или иным способом восстановить загрузчик Windows

https://github.com/dmitry-lavrik/smart-grid

Если не нужны фреймворки то делай следующее:
- у getbootstrap.com и прочих типа getuikit.com есть возможность взять только то, что тебе нужно
- https://getbootstrap.com/docs/4.4/layout/grid/ или https://getuikit.com/docs/grid
Сделай свой билд через yarn и webpack или же просто возьми grid

забудьте о системном пыхе.
homebrew и/или phpbrew решат все ваши проблемы.
ну, или какой-нить мамп для ленивых.

Исторически предполагалось что будут одинаково востребованы www.example.com, ftp.example.com, smtp.example.com и эти субдомены сделают обращения к ним более понятным для ученых которых работают с сетью (а ведь кому, кроме ученых может понадобиться интернет, правда?).
В наше время лучше предполагать введение адреса с www., просто добавить переадресацию на без-www, потому что во первых некоторые пользователи могут на автомате его добавлять, во вторых как дополнительный запас для распределения нагрузки: https://www.yes-www.org/why-use-www/

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

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

3 кейс.
Вы делаете несколько сложных сервисов и решаете распаралелить разработку на несколько команд. Одна команда делает "Кинопоиск", другая "Афишу". Все они обращаются к серверу авторизации из кейса 2 и бекендам из кейса 1.

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