ThunderCat

С тем же успехом можно было спросить "Какие сейчас тенденции в программировании?" Web-разработка - это настолько обширная область, что общие тенденции в ней вряд ли возможны. Если брать относительно узкую категорию "Клепание однообразных говносайтов для ИПшников" то да, агрессивный маркетинг 1С всё ещё держит битрикс на плаву.

В принципе можно.
Но может тогда лучше класс создать с необходимыми методами?

class fun1 {
  constructor(){
    // код...
    this.#fun2();
  }
  #fun2() {
    // код...
    this.#fun3();
  }
  #fun3() {
    // код...
    // вызов какой-то из вложенных функций
  }
  #fun4() {
    // код...
    // вызов какой-то из вложенных функций
  }
}

const f1 = new fun1();

Использовать action можно, можете хоть сотню форм на одной странице иметь, это не мешает никак.
POST предпочтительнее для форм, чем GET, некоторые типы данных вообще не получится отправить через GET.

пока не нашел, как их обрабатывать на стороне php

это шедевр. Вы могли бы написать эту фразу просто в гугл, без "пока не нашёл", и сразу найти
https://www.php.net/manual/ru/reserved.variables.p...

Собственно, так и делают.
Только вордообразный wysiwyg редактор прикручивают (CKEditor, TinyMCE и т д)

ну как вариант

.slick-slider:not(.slick-initialized) {
  opacity: 0;
}

По поводу смыслов. Обычно с БД работают сущностями (entities). Я не специалист в Node и я не знаю
как у вас принято. Кажется в новых ecma-спецификациях уже ввели понятие класса.

В данном коде идет проверка на то что email существует. Но полезный эффект - слабый.
Я-бы сразу возвращал сущность пользователя. Чтоб не бегать потом в базу еще
раз когда надо поискать имя или дату регистрации. Ну идея такая что
если вы уж пошли в базу (это сетевой round-trip) то постарайтесь
за этот трип собрать максимум информации.

Вот это более рационально

export const findUserEntityByEmail = async (
  email: string
): Promise<User> => {
  try {
    const users = await db
      .query('SELECT * FROM accounts WHERE email = $1', [email])

Тоже самое относится к выборкам множества строк по множеству ключей.
Лучше сделать 1 callback который вернет коллекцию чем для коллекции
ключей дергать один несчастный метод который по штучке что-то достает.

Еще важне - join. Если соединяете сущности - то соединяйте сразу в БД
без попыток соединять в приложении. Это кстати еще бонус к компетенции
в части ACID.

Тоесть идеальный вариант работы с БД - запросить пакетом всю информацию
что может потербоваться на ближайшие несколько секунд. Это рациональнее
чем потом что-то подтягивать.

<?php
$fmt = new IntlDateFormatter(
    'ru_RU',
    IntlDateFormatter::MEDIUM,
    IntlDateFormatter::NONE,
    'Europe/Moscow',
    IntlDateFormatter::GREGORIAN,
);
$date = new DateTimeImmutable('2021-5-1');
print $fmt->format($date);
// 01 мая 2021 г.

Но в mysql есть же json поля, что если построить нужное дерево в виде json

... то получится база, в которую удобно записывать, в которой удобно хранить, из которой удобно извлекать - и всё. Любые другие действия - поиск, изменение, сортировка, парсинг и пр.- совершенно неудобны. И с производительностью у них не очень. Так что лучше прикопать эту идею по-тихому, чтобы никто не заметил.

Кстати, ковыряние JSON руками... либо JSON не более сотни байт, либо ни разу не развлечение (если ты не мазохист, конечно).

Несколько мыслей.

1) У меня устойчивое дежа-вю. Периодически в топик заходят люди с именно этим вопросом. Разница только в количестве. Кому 1 млрд. Кому 10. Можно также поискать и слинковать эти вопросы в один большой вопрос.

2) MySQL который указан в тегах - нормально справляется с этой задачей. Он и не такое число строк
умеет хранить. И если взять MariaDb - там есть куча новых engines которые можно крутить для тюнинга
именно скорости чтения. Разумеется жертвуя чем-то другим. Транзакциями и записью например.

3) Непонятно что такое минимальное время? Если использовать дисковую БД типа MySQL то деградация времени
поиска будет примерно зависеть от логарифма количества строк. Тоесть деградация будет но очень медленно.
Для 10 млрд индекс по key будет содержать порядка 4-5 уровней BTree дерева. Тоесть дисковой системе
нужно будет сделать до 5 или до 6 рандомных чтений (если нужные данные лежат в таблице). Это достаточно
быстро для того чтобы моргнуть глазом за это время. Рандомное чтение любого блока из магнитного диска
класса SATA-3 занимает порядка 20 милисекунд. Тоесть для 5 уровней - это 100 милисекунд. Для дисков
класса SSD и это время можно уже считать меньше милисекунды. Точно я не знаю надо мерять.

Испортить это время может сетевой лаг который в данной задаче мы просто не учитываем. Считаем что сеть идеальна.

4) Непонятно зачем здесь указан Redis. Его задача не хранить 10 млрд а хранить только горячие
ключи по котороым идет очень частый доступ. Если автор хочет In-memory хранение - то время можно
еще сильнее улучшить. Его можно свести практически до нуля (я вангую несколько микро-секунд)
но придется прикупить планок памяти побольше и посчитать сколько памяти
надо для 10 млрд key/values неизвестной длины. Вообще крутить регулятор в направлении
микро-секунд нет особого смысла т.к. другие звенья вашего стека (приложение и сеть) могут
быть на порядки медленнее а это вообще нивелирует всю пользу от такой оптимизации.

Вот ваши сырники 62 кб. Можно ещё легче сделать без потери качества.
Подробности здесь

(Картины весят не более 1мб) 2мб первая же рандомная на которую я ткнул) попробуй tiny.png сервис потом jpg перегнать в webp

ну и для мобильной подгружай картинки с поменьше размером - воспользуйся тегом picture - вот микро гайд

<picture>
<source srcset="assets/images/blobs_orig.webp" type="image/webp" media="(min-width:1533px)">
<source srcset="assets/images/blobs_orig_mobile.webp" type="image/webp" media="(min-width:280px)">
<img src="assets/images/blobs_orig_mobile.webp" alt="Картинки людей">
</picture>

Есть подозрение, что из-за него некорректно работает форма авторизации / регистрации на сайте.

Надо бороться с причиной, а не с явлением как таковым. Если форма криво работает из-под VPN, то виновата форма, а не VPN. Половина мира уже сидит в интеренет под VPN, поэтому стоит задуматься о том, что у тебя не так реализовано. Тем более, что каких то объективных причин нарушения работы web-сервера если на него поступают запросы от VPN нет.
Я бы скорее предположил, что в форме реализованы какие то скрипты (возможно даже сторонние JS библиотеки), который блокировщики рекламы считают спамом, и режут их, отсюда и проблема. Надо конкретно смотреть, что не так.

ак определить, что у пользователя включен vpn

Ну определишь ты, и что дальше? Как это тебе поможет реализовать исправление ошибки формы? Лучше задуматься о том, как исправить форму, чтобы все могkи ей пользоваться независимо от VPN.

Другие технологии, их есть у нас. Называется - просто не делай этого вообще.
Игрок получил повреждения - записываешь в базу, и все, ничего не регенерируешь.
Когда произойдет какое-то новое взаимодействие с игроком - получил новый урон, обновил страницу, или какая там у вас игровая логика, тогда уже, при помощи формулы "прошедшее_время * скорость_регена = сколько_здоровья_оргененило".
С баффами все немножко сложнее, но смысл тот-же - считайте формулой, и в тот момент когда данные нужны, а не в фоновом процессе неведомо зачем.

Нельзя вот так просто отправить на печать браузерных js без подтверждения пользователя.
Если делаете для себя, то есть парочка костылей со стороны браузера или ОС.
https://stackoverflow.com/questions/9213660/html-j...

В шторме это встроенная функция, в vscode плагины (первый попавшийся) есть и и консольные утилиты, тысячи их.

Вообще ситуация странная - открытый код и вдруг файлы в одну строку. Вы не пробовали другим редактором открыть, может у вашего какие-то настройки заклинило и он перестал правильно воспринимать переводы строки?