Сергей delphinpro

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

По делу: да, проблема есть, именовать на больших проектах сложно. Решений нет.
Вернее, только те, которые вам кажутся "грязными", но других не завезли (и не завезут).
И те, которые не относятся к разработке (вроде "дать люлей дизайнеру, который не понимает, как это всё работает, и лепит каждый элемент как попало")

Тут просто надо несколько абстрагироваться и принять то, что абсолютно в любой объёмной системе, даже если её вдруг пишет один человек (что вряд ли), всегда есть место неочевидным вещам. Перфекционист внутри рыдает, но что делать.

Откройте любое масштабное решение - чёрт ногу сломит, не так ли? И требуется немало времени, чтобы вникнуть. Потом вникаешь - и становится проще, но всё равно много нагромождено. А если выпасть из контекста на месяц - потом опять заново вникать. Это норма (картинка с Малышевой).

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

Совмещение ваших пунктов 1 и 3 в одно - вполне здоровый стиль.
Если секция, где всё очевидно: about, gallery, text-section, etc.
Если контент неоднородный - именовать по смыслу (как в 3).

Единственное что мог бы посоветовать - не смущаться добавлять новые компоненты, задавая им какой-то дополнительный неймспейс (contacts-header, contacts-about), а не пытаться всё упихать в один общий с помощью модификаторов - в поддержке будет проще.

Просто размышления от прочитанного:
1. Подходы 2 ("section-1", "section-2") и 4 (атомарщина) - в аду для таких "специалистов" стоит отдельный котёл. Ну вы и сами понимаете. Использовать нужно никогда.
2. Инкапсуляция имён ничего не даёт в этом отношении, так как это придумано для элементов внутри блока (а с этим и концепция БЭМ хорошо справляется), глобально вам как разработчику всё равно нужно иметь понятное "корневое" название блока.

Ещё можно поработать со своей головой, возможно, что такой крик души идёт от страха быть осуждённым. Браузеру-то всё равно, вы ему хоть .qwerty123 { ... } скормите - нормально отобразится.
Понятные имена - для разработчиков, и надо понимать, что ни один толковый разработчик в вас камнем не бросит за то, что вы дали блоку имя .contacts-footer-call-to-action, если у вас этот самый .call-to-action в каждой секции настолько разный, что в один компонент не умещается.
Иногда помогает, если есть прямой выход на клиента или ЛПР донести, что такой дизайн... Ну не самый лучший для поддержки, и обосновать почему.
А чисто технически - решений нет, ну, вот такая работа, чё делать.

data() {
    return {
        showMobileMenu: false
    };
},
mounted() {
    const mediaQuery = window.matchMedia("(min-width:768px)");
    this.showMobileMenu = mediaQuery.matches;
    const listener = e => this.showMobileMenu = e.matches;
    mediaQuery.addListener(listener);
    this.$once('hook:beforeDestroy', () => mediaQuery.removeListener(listener));
}

Да, всё так как вы описали.

Насчёт OAuth конечно я бы не сказал, что прям это супер обязательно, иногда можно прибегнуть просто к jwt токену. OAuth по мимо безопастности даёт ещё много преимуществ, например как единый сервер для авторизации пользователей для множества проектов. Как по сути всякие соц. сети дают возможность. Если у вас простой проект и в нём нет каких либо очень важных данных, то можно и без OAuth обойтись. Это просто моё мнение))

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

Поэтому, чтобы называться начинающим верстальщиком, тебе нужен как минимум базовый JS. Без него ты никому не нужен, даже гавностудиям. Его ты можешь получить на курсах и в свободном доступе. Да хотя бы тут. Материал годный, рекомендую.

Ну и напоследок, фронтендер = верстальщик, просто у нас в русском языке есть такой самостоятельный термин.

Так что я рекомендую закрыть этот минус и идти договариваться подмастерьем (джуном).

Если не обращать внимание на дурацкий пример (PDO прекрксно без твоей помощи справится с выбросом исключения, и echo $ex->getMessage();die(); - это полная бессмыслица, поскольку пхп опять же выведет сообщение об ошибке без твоей помощи) то ты просто не туда поставил закрывающую скобку. она должна быть перед catch

try {
        $db=new PDO($DSN, $db_user, $db_pass, $pdo_opt);

?>
бла блa бла
<?

} catch(Exception $ex) {
    обработка исключения
}

В общем, оставь пока исключения в покое, тебе не надо их ни бросать, ни ловить.

Лучше никак. Измените api так, чтобы получать json вместо html, и создавайте разметку из данных средствами vue.

Ну а так-то можно делегированием воспользоваться:

<div v-html="свойствоСодержащееHTML" @click="onClick">

methods: {
  onClick(e) {
    if (e.target.tagName === 'BUTTON') {
      const id = e.target.closest('.product').dataset.id;
      ...
    }
  },
  ...
},

https://jsfiddle.net/grfo05vm/

QUERY_STRING - всё что идёт после ?
REQUEST_URI - полный путь без домена

например для example.com/some/path/xxx.php?a=1&b=2 получим

REQUEST_URI: /some/path/xxx.php?a=1&b=2
QUERY_STRING: a=1&b=2

b-a первый класс школы, 1 сентября

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

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

1. dart-sass - reference implementation языка т.е. является образцом того как должен работать язык. node-sass binding libsass (реализации спецификации языка на C++) к node.js.
   
   dart-sass содержит в себе все последние фичи языка, к примеру там уже есть поддержка sass modules, libsass отстаёт, а node-sass отстаёт от libsass. За пруфами - сюда и сюда
   
2. libsass производительнее, местами - существенно. К примеру в моих тестах интенсивная работа с sass maps в libsass примерно в 10 раз быстрее чем в dart sass. Насчёт микросекунд - у меня есть проекты которые по 15-20 секунд компилируют только стили на node-sass, на dart-sass всё намного медленнее
   
3. Приведённые ссылки - сравнение тёплого с мягким. Есть реализации языков, а есть плагины для их подключения к различным сборщикам. sass - сама реализация языка, gulp-sass - binding для Gulp, sass-loader - binding для Webpack