Dima Polos

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

Вот все вот эти инструменты и составляют, в основном, окружение фронтенда. Они помогают упростить рутинную работу, автоматизировать все процессы, которые происходят во все моменты работы над приложением, его публикацией, версионированием и так далее. Возможно, настройка этого окружения требует времени и определенных знаний, но то время, которое экономится - бесценно.
На начальных этапах, уже есть готовые шаблоны. К примеру, когда работаешь над Vue.js проектом, ты вполне можешь использовать vue-cli шаблон webpack-simple, который включает все те пункты, которые я перечислил. Как-то так.

Используйте глобальную дату, но помните одно, что её надо самому чистить из памяти. Ещё надо как-то придумать геттреы и сеттеры для неё. Вдруг понадобится из users достать определённых людей и это всё на разных страницах. Или например проверить авторизацию? На vuex сделать это проще, написав один геттер

Когда у вас возникнет проблемы с хранением и переполнением, то вы сами придёте к vuex.

Страница с контентом:

Vuex

В Vuex с помощью mutations можно отслеживать все изменения и аккуратно изменять нужные массивы и объекты данных. В data нет, в data все mutable, что то изменилось и уже сложно дебажить и т.д. Прочитайте в доках к Vuex часть про "Где и когда нужен Vuex".

Vuex это же паттерн управления состоянием. Он дает понятные механизмы управления, по сути задает стандарт, единый подход, методологию. Это удобно, когда вы не один в проекте, когда проект развивается и растет. Без этого ваш подход через не которое время приведет к неизбежным костылям, более сложной управляемости, а еще через некоторое вы вообще перестанете понимать, что происходит)
Ну и минусы вашего подхода:
1. Жесткая связь с рутовым компонентом
2. Нет разделения на синхронные и асинхронные операции
3. Ну и вообще у вас только есть реактивность, а вуекс дает различные удобные механизмы типа модулей, наймспэйсов в них, для управления сложностью и возможностью к расширению.

Предлагаю использовать svg text.

Потому что перед ним два тега используй ~

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

getComputedStyle(document.body).width

Если открыть страницу и попробовать сделать так : $('#field-id135987').length , вы получите 0
Т.е первый раз вы пытаетесь повесить маску на элемент, КОТОРОГО НЕТ. Судя по всему инпут создается после нажатия на кнопку "Заказать звонок". Никто не гарантирует вам, что когда вы нажмете кнопку сначала создастся инпут, а уж потом к нему прицепится маска. Это объясняет повторное срабатывание. Надеюсь, ошибка ясна. Удачи

Это можно сделать при помощи css, js тут не нужен.
background-attachment: fixed;

cssreference.io/backgrounds

зачем нужна сетка для верстки

Сетка нужна для удобства и консистентности верстки.

будь то бутстрап или грид

Бутстрап это большой фреймворк, сетка - лишь маленькая его часть. А грид - это и есть "сетка". С терминологией надо бы порядок навести.

если я все равно в контейнере отступаю в пкс от краев, задаю ширину в стилях и помещаю все в контейнер, а для телефонов оптимизирую через медиа запросы

Поздравляю, вы создаете и используете собственную сетку! :) Исходя из этого, решите для себя сами - достаточно ли вам вашей собственной сетки, удобно ли с ней работать. Если да - тогда сторонние готовые решения вам не нужны. Если нет - тогда используйте готовую сетку и не парьтесь.

пропишите css:

.кнопка {
  display: none;
}
.таблица:hover .кнопка {
  display: block;
}

естественно свои классы подставьте

.btn {
  display: none;
}
.table:hover .btn {
  display: block;
}

Потому что при сравнении объектов и булевых значений последние преобразовываются в числа, а при сравнение объектов и чисел объекты также преобразуются в числа, т.е., в конечном счёте, в данном случае имеет место сравнение NaN и 1.

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

1) можно навесить сколько угодно обработчиков на одно событие
2) можно передать 3 аргументом дополнительные опции https://developer.mozilla.org/en-US/docs/Web/API/E...

1920 для комфортной работы уже мало, конечно. Советы про 27+ правильные. Но обычно всё в финансы упирается - тут уж каждый сам решает.