ThunderCat

1) Проверить консоль, все ошибки проанализировать, или, в случае затупа, скинуть сюда ошибки.
2) Возможно на главной не хватает каких-то скриптов, которые подключаются и работают на других страницах
3) Как вариант - проверить что висит на кнопке бургера и в код раскрытия добавить логирование в консоль, проверить что блок нажимается хотя бы
4) Проверить перекрытие блоками, временно добавить всем элементам бордер 1 пх солид блэк, убедиться что ничего не перекрывается
5) Проверить стили, возможно что там где-то у вас выключено взаимодействие с элементом, например через pointer-events: none; Вижу его в стилях, проверьте его наличие при загрузке на элементе.

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

Уровень Novice: Js + html + electron
Уровень Advanced: C# + WPF
Уровень Pro: Java + Swing

Первое что приходит в голову - конвертировать игровую валюту в реальные вещи/услуги, например за условный миллион фантиков поход с папой в интересное место - зоопарк, аквапарк, кино, роллердром, просто в кафе.

Так же, в списке может быть что-то полезное из материального, например моя племяшка обожает книги, что сильно облегчает мне выбор подарков. Книга, одежда/обувь или бижутерия вполне могут быть призом.

Что касается внутриигрового контента - вполне можно попробовать на какой-нибудь полубирже (Яндекс Задания, Воркзилла) заказать набор спрайтов для игры у студентов за шапку сухарей. Генерится на компе за пару часов, у многих уже готовые сборки нейронок стоят локально, по этому особо проблем с платным Миджорней/Дали уже нету.

Что касается разных персонажей, вроде использование сида (заранее заданного числа которое задает некоторую рандомность начальной генерации) создает низкую вариативность нечетко прописанных вещей, делая упор на описанные детали. Так можно получить вариации одежды на одинаковых персонажах.

Если для написания тз у вас не хватает компетенций, то для начала сделайте юзерстори и/или майндмап. Распишите все возможные действия пользователя + желательно самые простые картинки как это +- выглядит и как работает. Во первых оцEните объем работ, во вторых откроете для себя кучу нюансов различного характера, в третьих с этим уже можно идти к более-менее адекватной команде за ПРИМЕРНЫМ ценником.

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

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

Варианты перехода с Bootstrap 3 на Bootstrap 5:
1. Постепенная миграция (Hybrid approach)

Подключить Bootstrap 5 с префиксом классов
Переписывать компоненты по одному
Использовать CSS-изоляцию для избежания конфликтов
Плюсы: Сайт остается рабочим, можно мигрировать частями
Минусы: Увеличенный размер CSS, сложность поддержки

2. Использование Bootstrap Migration Tool

Автоматические инструменты для замены классов
Скрипты для массовой замены в файлах
Плюсы: Быстрая автоматизация базовых изменений
Минусы: Не покрывает все кейсы, нужна ручная доработка

3. Создание CSS-моста (Polyfill)

Написать CSS-правила для совместимости классов BS3
Создать алиасы для старых классов
Плюсы: Минимальные изменения в HTML
Минусы: Не все компоненты можно эмулировать, устаревший подход

4. Полная перепись с нуля

Установить Bootstrap 5
Переписать все компоненты и страницы
Плюсы: Современный код, лучшая производительность
Минусы: Много времени, высокий риск поломок

5. Использование CSS-in-JS или препроцессоров

Создать миксины для совместимости
Использовать SCSS для переопределения
Плюсы: Гибкость настройки
Минусы: Нужны знания препроцессоров

6. Bootstrap 4 как промежуточный этап

Сначала мигрировать на BS4, потом на BS5
Плюсы: Меньше кардинальных изменений за раз
Минусы: Двойная работа

7. Микросервисный подход

Переписывать отдельные секции сайта на новом Bootstrap
Постепенно заменять старые части
Плюсы: Изолированные изменения
Минусы: Сложность интеграции

Для больших проектов: Постепенная миграция (#1)
Для средних проектов: Bootstrap 4 как промежуточный этап (#6)
Для небольших сайтов: Полная перепись (#4)
При ограниченном времени: CSS-мост (#3)

это делает сайт более уязвимым к XSS атакам.

Нет, скорее это наносит больший ущерб в случае удачной атаки, к самой защите от атак это никак не относится.

Так что же лучше, устанавливать куки стороне клиента или сервере?

Что лучше, мягкое или теплое? Разные куки подходят для разных задач. Если речь все еще про токены и авторизацию - только бэкенд.

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

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

По моему вы пытаетесь переизобрести реакт/вуе.
Простой ответ - react router.

Как мне их правильно соединить?

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

Или frontend и backend размещены разными программами?

что-то мне подсказывает что наверное вы рановато по знаниям взялись за задачу...

пути к файлам пишут от корня сайта, а не от папки темплейта, соответственно если документ рут у вас в app_dir, то путь должен быть src="/static/img.png" и src="/templates/img.png"

https://web.archive.org/web/20120420212500/http://...

И заметила, что основная часть задач - инфраструктурная.

Такой работы всегда много, но есть нюансы.

Настройка тестов

Да, это в любой разработке будет, не только во фронте

CI/CD

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

OLAP CUBE, оптимизация запросов к БД.

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

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

Извините, но
Первое - определить проблему. Как базовый вариант - ларавель дебагбар + телескоп. Смотреть что и как по времени отрабатывает, смотреть какие куски тормозят, делать точечные замеры исполнения. Обратить внимание на количество и качество запросов, вполне возможно что где-то натыкано левых или кривых запросов, еще и настаканных по 200 штук...
Второе - 80% что тормозит не код, а бд, но тут это чисто статистическое предположение, так как что там у вас в базе никто не знает. Проверьте запросы, долговыполняющиеся прогнать руками через експлэйн, проверить наличие нужных индексов и отсутствие ненужных.
Если критических косяков нет, то даже весьма средняя машинка потянет некрупный проект с небольшой базой.

FF + AdGuard?
Алсо, что-то типа тампермонки/оранжмонки...