Станислав

Только лишь за наличие .gitconfig и .DS_Store я бы уже не рассматривал вас как кандидата - это значит, что вы в принципе не понимаете, чем это может помешать другим людям, а значит в принципе не участвовали в командных проектах. Более того, вы не удосужились и изучить, как оно там бывает. Уверен, что в данной компании даже джуниоров рассматривают из тех, кто что-то понимает в этом.

Далее я честно клонировал ваш апп и попробовал запустить "npm run test:style". Выдало, что такого скрипта нет. На этом моменте ревью было закончено, так как стало понятно, что вы либо крайне невнимательны, раз не включили этот скрипт в рабочую версию в ветке master (или наоборот не удалили, скопировав откуда-то шаблон?), либо не понимаете, что делаете в принципе, нахватавшись откуда-то верхушек, скомпилировав чужой опыт, и тд.

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

Разные разработчики имеют тот или иной опыт работы и тот или иной стаж. Соответственно, если сейчас вам уже проще использовать Gulp, да и сами разработчики Bower уже не рекомендуют его использовать для установки пакетов, то вы используете Gulp. Но кто-то начинал ранее, или же просто первым делом столкнулся с Bower, и стал использовать изначально его.

Практического смысла в данный момент использовать именно его нет, раньше это имело смысл, когда Bower рекомендовали использовать для пакетов для фронта, а npm (не важно как, через Gulp или впрямую), использовать для бекенда - связано это было с тем, что первый не тянул зависимости для каждого пакета в свою личную папку, они устанавливались в общую, и таким образом папки с пакетами для фронта были более чистыми, а зависимые пакеты - общими.

Но при этом использовать везде Gulp для управления пакетами тоже нет смысла, так как для простых проектов это плюс один инструмент, который не факт, что нужен. Кому-то будет проще использовать чистый package.json и просто указать в инструкции своего проекта, что нужно запустить установку пакетов из него.

Самый удобочитаемый и короткий способ - сделать вот так:

$('.ads-category__link').on('click',function(){
  $(this).toggleClass('active');
});

Как несложно догадаться, метод toggleClass() не просто добавляет или удаляет указанный ему класс или классы, а "переключает" их, убирая, если они уже есть, или добавляя, если их еще нет.

Вообще, тут нужно понимать, что все подобные задачи в Gulp решаются как правило за счет тех или иных плагинов для него. Так, конкретно для вашей задачи подойдет плагин gulp-modify-css-urls. Сначала вам необходимо установить его:
npm install --save-dev gulp-modify-css-urls
Параметр --save-dev укажите, если хотите, чтобы эта зависимость прописалась в ваш package.json в раздел dev. После этого вы можете модифицировать пути в файлах css с помощью примерно такого кода (взят из доков этого плагина):

var gulp = require('gulp')
  , modifyCssUrls = require('gulp-modify-css-urls');
 
/* style.css
body {
  background-image: url('images/logo.png');
}
*/
gulp.task('modifyUrls', function () {
  return gulp.src('style.css')
    .pipe(modifyCssUrls({
      modify: function (url, filePath) {
        return 'app/' + url;
      },
      prepend: 'https://fancycdn.com/',
      append: '?cache-buster'
    }))
    .pipe(gulp.dest('./'));
});
/* style.css
body {
  background-image: url('https://fancycdn.com/app/images/logo.png?cache-buster');
}
*/

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

Ответ на ваш вопрос: нет, далеко не во всех случаях этот код эквивалентен.

Когда вы собираетесь писать какой-либо JS-код, нужно пройти несколько этапов принятия решения, что, на чем и как вы будете писать.

1. С чем должен работать ваш код, с DOM-деревом (если говорить просто, то с html-кодом), с какими-то внешними сервисами, или с просто консолью, например.
2. Насколько объемен этот код, и соответственно, если задачи простые и их минимальное количество, использовать вместо JQuery (а именно она у вас, скорее всего, и используется) обычный Javascript, так называемый ванильный JS (чистый). Не путать с библиотекой Vanilla.js.
3. Будет ли этот код расширяться в дальнейшем.

Ответив на первый вопрос, вы поймете, нужно ли вам дожидаться, пока что DOM-дерево страницы будет построено браузером. Обратите внимание, что конструкция вида $(document).ready(function(){... не равнозначна написанному после html некоему скрипту, так как браузер у вас сначала получает запрошенную страницу, и потом, если не оговорено, одновременно начинает "строить" ее отображение и одновременно выполнять ваш js-код.

Именно чтобы браузер дождался первого и после начал выполнять второе, используют конструкции, приведенные вами в вопросе. И даже если бы вы писали на чистом JS, вы все равно писали бы что-то вроде этого document.addEventListener('DOMContentLoaded', ..., то есть один в один тот же код, с точки зрения его логики.

Ответив на второй вопрос, вы поймете, стоит ли приниматься писать на чистом JS или же использовать те или иные готовые библиотеки (фрейворки) для своих задач. С одной стороны, если задачи минимальны, это не сильно повлияет на время написания кода (для библиотек примеров в сети готовых решений тех или иных задач больше), а с другой стороны, если использовать библиотеки, это повлияет на скорость работы сайта и скорость первоначальной загрузки его страниц.

Ну и ответив на третий вопрос, вы поймете, стоит ли ввязываться в работу с чистым JS, или же все-таки лучше не рисковать и сразу писать с использованием какой-либо библиотеки, чтобы потом не упереться в излишнюю сложность своей работы.

вообще composer для php

Нет, но в целом это верное решение, не использовать его для подобных целей, если только не будете внимательно следить за зависимостями.

видимо нужно создавать npm-пакеты, но тут уже я потерялся, пытаясь понять, как это для веб оформить

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

вынести некоторые части js кода в отдельные пакеты, чтобы потом использовать в других проектах

Еще раз по предыдущим пунктам - composer действительно собирает в основном для бекенда (условно движок), хотя и им можно забивать гвозди. NPM собирает для скорее опять же каких-то нужд бекенда, в том числе административных, например, через него ставится Bower. В том числе потому, что у него для каждого пакета в его папку подтягиваются все его зависимости, каждый раз для каждого пакета, даже если пакеты, от которых они зависят, являются общими.

А вот тот же Bower можно и нужно использовать для подтягивания пакетов для фронта. Elixir, laravel-mix - это все сборщики, как и тот же Gulp, они занимаются не установкой пакетов, а их преобразованием - например, минифицируют и конкатенируют файлы стилей или скриптов, это совершенно иные задачи.

Поэтому я бы вам предложил использовать Bower, но, опять же, не публиковать для него свои пакеты в общем доступе, если только они не имеют ценности для всего сообщества в целом (смысл загрязнять общую эко-среду), а использовать ваш личный Github или какой угодно другой ваш публичный сервер/etc. Подробнее о том, как устанавливать пакеты не из общего репозитория можно прочитать тут, но в целом там совсем всё просто:

# Git endpoint
$ bower install git://github.com/user/package.git
# URL
$ bower install http://example.com/script.js

есть ли бесплатные сервисы, которые смогут мне предоставить вышеописанные возможности?

Не совсем понятно, какие именно возможности вас интересуют, но в целом можете посмотреть на де-факто стандарт в разработке API, на текущий момент, swagger.io. Он будет бесплатен для вашей задачи.

Или надо арендовать сервер и на нём устанавливать deployd приложение?

В целом, аренда сервера стоит копейки по нынешним ценам, пара сотен рублей в месяц. Но если вас смущает эта цена и не смущает стоимость вашего времени, потраченного на поиски альтернативных решений и их настройку, вы можете всегда поднять локальный веб-сервер у себя на машине, используя хоть VirtualBox+Vagrant, хоть Denwer, хоть что угодно еще. Для задач разработки и тестирования этого хватит на 100%.

Данная проблема давно известна, и именно ваша попытка ускорить сайт к ней и привела - Contact form 7 конфликтует с различными плагинами, ускоряющими сайт за счет кеширования и других вещей. Посмотрите на этот ответ на SO, возможно, что он поможет вам.

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

пробовал поставить через класс но что то я делаю не так или это вообще не возможно

Нет, это возможно, и ход мыслей у вас абсолютно верный. Скорее всего, вы ошиблись при написании селекторов в $("#form").submit(...). Если у вас на странице все формы именно те, что вам нужно обрабатывать указанным скриптом, то вам достаточно написать вот так: $("form").submit(...). Если же у вас есть еще какие-то формы, которые нужно обрабатывать иным способом, то вам следует придумать некий класс для обсуждаемых форм, и делать по ним выборку таким образом: $("form.some-class").submit(...).