Хочу рассказать ещё несколько вещей на тему локального хранилища.
У него есть ограничения на размер хранимой информации и этот размер равен примерно 5 мегабайт для каждого
origin. Может отличаться от браузера к браузеру, но мы же хотим чтобы всё работало в разных браузерах, значит нужно ориентироваться на минимум. Но что значит эти 5 мегабайт? Это значит что мы примерно можем сохранить строку из 5242880 англ. символов. И вот тут всплывает не самая очевидная деталь - ключи тоже занимают место. То есть мы можем сохранить 5 мег строку под пустым ключом. Или под ключом длиной 5 мег пустую строку. Ну и все промежуточные варианты, конечно. И логично было бы хранить всё одной строкой и не тратить место на ключи, но тогда возникает проблема производительности, ведь эту длинную строку придётся каждый раз перезаписывать целиком! Поэтому нужно искать компромисс между кол-вом ключей и размером значений.
Кстати, размер в 5 мегабайт можно и обойти, и я давно пришёл к этой идее и хотел даже библиотечку написать, но потом нашёл ещё людей, которые пришли к тому же!
Надёжный localStorage для букмарклетов,
Cross-Domain LocalStorage.
Что касаемо моего эксплорера, то во время теста на максимальное заполнение (посмотреть его можно
тут, только он совсем не юзерфрендли, не совсем понятно что он делает, если не заглядывать в код, но я создавал его для себя, а не для общего пользования), выяснилось, что браузер то не справляется с таблицей на тысячи строк...
И тут я пустился в размышления и понял, что единственный способ "отобразить" тысячи и больше единиц информации - это не отображать её в DOM, а держать в переменной javascript, и отображать только видимую часть. И это решит и проблему производительности и проблему памяти. Только вот думаю стоит использовать какой-нибудь фреймворк для таких манипуляций.
Если же смотреть только на производительность, то мой подход с переиспользованием элементов оказался не плохим вариантом! Дело в том, что это единственное, что смог осилить Интернет Эксплорер! И конкатенация строк в цикле с последующей записью в innerHTML таблицы, и insertAdjacentHTML в цикле, показали в десятки(!) раз худшую производительность! И если бы не IE, то я бы сказал, что конкатенация строк, то есть пересоздание таблицы в памяти с последующей записью в innerHTML нормальный и производительный способ! Он показал в 2 раза лучшую производительность в Хроме. И в новой версии я бы использовал именно этот подход. А так пришлось оставить всё как было...
Вот тут и эксперименты:
1,
2,
3