Сергей delphinpro

Бонусом идёт то, что Windows не просто проставляет значение в соответствии с ОЗУ, а, через некоторое время, оптимизирует этот размер.

Потому что по недосмотру, undefined не зарезервированное имя (как, например null) и кто-то может написать undefined=42.

Поэтому авторы библиотек таким образом гарантируют, что undefined точно undefined

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

svg или множественный background с градиентом

https://codepen.io/xdevelx/pen/QWbxxvR

Та же песочница codepen.io очень много разного и можно скопировать к себе, изменить, улучшить и т.д.

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

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

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

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

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

Совмещение ваших пунктов 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