Интернет експлорер преподнёс пару сюрпризов. Оказалось, что методы add и remove у classList не поддерживают множественные аргументы.
Добавил реакцию на событие storage. Теперь изменения сделанные в одной вкладке/окне, сразу видны во всех других. И тут скрывался очередной сюрприз! Все ие от этого страдают, пришлось добавить throttler. В принципе, я и так собирался это сделать, чтоб перерисовывать DOM через requestAnimationFrame.

Хочу рассказать ещё несколько вещей на тему локального хранилища.
У него есть ограничения на размер хранимой информации и этот размер равен примерно 5 мегабайт для каждого origin. Может отличаться от браузера к браузеру, но мы же хотим чтобы всё работало в разных браузерах, значит нужно ориентироваться на минимум. Но что значит эти 5 мегабайт? Это значит что мы примерно можем сохранить строку из 5242880 англ. символов. И вот тут всплывает не самая очевидная деталь - ключи тоже занимают место. То есть мы можем сохранить 5 мег строку под пустым ключом. Или под ключом длиной 5 мег пустую строку. Ну и все промежуточные варианты, конечно. И логично было бы хранить всё одной строкой и не тратить место на ключи, но тогда возникает проблема производительности, ведь эту длинную строку придётся каждый раз перезаписывать целиком! Поэтому нужно искать компромисс между кол-вом ключей и размером значений.
Кстати, размер в 5 мегабайт можно и обойти, и я давно пришёл к этой идее и хотел даже библиотечку написать, но потом нашёл ещё людей, которые пришли к тому же!
Надёжный localStorage для букмарклетов,
Cross-Domain LocalStorage.

Что касаемо моего эксплорера, то во время теста на максимальное заполнение (посмотреть его можно тут, только он совсем не юзерфрендли, не совсем понятно что он делает, если не заглядывать в код, но я создавал его для себя, а не для общего пользования), выяснилось, что браузер то не справляется с таблицей на тысячи строк... :cray:
И тут я пустился в размышления и понял, что единственный способ "отобразить" тысячи и больше единиц информации - это не отображать её в DOM, а держать в переменной javascript, и отображать только видимую часть. И это решит и проблему производительности и проблему памяти. Только вот думаю стоит использовать какой-нибудь фреймворк для таких манипуляций.

Если же смотреть только на производительность, то мой подход с переиспользованием элементов оказался не плохим вариантом! Дело в том, что это единственное, что смог осилить Интернет Эксплорер! И конкатенация строк в цикле с последующей записью в innerHTML таблицы, и insertAdjacentHTML в цикле, показали в десятки(!) раз худшую производительность! И если бы не IE, то я бы сказал, что конкатенация строк, то есть пересоздание таблицы в памяти с последующей записью в innerHTML нормальный и производительный способ! Он показал в 2 раза лучшую производительность в Хроме. И в новой версии я бы использовал именно этот подход. А так пришлось оставить всё как было...
Вот тут и эксперименты: 1, 2, 3

Что можно хранить в локальном хранилище в таких объемах?
Почему именно в локальном хранилище?

Ну почему, потому-что простые вещи, как уровень игрока в игре, проще хранить именно в нём, это и послужило началом для этой темы. А дальше я просто делюсь тем что ещё знаю об этом. Это, конечно, не единственный способ сохранять информацию! Простые вещи можно хранить в куках, например, но там совсем мало места и они шлются каждый раз на сервер. Ещё localStorage хорошо поддерживается браузерами и не спрашивает разрешения пользователя, и с ним проще работать чем с куками! Так что для простых вещей самое то.

А о каких "таких" объёмах речь? Пока речь идёт о тексте, кажется что 5 мегабайт это много, но как только дело дойдёт до картинок, много вы туда сможете сохранить? Сейчас эра вебаппликаций, вот вы загружаете фото в соц. сеть и вдруг раз, пропал интернет. Картинка временно сохраняется локально, а потом синхронизируется с сервером при появлении связи.

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

Все используемые в работе данные обязаны храниться только на сервере.
Если lvl персонажа хранится на клиенте и используется для каких-либо расчетов, то это колоссальная дыра.
Данные персонажа можно передать клиенту при инициализации и сохранить их в ram.
Т.е. опять же нет необходимости хранить данные персонажа на клиенте в localStorage.

PS. а изображения в localStorage вы храните в base64?

В простейшем случае да, тем более что канвас поддерживает экспорт в base64.

Это Вы в конституции интернета прочитали?
Вон товарищ зачем-то хочет в PNG сохранять историю действий. По моему ему идеально подошёл бы localStorage. Вот уж не знаешь что глупее, хранить текст в картинке или картинку в тексте!

Пришедшие с сервера, да. Но я говорил про загруженные пользователем с диска, которые он хотел загрузить НА сервер, но вдруг пропал интернет. Он закрывает сайт, а потом при повторном открытии они ждут в localStorage и сами синхронизируются. Вот тут интересная вещь - https://pouchdb.com/, но я ей ещё не пользовался. Там и сервер и поддержка разных хранилищ на клиенте. Кстати, браузер кеширует, но он не гарантирует сколько он их будет хранить в кеше. Всё это, конечно, моё личное мнение о том как стоит организовать работу приложения. Для кого-то такой подход может быть не приемлем. Более того, это только теория, а реализация может по разным причинам отличаться.

Да, а ещё если сохранять место до которого пользователь дочитал в книге в localStorage, то это, получается, тоже дыра? В игре уровень хранится исключительно для удобства пользователя.
А Вы для каждого простого приложения держите сервер и проводите регистрацию пользователей?
В любом случае речь идёт об offline first web app, то есть приложение, которое должно в первую очередь работать без наличия интернета. И многие принципы, которые были актуальны раньше, тут уже не подходят.

А тем временем я написал "полнофункциональное" приложение для просмотра и редактирования localStorage, sessionStorage и cookie на своём сайте и с возможностью кроссдоменного доступа через букмарклет. Так же приложение доступно оффлайн через технологию application cache.
Storage Explorer
UPD: Ссылка на репозиторий https://github.com/yesasha/storage-explorer