Ну какбэ есть всего два подхода:
1. Свой формат: классика типа bb-тегов или даже тупо markdown. Формат строгий а потому никаких проблем, кроме ограниченности.
2. Чищеный html: если будешь сам велосипедить "очищалку" - гарантировано поимеешь дырки в безопасности, а если использовать какую-то проверенную и поддерживаемую либу - то шанс попасть минимален.
Использовать json'чик с данными разбитыми по частям можно, но для постов произвольной и вариативной начинки это бессмысленно всё усложнит. Такое используется обычно как связка: конкретные данные + форм-генератор строящий интерфейс по схеме.
В идеальном мире: сторонние компоненты должны поддерживать всю возможную стилизацию стандартизированным образом: либо через props, либо (реже и хуже) через документированные классы разрешённые к изменению сверху. В ином случае всегда будет оставаться шанс, что всё развалится при обновлении компонента.
Теперь собственно к нашему, катящемуся в бездну, миру: да, смотреть шаблон компонента и менять стили через :deep или глобально. Обязательно писать к этому тесты, чтобы отвал после какого-то обновления не пролез незаметно на прод.
Если править классы становится слишком сложно, то форкать к себе, и править как хочешь. Также можно форкнуть если компонент простой.
Обратно к идеальному миру: при желании можно попробовать пропихнуть пул реквест автору оригинального компонента, поддерживающий нужную кастомизацию(естественно в универсальном и удобном виде).
Если заменить кривой язык для которого за годы и годы работы написали столько костылей, что они уже сложились в более-менее стабильный и устойчивый фундамент, на свежие кривые хипстерские языки от той же тусовки, то всё конечно станет стабильно.
*сарказм.жпг*
Ну и интересно, что у тебя там меняется, обратная совместимость в js практически абсолютна. Если ничего не трогать - ничего не сломается.
Эмодзи - часть юникода(будь прокляты те, кто это придумал), а значит часть шрифта. Просто заставь юзеров подгружать нужный тебе шрифт с нужным видом эмодзи. Если его поставить в конец списка, то первыми можно использовать любые иные(без встроенных эмодзи).
webpack devServer, в частности функция proxy.
Webpack поднимает сервер с горячей перезагрузкой фронта, бэк сервера поднимаешь на других портах, и обращаешься к api прозрачно с помощью встроенного прокси.
Это работает исключительно потому, что элемент по умолчанию не создаёт своего контекста и минусовой индекс работает в родительском.
Заверните корневой элемент в обёртку и уже обёртке назначайте нужный индекс, других вариантов по конкретному вопросу нет.
Но скорее всего вы что-то делаете не так, и описание настоящей задачи помогло бы нам дать правильный ответ.
Знать как работает и уметь боль-мене понять конфиг того же nginx - да. Без этого часто может быть грустно. Даже если именно настраивать не придётся ни разу.
Уметь именно правильно настраивать - нет. Это задача админа(девопса). Там на самом деле тонкостей и сложностей очень и очень много. На отдельную должность, ага, и не одну.
Хз, это спорный вопрос. Я юзайю одинаковую иерархическую сруктуру. Т.е. на верхнем уровне у меня есть папки components, utils итд, дальше у каждого сложного компонента \ страницы своя папочка с точно такой же структурой относящаяся конкретно к этому компоненту. И так вглубь. Если что-то становится общим - оно едет выше, что-то локальное - ниже. Но я не претендую на истину, и кому-то это может показаться ужасным.)
Что нравится, то и используй. Всё в итоге сводится к одному.
Angular умеет всё из коробки, но в связи с этим жёстко диктует конкретную архитектуру.(отвратительно оверинжинирнутую на мой вкус, но кому-то нрвится)
React нифига не умеет из коробки, ты свободен в выборе как архитектуры так и простых прикладных инструментов.
Vue имеет идеальный набор прикладных инструментов(который хрен повторишь в реакте) и свободу в выборе архитектуры.
По нынешнем временам "классическая" php-лапша из смеси php, html и css - это фуллстак, а не бэкэнд.
Бэкэнд - то что на сервере, фронтэнд - то что на клиенте. Там и там - фуллстак.
Просто делай отдельный файл конфига\локали и пусть сервер подгружает в соответствии с доменом. Самому билду вообще лучше ничего не знать о конкретных доменах, для лёгкой переносимости.
Скорость и интерактивность, очевидно.
А вынос фронта отдельно - прямое следствие усложнения интерфейсов. Даже если ты пишешь на серверном шаблонизаторе и плюёшь в юзера голым html тебе всё равно придётся отделять слой бизнес логики от слоя отображения.
Ну какбэ энтерпрайзно обычно это система: микророли - роли - должности(наборы ролей). Первые - это разрешение на определённый чих в определённом направлении внутри приложения, второе - связанный некоей логикой набор первых, третье - это связанный начальством набор вторых. Пользователю соответственно назначается третье, а внутри приложения проверяется первое.
Если пилить на коленке - можно не париться и использовать однодноуровневую систему, в которой просто назначать юзеру роли и проверять оные сразу же в приложении. Список доступных ролей брать при логине.
Роли никак не привязаны к структуре приложения и имеют говорящие названия.