batyrmastyr

Если что-то совсем одностраничное, то «сохранить как - mht» в браузере.
Если покрупнее - то перегнать в chm через htm2chm. Не факт, что вытянет свежий js, но лучше начать с этого, чтобы не тащить 300 метров электрона.

С помощью любых транслируемых в WebAssembly, например Unreal Engine уже года три назад добавили поддержку работы в браузерах.

Независимо от выбора БД, отделять комментарии от расписаний нужно обязательно и каждый комментарий хранить отдельным документом/строкой. Так вы сможете забирать из базы не всю гипотетическую тысячу сообщений, а только новые.

Для сообщений в реальном времени: а правда ли вам нужно оно нужно или устроит задержка в 1 - 5 секунд? Если нужно, то стоит посмотреть на модуль HTTP Push Stream для nginx.

В 2020 чистый JavaScript только для «хренак-хренак и в продакшен» пригоден. Если и выбирать, то между TypeScript / Dart / PHP.

1) Типизация: PHP / TS / Dart
2) По скорости: для сайтов с < 200 000 просмотров в сутки даже на классическом php-fpm хватит пары ядер. Но если хочется «чтобы не хуже ноды», то смотрите в сторону swoole, roadrunner, amp и workerman с phpsocket.io.
3) Возможность писать клиентский и серверный код на одном языке: JavaScript / TypeScript / Dart.

В роли базы данных лучше возьмите постгрес - он лучше монги почти всем параметрам (скорость почти любых запросов, потребление памяти), только сложные запросы по json у него выглядят, кхм, страшненько. Но уж лучше страшные запросы, чем отдавать монге от 1 гига до 50% оперативки, строить индексы на все подряд поля и несмотря на это терпеть её тормоза.

В ЕС такая же история, причем длится она дольше, чем в РФ.

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

Если вам нужно демонстрировать заказчику, то передавайте ему изображение, а не сам сайт:
а) технически простой: приезжаете к нему и даёте тестировать при вас, следите чтобы не скопировал.
б) продвинутый: поднимаете RDP или VNC до своей [виртуальной] машины, на ней рубите исходящие соединения ко всему, кроме вашего сайта (любые порты и протоколы, а то ещё вспомнят времена www4mail).
Чтоб совсем сложно было - ищете скрипты ломающие отладчик браузера, чтобы и в отладчике не посмотрел.

базовый шрифт не 16px, а какие-нибудь 14.25px±50%

За такое надо исправить должность на "дизагнира". Дробные пиксели все браузеры отображают как хотят: кто-то округлит до целых, кто-то до сотых, как у вас, а кто-то честно отрисует даже 14,674956954px. Добавьте субпиксельное сглаживание и получите кучу вопросов "а что у вас шрифт такой мыльный?".

Реально ли пользователи подстраивают размер шрифта?

Сейчас пользователи могут только всю страницу масштабировать. Особо не пользуются, только если со зрением (у пользователя или создателей сайта) проблема.

Чего точно не стоит делать, так это смешивать пиксели и типографские пункты. Либо {font-size: 1em, line-height: 1.25em}, либо {font-size: 16px, line-height: 20px}. У нас сейчас решили использовать пиксели чтобы не думать, чему будут равны 1,4 пункта, особенно если кому-то приспичит сменить размер шрифта. Хотя лично я считаю допустимым при вёрстке в пикселях иногда использовать em для указания отступов, например, в :first-letter.

Из простых преимуществ постгреса - многие запросы в нём отрабатывают шустрее, можно весьма гибко прописать ограничения на данные (если в поле "а" что-то есть, то в поле "б" может быть только "с"), даже крупному магазину может хватить настроек по-умолчанию при которых база довольствуется смешным объёмом памяти.

Из недостатков по сравнению с Mysql - нет множеств (заменяется массивом перечислений), большая строгость работы (число или перечисление нельзя взять и сравнить со строкой "5 = '5'", нужно привести их к одному типу "5 = '5'::int" или " 5::text = '5'5 ", а ваша обёртка над базой может быть не готова к такому).

В контексте nosql баз данных например вижу преимущества в быстродействии, например, причем на порядок.

Увы, это преимущество скорее всего окажется мифом - сейчас как раз потихоньку выпиливаем MongoDB.
Если говорить про MongoDB, то в моих задачах он работал либо не быстрее мускуля или постгреса при поиске, либо в разы (в 2 - 50 раз) медленнее при записи. При этом Монга жрала 1,5 гига памяти, мускуль - 300 Мб, а постгрес - меньше 15 Мб (да, меньше жалких пятнадцати мегабайт).