GreatBOND

Передача письма тут ни при чём. Просто почтовые клиенты (и отдельные и браузерные) не успевают за развитием стандартов веба. Им, фактически, нужно свой браузер реализовать или, наоборот, обрезать какие-то браузерные
возможности.

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

Браузерным клиентам нужно ещё следить, чтобы вёрстка письма не сломала сам клиент.

Но, на самом деле, с каждым годом становится всё лучше и лучше.

Недостаточно данных, какую именно игру хотите? Например, Годвилль ничем не отличается от обычного SPA. Если что-то должно бегать-прыгать-взрываться, то надо смотреть на игровые движки (phaser.io, CraftyJS), писать будете на JS или TypeScript. Если 3D — BabylonJS или PlayCanvas. Не исключен вариант с конструкторами типа ClickFusion или Construct 2, которые умеют публиковать в веб, тут вообще программирование мышкой. Unity 3D тоже умеет публиковать в веб. Еще многообещающий инструмент Blend4Web.

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

Язык - все тот же ЯваСкрипт, ему нет альтернатив. Раньше еще имело смысл на Флеше - сейчас уже не имеет смысл.

На сервере что за язык - значения не имеет.

Вам нужно создать файл php который будет обрабатывать данный запрос. Например ajax-form-comment.php. В нём вы описываите на php всю логику получения данных. Просто берёте всё из массива post. С помощью AJAX вы формируете запрос, файл php получает запрос от ajax, обрабатывает там, в БД добавляет комент и с помощью echo выводит ответ, например текст "Всё круто, записали коммент!" или в формате JSON. В функцию callback success или done (смотря какую вы будите использовать) придут эти данные как раз. И в ней вы опишите логику, например отрисовку данного добавленного комента (вам нужно лишь от сервера получить подтверждение что коммент попал в базу, а данные использовать теже что и отправляли AJAX-ом ранее на сервер). Если нужен код, то могу написать js часть.

$('form').on('submit',function(){//используйте id лучше
  e.pereventDefault();//блокируем действия по умолчанию, чтобы не перезагружать страницу
  var data;//записываем сюда данные которые хотим передать
  $.ajax({
    url:'file.php',
    data:data,//наши данные которые передадим
    method:'POST',//метод
    dataType:'text/plain',
  }).done(function(data){//допустим сервер будет возвращять JSON {isError="true",message="Всё записалось"}
    //описываем действия по получению ответа сервера
    if(data.isError==true){
      //коммент записался
      page.render(data);//отрисовываем наш комент с переданными рание данными
    }
  }).fail(function(err){
    //обрабатываем ошибку ajax
    
  });
});

В php всё ещё проще, просто массив разбераите, работаите с базой и echo возвращаите данные обратно)

Сглаживание шрифтов с помощью css

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

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

Пример где стоит использовать CMS: нужен эл. магазин, маленький бюджет и сроки тоже. Берем PrestaShop, устанавливаем, прикручиваем тему, настраиваем. Следующий!

Пример где стоит использовать фреймворк: вам нужен сайт на подобии того, на котором вы читаете мой ответ. Да, его можно за уши притянуть к понятию "блог", но переписывать и допиливать нужно многовато. Пойдем от обратного (вы таки выбрали WP)
* Потом поймете, что нужно было еще абстрактный уровень над WP написать, потому как после обновления ваши правки затерлись.
* Потом вдруг случается несчастье: ваш сайт стал популярным и железо не тянет, вы задумаетесь об масштабировании, но окажется, что система довольно таки целостная и что бы ее разделить придется не хило так по вкалывать.
* Через какое-то время ваш проект будет на 50% состоять переписанного кода и костылей, обходящих логику WP.
* Вдруг, на хабре вы читаете статью про уязвимость в вашей версии WP, начинаете ее прикручивать, при этом часть вашего сайта тупо отваливается из-за тех же артефактов и костылей. Вы, ясное дело, фиксите траблюки.
* В один прекрасный весенний денек, когда птички поют, радость, счастье, улыбки и бла-бла-бла вам звонит руководство и говорит, что "ничего не работает ( с )", отчаянье-печаль-грусть-уныние-безысходность-тлен. Зайдя на главную вы увидите замечательный баннер:
Вас взломал @ сраный_script_kid. Один глаз начнет немного дергаться, "это нормально ( с )". Восстановившись из бэкапа 4-х недельной давности, вы начинаете судорожно писать 1ккк проверок всего и вся. Система мутирует в еще более страшную и громоздкую хрень.
* Через какое-то время вас просят добавить фичу "на вчера", а что бы это сделать придется переписать добрую часть вашего монстра, вы (ну судя по количеству факапов) уже с прокачанным скилом "тебе фича не нужна эта" убеждаете руководство в этом, подобные разговоры возникают все чаще и в один прекрасный момент вы, или вас - увольняют.
* На смену вам компания набирает других человек, которые выльют пару ведер крови из глаз, убедят руководство, что код не саппортабельный и перепишут вашего монстра с 1,5кк строк до 0,3кк на нормальном фреймворке.

На скорость это не повлияет. Если логика завязана на очередность операций, то да, лучше по id сортировать.

Единственная возможность - сделать для body overflow:hidden, и обернуть контент в div, который будет иметь кастомный скроллбар, которым вы будете управлять через JS.

Нативно стилизация скроллбара крайне туго поддерживается, тем более кроссбраузерно.