Роман

ну такое себе. есть Atomic css со стилями mt15 p40 и далее
для шаблонов наверное норм, для более индивидуальной верстки - ад

"Более защищённей" та ОС, которая настроена более пряморуким админом. То же самое относится к остальной инфраструктуре. При прочих равных - разница в "более защищённости" у популярных дистрибутивов отличается гомеопатически.

На заборе обычно пишут "х.й", но лежат там обычные дрова. А забор уверяет, что нет? Верить ли забору? :)

Разумеется, взломать можно и многих ломают. Тех, кто пренебрегает следующими правилами:
- Длинный сложный пароль
- Действующее постоянно читаемое мыло в регистрации
- Бдительность при чтении почты (особенно всяких "оповещений от администрации VKoнтакте")
- Бдительность при посещении сайтов
- НЕ использование мобильного клиента. (Это не касается тех, у кого телефон достаточно обезопасен)
- НЕ использование публичных wifi и прочей непонятной фигни (я уверен, что если публичный wifi выкатит в качестве условия использования установку своего сертификата в корневые - все желающие наперебой побегут его ставить!)

Но все это - вообще говоря банальные правила, применимые к тырнету вообще

Photopea.com

Вот вам два простых правила:

1. Не используйте анимацию просто так.
   
2. Добавляйте анимации только в тех местах где они действительно нужны. И где без них ну вот вообще никак.
   

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

а на самом деле - префиксы служат для использования экспериментальных опций css которые еще не прошли релизную стадию либо в стандарте w3c либо в движке браузера. Их можно использовать, особого вреда не будет. Пишут сначала с префиксом, потом без, чтобы релизная инструкция могла примениться ПОСЛЕ объявления с префиксом.
Можно почитать тут.
В на счет применения всяких хаков для компенсации ущербности браузеров - такие префиксы не помогут.

Заводим тег picture внутри которого указываем дефолтную картинку:

<picture>
    <img class="image"
      src="img/mobile.jpg"
      alt="Описание" width="260" height="260">
<picture>

В данном коде у нас везде просто загрузится "img/mobile.jpg".
Как это можно улучшить? Можно использовать прогрессивные файлы изображений такие как webp (почитать про них стоит отдельно, вкратце - они меньше весят при одинаковом качестве картинки).
Добавляем условие для показа новой картинки:

<picture>
    <source srcset="img/mobile.webp" 
      type="image/webp">
    <img class="image"
      src="img/mobile.jpg"
      alt="Описание" width="260" height="260">
<picture>

Здесь, если браузер поддерживает .webp будет загружена картинка: img/mobile.webp.
Допустим у нас есть брейкпоинт на десктоп при 768px где нам нужно показывать картинку более высокого качества (либо вообще другую). Код можно улучшить так:

<picture>
    <source media="(min-width:768px)" 
      srcset="img/desktop.webp"
      type="image/webp">
    <source media="(min-width:768px)"
      srcset="img/picture/desktop.jpg">
    <source srcset="img/mobile.webp" 
      type="image/webp">
    <img class="image"
      src="img/mobile.jpg"
      alt="Описание" width="260" height="260">
<picture>

Тут мы добавили еще 2 условия: если окно шире 768px и браузер поддерживает webp - грузится desktop.webp, если не поддерживает то - desktop.jpg.
Данную конструкцию можно еще расширить. Например мы хотим чтобы на retina-дисплеях картинки показывались в более высоком качестве. Для этого у нас должны быть копии всех наших картинок но с увеличенным в 2 раза разрешением. Например, наши картинки будут именоваться как mobile@1x.jpg (260х260рх). плюс эти же картинки, но в 2 раза большем разрешении: mobile@2x.jpg (520х520рх). Загружать их, или нет будет решать браузер, на основании данных о плотности пикселей на экрана полученных от системы (это тоже отдельная тема для обсуждения, есть статьис названием что-то вроде "Пиксель на самом деле не пиксель". Точного названия не помню, но смысл в том, что на "так называемых" Retina-дисплеях при фактическом разрешении, например, 2500х1600px браузер будет "считать", что окно шириной 1250px). Короче для "ретинизации" код нужно изменить так:

<picture>
  <source media="(min-width:768px)" 
    srcset="img/desktop@1x.webp, img/webp/desktop@2x.webp 2x"
    type="image/webp">
  <source media="(min-width:768px)"
    srcset="img/picture/desktop@1x.jpg, img/picture/desktop@2x.jpg 2x">
  <source srcset="img/webp/mobile@1x.webp, img/webp/mobile@2x.webp 2x" 
    type="image/webp">
  <img class="image" 
    src="img/mobile@1x.jpg" 
    srcset="img/mobile@2x.jpg 2x"
    alt="Описание" width="260" height="260">
</picture>

Вся эта громадина читается сверху:
- первый <source>: если ширина экрана больше 768рх, браузер поддерживает webp и плотность пикселей 2x грузится desktop@2x.webp, если плотность пикселей 1х - desktop@1x.webp
- если webp не поддерживается, то второй <source> - все тоже самое для .jpg
- если экран уже 768px - третий <source>
- во всех остальных случаях и в случае если браузер не поддерживает загрузится обычный <img>.
Нужно понимать, что для такого подхода требуется иметь для одной картинки 4 файла и это только для одной ширины экрана:
mobile@1x.jpg, mobile@2x.jpg, mobile@1x.webp, mobile@2x.webp.
И еще столько же для desktop.
Вот как-то так, можно добавить еще брейкпоинт для tablet - все по примеру :)

освоил полностью Фронтенд

Да ладно!
Я не видел в своей жизни ни одного человека, который полностью освоил фронтенд.
Я тебе сейчас парочку вопросов по фронту задам и ты на них не ответишь :)
Начнём с Андроида и iOS. Ты же не будешь отрицать, что мобильные приложения - это тоже фронтенд?