Игорь Николаевич: не всегда у вопрошающего хватает компетенций, чтобы понять ответ. Ничего страшного, пробуйте решить проблему самостоятельно, чтобы набить все шишки самому.
OVK2015: я вас не собирался благодарить (я не автор вопроса), а вот вы меня можете поблагодарить, что я удержался от написания ответа аналогичного вашему, но с возможностью получить себе плюсик в рейтинг :).
Игорь Николаевич: попробуйте такой вариант, но я бы не смешивал setTimeout и requestAnimationFrame, для фиксированного количества FPS лучше внутри requestAnimationFrame делать проверку, прошло ли нужное для следующего фрейма время: stackoverflow.com/questions/19764018/controlling-f... .
Виталий Столяров: не на все вопросы можно нагуглить простые и однозначные ответы "для детей". Для того, чтобы понять нагугленное, нужно будет хотя бы немного разобраться с тем, как работают компиляторы, интерпретаторы, транспиляторы, JIT-оптимизаторы, менеджеры памяти, сборщики мусора, и прочие кишочки платформы . И научиться понимать алгоритмическую сложность, а не "синтаксическую" (наивно веря, что вся скорость упирается в язык).
Дмитрий Беляев: давайте столько, сколько есть, менеджер памяти программы на асме возьмёт столько, сколько нужно. Зачем надстраивать менеджера над менеджером? Компульсивное желание обрезать память процессу под самый минимум идёт ещё со времён DOS, в которой не было своего менеджера памяти. А в современных операционных системах можно хоть террабайт выделить, а работать будет только реально используемая. Современные программы не пытаются уменьшить количество используемой памяти, наоборот, они резервируют максимум, чтобы проинформировать ОС об потенциальных пиках нагрузки.
Недопустимо. В идеологии реакта (точнее, флакса и его производных) предполагается, что всё изменяемое состояние приложения лежит в сторе. (Это помимо вопроса о целесообразности вообще выносить в глобальную переменную стилизацию, озвученного выше.)
logpol32: слушатель событий привязывается к элементу в момент объявления слушателя. Если вы объявили слушателя до того, как создали элементы DOM, то слушатель ни к чему не привязался. Потому вам посоветовали привязать слушателя событий к элементу, который точно УЖЕ есть в документе и никуда не денется - к элементу body.
Сергей Савостин: вам приятно лишь до тех пор, пока вы пишите хеловорлды и мечтаете о том, как напишете убийцу фейсбука. А как только начнёте воплощать реальный проект, тут все ваши "ручки" и ударят больно по голове. Но этот опыт будет даже полезен и важен, чтобы "пощупать", что такое сложность в информационных системах (желательно ещё и почувствовать проблемы разделения работ в командной разработке), чтобы адекватнее оценивать технологии и проблемы, решая которые технологии и придумывают.
Вы все минусы сами описали. Но, видимо, не очень их осознали, раз считаете, что после их формулирования имеет смысл продолжать искать ответ на свой вопрос :).
