Вафель Кренделькин

WSL + Visual Studio прекрасно справится со всеми вашими задачами.
Дополнительно посмотрите на DevilBox

Animated Map Path for Interactive Storytelling

Поместив HTML, XML, SVG и т.д. и т.п. файл на домене usercontent.google.com можно
манипулировать куками домена google.com и фишить. Поэтому пользовательский контент всегда отдается с отдельных sandbox-доменов.
Так же с отдельных доменов обычно отдается статический контент, это позволяет использовать CDN и упрощает управление кэшированием.
Отдельный домен обычно используется для PTR-записей (например 1e100.net). Для PTR часто нужна двойная валидация, т.е. PTR должна разрешаться в имя и имя обратно в тот же IP. При этом на одном IP может хоститься много доменов и быть установлено много сертификатов, включая вайлдкарды. И наоборот, один домен может хоститься на многих IP. Чтобы исключить прямое обращение к хосту по "неожиданному" для него имени в своем домене, обычно используются PTR записи в нейтральном домене. Кстати исторически принято использовать именно домены в .net. Google так же использует 1e100.net как нейтральный домен для подписи транзитных писем, раньше для этого использовался собственно домен google.com и это приводило к забавному багу, позволявшему подделывать подписи на письмах от google.com, я рассказывал о нем на PHDays 2014.
Географические домены исторически используют для организации региональных датацентов и ускорения доступа, например yahoo.jp физически расположен в Японии.

Это конечно не очень хороший совет, но попробуйте через jquery, у него вроде совместимость с разными браузерами это фича.
В интернетах пишут что этот специфический глюк обходится заранее созданным элементом div, в него все фигачется через innerHTML, и этот див уже аппендится куда надо.

var newdiv = document.createElement("div");
newdiv.innerHTML = someString;
var container = document.getElementById(id);
container.appendChild(newdiv);

Паттерны - это реальные инструменты, позволяющие добиться реализации концепции объектно-ориентированного проектирования и принципов SOLID

Ссылка на SOLID

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

Один из наиболее часто встречающихся мне примеров, это пример принципа "Принцип открытости/закрытости" , когда класс - описывающий некую сущность(например модель комментария) , описывает только свои базовые назначения( создание, удаление, редактирование), при этом такие механизмы, как модерация, прикрепление файлов, лайки , реализуется другими классами и "прикручиваются" к классу моделей через интерфейсы и наследование/ трейты / примеси

При этом :
1) Никак не изменяется код класса "Комментарий" (кроме подключения интерфейса) и в будущем мы добавляем поведения без изменения класса + стабильность системы, гибкость
2) Каждый класс имеет свое четкое назначение + легкость модификации, порядок
3) Комментарии наследуют некоторое поведение, путем подключения поведения, но также могут поступать любые другие классы - сущности (посты, блоги итп) , то есть интерфейс и реализация лайков универсальна, и весь функционал работы лайков находится только (строго!!!) в одном месте + легкость модификации, Универсальность, стабильность, интуитивная понятность

Из википедии :

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

Оттуда же про SOLID

Избавиться от "признаков плохого проекта"[4] помогают следующие пять принципов SOLID:

Принцип единственной ответственности (The Single Responsibility Principle)
Существует лишь одна причина, приводящая к появлению класса.

Принцип открытости/закрытости (The Open Closed Principle)
«программные сущности … должны быть открыты для расширения, но закрыты для модификации.»

Принцип подстановки Барбары Лисков (The Liskov Substitution Principle)
«объекты в программе должны быть заменяемыми на экземпляры их подтипов без изменения правильности выполнения программы.»

Принцип разделения интерфейса (The Interface Segregation Principle)
«много интерфейсов, специально предназначенных для клиентов, лучше, чем один интерфейс общего назначения.»

Принцип инверсии зависимостей (The Dependency Inversion Principle)
«Зависимость на Абстракциях. Нет зависимости на что-то конкретное.»

Если ты не понимаешь теорию, значит на практике у тебя ничего стоящего не выйдет.
А так вполне себе хорошая теория тут https://developer.mozilla.org/en-US/docs/Web/API/P...
И она содержит ссылочку на вполне себе реальный пример https://github.com/chrisdavidmills/push-api-demo

Как эта штука используется на практике.

После того, как вы определились с тем, что вы собираетесь отправлять, вам нужно сделать несколько вещей.
1. Запросить у пользователя разрешение на отправку уведомлений. Делается это через Notification.requestPermission. Если мы получили подтверждение, то идем дальше, если нет, забиваем на это дело. Здесь нужно быть очень осторожным и делать это ненавязчиво.

2. Создать фоновый обработчик, который будет принимать push-уведомления от сервера. Это делается через вызов navigator.serviceWorker.register. Например так https://github.com/chrisdavidmills/push-api-demo/b...
Он подписывается на канал. Канал - это как комната в чате.

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

3. Написать сервер уведомлений. У nginx есть хороший модуль. Он будет обслуживать клиентов.

Рекомендую к просмотру https://www.youtube.com/watch?v=5A5Iw9z6z2s