Леха Ярков

В книге идентичный пример работает почему-то

Фокусы руками, найдите различие:

mysql> CREATE TABLE album ( artist_id SMALLINT(5) NOT NULL, album_id SMALLINT(4) NOT NULL AUTO_INCREMENT, album_name CHAR(128) DEFAULT NULL, PRIMARY KEY (artist_id, album_id) ) engine=innodb;
ERROR 1075 (42000): Incorrect table definition; there can be only one auto column and it must be defined as a key
mysql> CREATE TABLE album ( artist_id SMALLINT(5) NOT NULL, album_id SMALLINT(4) NOT NULL AUTO_INCREMENT, album_name CHAR(128) DEFAULT NULL, PRIMARY KEY (artist_id, album_id) ) engine=myisam;
Query OK, 0 rows affected (0,00 sec)

mysql>

У вас с книгой разные дефолтные движки, в будущем от этого могут ещё сюрпризы возникать. Очень разные myisam и innodb по поведению, возможностям и ограничениям.

под данные о текущих боях (расположение кораблей, ходы) сделал просто глобальный объект с массивами

Я бы так не делал. Во первых, по хорошему, на каждый бой должен запускаться отдельный процесс. Чтобы процесс боя падая не убивал с собой весь стек сервисов. Хранить данные можно в памяти, можно файлом на разделе tmpfs.
Не забывайте, важно не допускать race conditions.
Если у вас используется express/connect, сведите к минимуму обращения middleware к глобальным объектам, и ни в коем случае не сохраняйте ничего в глобальных из middleware. Есть объекты для общих данных, например, app.locals, res.locals; есть много реализаций сессий.

Позже заметил
matrix[i] = Array('','','','','','','','','','');
наверное, правильнее так
matrix[i] = ['','','','','','','','','',''];

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

Как же сложно изъясняетесь.

Получает тело документа.

Как я понимаю js получает от обработчика то, что выводится в echo или print_r.

Вы спрашиваете, как отдать php обработчиком json data?

Можно ли вернуть массив, что то по типу return?

Допустим мы имеем массив

$arr = [
"name" => "vasya", 
"age" => "23"
];

Используя функцию json_encode выводим этот массив в виде json.
echo json_encode($arr);

P.S. Если я так и не понял вопроса, то оставьте комментарий с разъяснениями.

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

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

Оно не должно мешать загрузке остальной страницы и ее скриптов.

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

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

Лучше добавить в теги скрипт атрибуты async или defer. Первый не блокирует рендеринг страницы, но начинает свое исполнение сразу как только загружен. Это потенциально может привести к проблемам. Например попап еще не отрендерен, а скрипт уже начал выполнение и не нашел в разметке попапа, не смог повесить обработчики событий и все нерабочий попап получится. Из-за этого же этот атрибут не гарантирует, что скрипты будут выполнятся в том порядке в котором объявлены. Опять же одни скрипты могут зависить от других и это может привести к неработающему функционалу.

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

Вообще есть бесплатный курс по оптимизации загрузки страницы от гугла. https://www.udacity.com/course/website-performance...

Кажется я в итоге не на ваш вопрос ответил.

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

1. Если тебе где-то нужно переопределить стили в каком-то отдельном контексте придеться такую же длинную цепочку фигачить.
2. Ну и размер файла стилей это не уменьшает.
3. Плюс дополнительные элементы цепочки это лишние циклы поиска браузером соответствии элементов в ДОМ структуре, что ест ресурс. Одна цепочка может не заметна, но полчища таких цепочек уверен могут показать существенную разницу.
4. Потом браузер ведь читает справа налево. В .navbar .navbar-right-menu li.notify-dropdown .notify-list li a .notify-body он сначало найдет все .notify-body, потом начнет проверять какие из них вложены в тег a и искать будет до самого верхнего эелемента пока не найдет или не упреться в бади. Потом начент проверять а какие из них лежат внутри списка li и тд. Куча ненужных обработок.
5. В этом же ключе стоит упомянуть, что селекторы в идеале все должны быть классами. А селекторы теги типа a, li, p, span и тд нужно избегать потому что они неспецифичны, не несут большой ценности, создают лишние цыклы обхода дерева элементов. По той же причине нельзя использовать селектор *.

В идеале вообще не должно быть вложенных селекторов. Почитай про БЕМ методологию. https://ru.bem.info/methodology/ Максимум 2 в крайних случаях три уровня вложенности.