Aetae

Можно взять pdf.js и допилить как тебе надо. Будет жирно и тяжело.
Либо моджно сохранить pdf как набор картинок и просто положить их на сайт. Будет просто и жирно.

Это называется web-proxy. Решений таких миллион, гугли да разворачивай. Не забудь только запоролить, а то боты быстро тебе весь трафик выжрут, а потом и ркн забанит.:)

Есть подозрение, что вот это вот создаёт вечный цикл:

картинка.src = e.target.result

картинка.onloadend = function()
{
  var width = картинка.naturalWidth 
  var height = картинка.naturalHeight
  var соотношение = width/height

  картинка.src = создать_картинку(картинка, 1000, 1000/соотношение)
}

1. ставишь картинка.src
2. картинка загружается
3. срабатывает картинка.onloadend
4. ставишь картинка.src
5. картинка загружается
6. срабатывает картинка.onloadend
и т.д.

Ну какбэ есть всего два подхода:
1. Свой формат: классика типа bb-тегов или даже тупо markdown. Формат строгий а потому никаких проблем, кроме ограниченности.
2. Чищеный html: если будешь сам велосипедить "очищалку" - гарантировано поимеешь дырки в безопасности, а если использовать какую-то проверенную и поддерживаемую либу - то шанс попасть минимален.

Использовать json'чик с данными разбитыми по частям можно, но для постов произвольной и вариативной начинки это бессмысленно всё усложнит. Такое используется обычно как связка: конкретные данные + форм-генератор строящий интерфейс по схеме.

Ты можешь использовать css переменные.

Ответ: по ситуации. :)

В идеальном мире: сторонние компоненты должны поддерживать всю возможную стилизацию стандартизированным образом: либо через props, либо (реже и хуже) через документированные классы разрешённые к изменению сверху. В ином случае всегда будет оставаться шанс, что всё развалится при обновлении компонента.

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

Обратно к идеальному миру: при желании можно попробовать пропихнуть пул реквест автору оригинального компонента, поддерживающий нужную кастомизацию(естественно в универсальном и удобном виде).

<img> - это чисто картинка, которая ведёт себя как картинка и никак иначе, никакой интерактивности.

Ты можешь либо использовать object\embed\ifrrame, либо преобразовать в svg symbol и использовать svg use.

Если заменить кривой язык для которого за годы и годы работы написали столько костылей, что они уже сложились в более-менее стабильный и устойчивый фундамент, на свежие кривые хипстерские языки от той же тусовки, то всё конечно станет стабильно.
*сарказм.жпг*

Ну и интересно, что у тебя там меняется, обратная совместимость в js практически абсолютна. Если ничего не трогать - ничего не сломается.

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

webpack devServer, в частности функция proxy.
Webpack поднимает сервер с горячей перезагрузкой фронта, бэк сервера поднимаешь на других портах, и обращаешься к api прозрачно с помощью встроенного прокси.

Нормально. Суть вэб-компонентов в том, что они ничем снаружи не должны отличаться по поведению от обычных элементов. Вложенность сюда тоже входит.