Артем

Суперлузер? Серьезно?
Ок, размер рабочей области зависит от предпочтений и фолбеков.
Например, мое разрешение монитора сейчас как раз 1920, то есть картинка шириной 1920 будет как раз 100% ширины экрана... не учитывая полосу прокрутки и рамки окна. То есть нужны поля. Допустим по 15 пикселей(у меня не ретина, так что мой монитор имеет 72 точки на дюйм). Итого 1920 превращается в 1890, если надо контент делать на всю ширину (section-fluid в бутстраповых классах).
1920 это сейчас считаем как дефолтный монитор(смотрим по статистике), а на момент создания бутстрапа они зафиксировали 1170 как минимально допстимое разрешение десктопа, потому контент вписывают на такой размер(учитывая поля по 15 пикселей это разрещение 1200*800) как наиболее используемым разрешением.
Дальше 1280 это популярная ширина в разных разрешениях, как брекпойнт. Но уже без полей.
960 это из за одноименного фреймворка, где это число используется для фолбека на 1024*968 разрешение плюс поля, округление до нормального делительного числа.
Число 960(как и остальные перечисленные Вами) выбрано потому что удобно делить на колонки с полями. На 2/4/6/8/10/12/16/24

Берите ширину в зависимости о того, как будете верстать. А, ну и погодите, если Вы получаете готовый дизайн, то Вам не сильно получится "брать" какую то ширину контента, а придется работать с тем, что дали.
Опять же, будете ли пользовать фреймворки - тоже ограничит/упростит выбор ширины.
Забивать не надо. Если забили на ширину контента, то либо просто накалякали какую-то свою ширину, но все равно единую, либо вообще разброс по секциям/блокам. Вы вполне сможете потом свести всё до единой ширины, которую сами выбрали, если заказчик согласен и не требуется пиксель перфект по контентной области(обычно нет, и вполне обьясняется заказчику требованиями "соответствия для старых мониторов" или что то такое, после чего они соглашаются)

Зависит в основном от этого:

Магия кроется вот здесь

$file -> move( public_path() . '/upload_for_post/' . $blog -> id . '/' . $input[ 'image' ] );

Нужно перед $input[ 'image' ] указать " , " а не " . "

правильно, но что бы ты понимал:
1. JQuery это библиотека
2. slick slider это плагин
с их помощью ты сделал слайдер слайдер изображений как хотел заказчик за 3мин и доволен
...
шли секунды... минуты... часы
...
заказчик тебя попросил за доп. плату сделать превью изображений к слайдеру

вот, что бы не сесть в лужу нужно знать как это работает

и это 1см айсберга, дальше - глубже

json_decode($json,true);?

Доки для слабаков и трусов!

Нет, вы от этого совсем ничего не получите. Кроме если в iife сделать локальную область переменных.

<div class="js-courses-type" data-loop="4"></div>
<div class="js-courses-type" data-loop="2"></div>
<div class="js-courses-type" data-loop="1"></div>
<div class="js-courses-type" data-loop="3"></div>
<div class="js-courses-type" data-loop="5"></div>

const courses = [...document.querySelectorAll('.js-courses-type')].sort((a, b) => a.getAttribute('data-loop') - b.getAttribute('data-loop'));
courses.forEach( course => window.console.log(course));

Нужны пояснения?

global ${$arParams["FILTER_NAME"]};

Передача в функцию по ссылке убрана еще в 5.4

По видимому Вы не понимаете как и что работает. Когда Вы разработываете на php, и внеся изменения в код - Вы же обновляете страницу, для которой этот код был написан? В отличие от PHP - nodejs исполняется сразу и загружается в память, так что можно вплоть до того, что после запуска - удалять файлы и софт будет работать. Так вот Вы изменили что то в коде и как по Вашему должен этот код (без внешнего вмешательства) узнать, что чтото там изменилось, если вы такую логику не прописали в самом коде?
Так что не переживайте и учите nodejs дальше.

Css классы вообще не несут никакой семантики. Хоть как обзывайте, всем пофиг. Если вы говорите о "понятности" для программиста/верстальщика, то тут вы правы — мнения разные.
Что такое .title? Заголовок. Какой заголовок? А хз...
А что такое .product-item__title? Это заголовок блока в списке товаров. Very good.

Окей. Но мы же видим в разметке class="title _product-item". А в css мы это видим? Нет. У нас голый класс .title {}, и еще где-то составной есть .title._product-item. Очевидно, что .title используется с другими блоками тоже. Пришел новый человек с задачей поменять поменять цвет тайтлов ну допустим в отзывах. Он откроет страницу, посмотрит в инспектор, увидит что цвет заголовка задан в классе .title, а про .title._product-item он даже не в курсе будет, это на другой странице сайта, в css через 1000 строк. Он просто поменяет цвет в .title. А потом выяснится что заголовки в товарах тоже поменяли цвет. А не надо было.

Короче, ребята, зачем вы ищете и выдумываете разную хрень? Всё уже придумано до вас — БЭМ. И не дураки это придумывали, а люди с большим опытом верстки и поддержки проектов разного уровня. А претензии типа "мне не нравятся длинные названия классов" — ну право же, детский сад, надо взрослеть.

Ну и можно слегка поэкспериментировать, объединив SMACSS с BEM.
Оставить уровни base и layout. Оставить уровень modules — по сути это будут БЭМ-блоки. Стейты выкинуть — состояния блока лучше в нем самом описывать. Темы — по желанию.

если не использовать SASS - а это зачастую не используется, так как работаю часто с готовыми проектами.

Если приходится лезть в готовый проект, то стоит изучить его и придерживаться стиля заданного автором. Если там нет никакого стиля, то сам бог велел наговнокодить =)) Ну или отрефакторить, если заказчик готов платить.

export default {
  data () {
    props: ['a'],
    return {
      qwe: "Привет 2"
    }
  }
}

Это шизофрения какая-то. Наверное, имелось в виду

export default {
  props: ['a'],
  data() {
    return {
      qwe: "Привет 2"
    }
  }
}

querySelectorAll возвращает не элемент, а коллекцию элементов NodeList. Если нужно изменить один элемент, то используйте querySelector. Если много, проходите эти элементы в цикле и добавляйте класс.

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