smilingcheater

Кириллицу лучше не использовать. Особого вреда нет, но и пользы никакой: Кириллица в URL — полезно ли для SEO?
Из приведенных вариантов лучше:
mysite.com/service/alarm-installation или mysite.com/uslugi/ustanovka-signalizacii
при условии, что страница service или, соответственно, uslugi существует.
Если в структуре сайта вложенности нет, то mysite.com/service-alarm-installation
Транслит или перевод — дело вкуса.

Такие вещи как корзина нужно согласовывать с бэкэнд-программистом. У него может быть CMS c готовым модулем, который вам нужно перестилизовать. А может он любую разметку прикрутить готов.
Удаление товара может быть реализовано как с перезагрузкой страницы. так и аякс-запросом. Это тоже нужно уточнять.
Для подсчета стоимости вам нужны данные — цена и количество, и возможно скидки. Также нужно согласовать, каким образом вы будете получать эти данные, в дата-атрибутах, отдельным объектом на странице или аякс запросом.

А может от вас просто требуется статичная верстка. =))
В общем, не по адресу вопрос задаете. Обговаривайте это с заказчиком или коллегами.

Не совсем понятно, чем не устраивает position: absolute
"Герой" — это отдельный элемент. Соответственно разместить его поверх других элементов, кроме как через absolute невозможно!
Даже с использованием JS или JQ, под капотом все равно будет тот же absolute.

Если смущает выпадание элемента из родителя, то используйте overflow: hidden

.block {
  position: relative;
  overflow: hidden;
}
.block__hero {
  position: absolute;
}

Ах да! Еще можно использовать множественные фоны:

.block {
  background-image: url(hero.jpg), url(bg.jpg);
}

Нет встроенного - подключай к дискретному адаптеру, На дискретном нехватает разъёмов - меняй видуокарту или покапай ещё одну видеокарту и включай в неё.

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

GPU быстро работает тогда, когда нужно перемолоть много данных с минимумом ветвелений. Парсинг этому противоположен по структуре алгоритма.

Ну раз вам проще сделать $('h1').text('hello world') чем this.title = 'hello world', то продолжайте манипулировать DOM-ом. Вы пока не доросли до фронтенд фреймворков.

Когда-то я писал на PHP. Писал много. Сначала это было месиво из кода на PHP и HTML, потом появились всякие шаблонизаторы, стало чуть чище.
Проекты росли, кода становилось все больше и хотелось некоторые кусочки переиспользовать. Так я пришел к управлению кодом через Composer.
На каком-то этапе разработки я столкнулся с тем, что у меня было 2 разных веб-интерфейса делающих одно и то же. Вдобавок нужно было часть данных отдавать в систему логистики. Причем это должно было быть автоматизировано. Тогда я уже знал, что есть такая штука - автоматизированные программные интерфейсы (API).
Наскоро было что-то написано и оно заработало. По итогу, оба веб-интерфейса и система логистики использовали одни и теже функции. Но поддерживать 2 разных интерфейса было очень геморно. В те времены был jQuery самым главным. Очень сложно было добиться правильного отображения, посколько Javascript код был в перемешку с HTML, часть которого генерировалась из PHP. Возникали ошибки. Данных было много, разных скриптов было много (сотни), части скриптов были копиями друг друга с небольшими отклонениями. По итогу, на решение простых задач вроде редактирования строчки в таблице с обновлением на сервере уходило много времени, дни, иногда даже недели.
Потом я увидел Mustache.js, это был предок Ангуляра и Реакта. Что-то вроде шаблонизатора, но только на стороне клиента. Работало оно только в одну сторону, отображало данные в HTML, но потом была та же жесть из jQuery.
Затем я познакомился с Angular1. Идея была простая - пишешь шаблон, подставляешь в него данных. Оно отображается, само! Никаких тебе извращений, найди класс или идентификатор, или еще какая-нибудь ерунда.
Кодить стало проще. Стало можно создавать библиотеки компонентов и просто редактировать стили. Можно было сделать компонент для ввода и проверки почты, и использовать его сразу во всех проектах и исправлять ошибки в одном месте, а не бегать по сотням скриптов и искать в каждом этот повторяющийся косяк.
Поначалу я тоже относился к Ангуляру с предубеждением, столько траблов, стоят ли они того. Но как только я стал чаще сталкиваться с задачами, когда мне понадобились разные интерфейсы для отображения одних и тех же данных, это стало сходить на нет.
Пока вы пилите простые штуки, всякие фреймворки вам не втарахтели. Даже jQuery не нужен. Но иногда начинается жопа, когда одному уже проект не вытащить, ибо охеренеть, как сложно, а еще и делать надо быстро. Поэтому лучше разделиться, кто-то делает бэкенд, кто-то фронт. Так просто удобнее, а общаться через API. Вначале вы вместе просто пишите спецификацию для API, это занимает день или два. А потом вы бомбите месяц в параллель. Причем фишка такого подхода в том, что есть инструменты, которые просто выдают заглушки для кода на фронте. Т.е. если фронт пишется быстрее, то его проще тестить и все такое. Аналогично с бэкендом. Его тоже можно тестить даже если фронт не готов. Причем эти все фишки особенно круты, когда вас не двое, а например 20, да и живете вы по всему миру в разных часовых поясах и т.д.