Что такое локальное хранилище
Что такое локальное хранилище и как его используют в программировании
Локальное хранилище данных — это новый инструмент, который был внедрен в HTML5 ; он дает возможность разработчику сохранять нужную ему информацию прямо в браузере пользователя на неограниченное количество времени, применяя средства JavaScript. Данные сохраняются в хранилище до тех пор, пока пользователь не удал яет их самостоятельно.
Фактически локальное хранилище данных — это простой объект, созданный при помощи JavaScript, в котором можно располагать какие-то данные и взаимодействовать с ними.
Что такое локальное хранилище данных
Локальное хранилище данных в HTML5— это главная альтернатива «кукам». Когда используются «куки», они должны создаваться с использованием сервера. Сервер — это не всегда понятно и в каком-то плане сложно, особенно для молодых программистов. Другое дело — локальное хранилище данных ; для его создания применяется исключительно JavaScript, что не может не радовать веб-разработчика.
изучать или п ользоваться каким-либо серверным языком программиро ва ния;
В этом случае все ограничится тем, что вам нужно будет добавить несколько строк в скрипт и организовать взаимодействие вашего сайта с локальным хранилищем силами браузера.
На первый взгляд локальное хранилище данных — это легко, просто и эффективно. В принципе, все так и есть. Однако у этой технологии есть определенные недостатки.
Недостатки локального хранилища данных
Локальное хранилище данных — это действительно очень просто, от этого у н его можно выделить следующие недостатки:
Хранит в себе данные только в виде строк. Более сложные структуры данных сохранять в локальном хранилище можно только преобразовав их в строчный вид. Но это так себе решение.
Синхронное взаимодействие. Это значит, что любые взаимодействия с локальным хранилищем выполняются одно за другим. В небольших приложениях это не страшно, но если приложение по сложнее и запросов к хранилищу будет много, то такое приложение будет медленно работать.
Очень низкая безопасность. Связано это с тем, что у локального хранилища данных нет никаких способов защититься от сторонних JS-скриптов. А это значит, что любой JS-скрипт со страницы может каким-то образом воздействовать на сведения, сохраняемые в хранилище.
сохраняемая информация не является конфиденциальной;
ваша разработка не будет является высоконагруженной;
информацию возможно сохранить в виде строк.
Заключение
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
LocalStorage на пальцах
Авторизуйтесь
LocalStorage на пальцах
Один из наших читателей прислал статью с рассказом о HTML5 LocalStorage в браузерах. Передаём ему слово.
Я постарался написать самое простое и понятное руководство по использованию технологии localStorage. Статья получилась совсем небольшой, в силу того, что и сама технология и средства работы с ней не несут ничего сложного. Для старта вам достаточно чуть-чуть знать JavaScript. Итак, уделите этой статье 10 минут и вы смело сможете добавить себе в резюме строчку «умею работать с localStorage».
Что такое localStorage?
Так выглядит JavaScript объект:
А так выглядит JSON. Почти так же как обычный js-объект, только все свойства должны быть заключены в кавычки.
Чтобы понять, что такое localStorage, просто представьте, что где-то у вас в браузере встроен такой объект, которым мы можем пользоваться. При этом данный объект не очищает значения, которые мы туда запишем, если мы перезагрузим страницу или даже совсем закроем браузер.
Если говорить языком JavaScript, то localStorage это свойство глобального объекта браузера (window). К нему можно обращаться как window.localStorage или просто localStorage.
Еще стоит сказать, что у браузера существует клон localStorage, который называется sessionStorage. Их разница только в том, что последний хранит данные только для одной вкладки (сессии) и просто очистит свое пространство как только мы закроем вкладку
13–15 декабря, Онлайн, Беcплатно
Давайте посмотрим на него вживую. Например, в Google Chrome вам надо открыть DevTools (F12), перейти на вкладку «Resourses» и на левой панели вы увидите localStorage для данного домена и все значения, что оно содержит.
Зачем мне нужен localStorage?
LocalStorage нужен только для одного — хранить определенные данные между сессиями пользователя. Можно придумать тысячу и одну вещь, которую можно хранить в локальном хранилище браузера. Например, браузерные игры, которые используют его как сохраненку, или записать момент, на котором пользователь остановился при просмотре видео, различные данные для форм и т.д.
Как мне начать работать с localStorage?
Работа с localStorage очень напоминает работу с объектами в JavaScript. Существует несколько методов для работы с ним.
Метод который добавляет в localStorage новый ключ со значением (а если такой ключ уже существует, то перезаписывает новым значением). Пишем, например, localStorage.setItem(‘myKey’, ‘myValue’);
Берем определенное значение из хранилища по ключу.
Очищаем все хранилище
Сейчас вы можете открыть вкладку с localStorage вашего браузера и самостоятельно потренироваться записывать и извлекать данные из этого хранилища. Если что — весь код пишем в js-файл.
Также хочется отметить, что localStorage отлично работает и с вложенными структурами, например, объектами.
Вы также должны знать, что браузеры выделяют 5мб под localStorage. И если вы его превысите — получите исключение QUOTA_EXCEEDED_ERR. Кстати, c его помощью можно проверять есть ли в вашем хранилище еще место.
Вместо заключения
Мне бы хотелось, чтобы из этой небольшой статьи разработчики сделали для себя простой вывод, что данная технология уже вовсю может использоваться у вас на проектах. У нее хорошая стандартизация и отличная поддержка, которая со временем только развивается.
sessionStorage и localStorage
В этой статье познакомимся с веб-хранилищами sessionStorage и localStorage, изучим методы JavaScript для работы, узнаем про их отличия друг от друга, и от файлов cookie, а также рассмотрим примеры использования в Google Tag Manager.
Самая большая проблема при использовании cookie в качестве локального хранилища заключается в том, что:
С появлением HTML5 мы получили доступ к более объемному веб-хранилищу (между 5 и 10 МБайт на каждый домен), которое сохраняет информацию между загрузками страницы и посещениями сайта (даже после выключения и включения компьютера). Кроме того, данные локального хранилища не отправляются на сервер при каждой загрузке страницы, в связи с чем ускоряется работа веб-приложения.
Существуют два основных типа веб-хранилища:
Оба типа являются свойствами глобального объекта браузера (window). К ним можно обращаться как window.sessionStorage (или sessionStorage) и window.localStorage (или localStorage) соответственно. В них можно хранить ТОЛЬКО СТРОКОВЫЕ ДАННЫЕ для ключей и их значений.
Разберем каждый из них подробнее.
sessionStorage (сессионное хранилище, хранилище сессии)
Объект sessionStorage используется гораздо реже, чем localStorage.
localStorage (локальное хранилище)
Каждый домен имеет доступ к своему хранилищу данных localStorage. Например, localStorage, используемый для, https://osipenkov.ru является отдельным от localStorage, используемым для https://coobiq.com. Субдомены (поддомены) и различные протоколы HTTP (HTTP и HTTPS) имеют независимые друг от друга хранилища данных. Например, localStorage https://gtm.osipenkov.ru используется полностью отдельно от https://osipenkov.ru. Точно так же localStorage https://osipenkov.ru используется отдельно от http://osipenkov.ru.
Некоторые браузеры блокируют localStorage в режиме инкогнито. localStorage работает даже с отключенными cookie.
Примечание: не храните в localStorage конфиденциальную информацию и личные данные пользователией, включая имя, фамилию, дату рождения, пароли, номера кредитных карт, номер телефона, e-mail и многое другое.
Что можно хранить и для чего использовать?
Хранение данных в локальном хранилище очень распространено. Классическим примером использования локального хранилища является веб-приложение типа Ежедневник, когда пользователь составляет список дел на день, и по мере выполнения удаляет их из списка. Для выполнения этой задачи не нужен сервер, подойдет localStorage. Кликнув по задаче из списка, которое человек уже сделал, она будет удаляться с локального хранилища и, следовательно, показываться пользователю больше не будет. Локальное хранилище часто используется для сохранения настроек пользователя на сайте (выбор темы оформления, вид отображения информации), чтобы при следующем заходе эти данные уже были применены к его профилю и повторно не вводились.
Посмотреть, что из себя представляют sessionStorage и localStorage, какие данные там хранятся у разных сайтов, можно в консоли разработчика на вкладе Application (для браузера Google Chrome).
Веб-хранилище (вкладка Application)
Либо использовать команды sessionStorage и localStorage на вкладке Console:
Команда sessionStorage или localStorage (вкладка Console)
Карточка пользователя по одному из чатов
sessionStorage vs localStorage vs cookies
Нагляднее всего продемонстрировать отличия между sessionStorage, localStorage и cookies с помощью таблицы:
Отличие cookies от sessionStorage и localStorage
Помимо этого, согласно правилам обработки персональных данных, установленных Генеральным регламентом ЕС о защите персональных данных (или GDPR — General Data Protection Regulation), владелец сайта должен получать разрешение от пользователей на использование файлов cookie. Для локального хранилища этого не требуется.
Как вы уже знаете, сейчас в части браузеров используется технология «умной защиты от слежения», которая предоставляет отчеты о заблокированных трекерах (в том числе и счетчиках веб-аналитики), тем самым препятствуется слежение за пользователями и показ им персонализированной рекламы с помощью файлов cookie. Хоть мы и можем устанавливать срок жизни куки, их время все равно зависит от настроек самих браузеров. Например, система интеллектуального отслеживания (Intelligent Tracking Prevention, ITP 2.2) Apple ограничивает в Safari использование основных файлов cookie (first-party) до 1 дня. В результате файлы cookie, установленные рекламными сервисами, например, Facebook, Google или Яндексом, для измерения трафика сайта и атрибуции рекламы, будут удалены через 24 часа. И если человек нажимает на рекламное объявление в пятницу, а затем решает отложить покупку в выходные, то в понедельник у нас уже не будет cookie, чтобы показать ему рекламу и напомнить о приобретении. Остается только надеется на то, что человек запомнил наш сайт и вернется сам.
Чтобы отслеживать пользователей больше этого времени, можно использовать localStorage. Но и тут разочарование относительно пользователей Safari. В последних обновлениях разработчики добавили ограничение в 7 дней, то есть срок жизни данных в локальном хранилище теперь ограничен. Когда пользователь просматривает сайт через Safari, счетчик становится равен 7 дням. В течение этого времени он должен повторно вернуться на сайт, чтобы мы смогли использовать информацию из локального хранилища. В противном случае данные по истечении этого времени будут удалены из localStorage.
Так или иначе, sessionStorage и localStorage активно используются разработчиками при разработке веб-приложений, а интернет-маркетологами как альтернатива файлам cookie. В блоге Симо Ахавы (Simo Ahava) есть статья, которая посвящена хранению Client ID в localStorage для Google Analytics.
Методы и свойства
Объекты хранилища sessionStorage и localStorage предоставляют одинаковые методы и свойства:
Запись данных в хранилище
Функция setItem(key, value) принимает ключ в качестве первого аргумента и значение в качестве второго аргумента. Как упоминалось ранее, все данные должны быть строками. Примеры установки:
Локальное хранилище
Перевод: Влад Мержевич
Постоянное локальное хранилище это одна из областей, где клиентские приложения имеют преимущества перед серверными. Для приложений, таких как операционная система, обеспечивается уровень абстракции для хранения и извлечения данных вроде настроек или статуса выполнения. Эти значения могут быть сохранены в реестре, INI-файлах, XML-файлах или в другом месте в зависимости от принципов платформы. Если ваше клиентское приложение нуждается в локальном хранилище больше чем просто пара ключ/значение, вы можете вставить свою собственную базу данных, придумать свой формат файлов или любое количество других решений.
Исторически, у веб-приложений не было ни одной из этих роскошей. Кукисы были изобретены в начале истории Интернета и они могут быть использованы для постоянного локального хранения небольших объемов данных. Но у них есть три потенциальных минуса:
Вот что мы действительно хотим:
Перед HTML5 все попытки добиться этого в конечном итоге были по-разному провальными.
Краткая история локального хранилища до HTML5
Вначале был только один Internet Explorer. По крайней мере, Майкрософт хотел, чтобы мир так думал. С этой целью в рамках Первой Великой Войны браузеров Майкрософт изобрел очень много вещей и включил их в свой браузер-который-завершил-войну — Internet Explorer. Одна из этих вещей была названа DHTML Behaviors, а одна из форм поведения называется userData.
UserData позволяет веб-странице хранить до 64 Кб данных на каждый домен в иерархической XML-подобной структуре. Доверенные домены, такие как интранет-сайты могут хранить в десять раз больше. И эй, 640 Кб должно быть достаточно для всех. IE не представил какой-либо способ изменить эти соглашения, поэтому нет способа увеличить объем доступной памяти.
В 2002 году компания Adobe представила функцию во Flash 6, которая получилась неудачной и с названием, вводящим в заблуждение — «Flash-кукисы». В среде Flash эта возможность известна более правильно как Local Shared Objects (локальные доступные объекты, LSO). Вкратце, она позволяет Flash-объектам хранить до 100 Кб данных на каждый домен. Брэд Нойберг разработавший ранний прототип моста между Flash и JavaScript назвал ее AMASS (AJAX Massive Storage System), но она была ограничена некоторыми причудами Flash-дизайна. К 2006 году с появлением ExternalInterface во Flash 8 доступ к LSO через JavaScript стал на порядок проще и быстрее. Брэд переписал AMASS и интегрировал ее в популярный Dojo Toolkit под псевдонимом dojox.storage. Flash «бесплатно» дает каждому домену 100 кб для хранения. Кроме того, он предлагает пользователю при запросе увеличивать объем хранения на порядок (1 Мб, 10 Мб и т.д.).
В 2007 году Google запустила Gears, открытый плагин для браузера направленный на обеспечение дополнительных возможностей. Мы уже обсуждали Gears ранее в контексте обеспечения геолокации в Internet Explorer. Gears предоставляет API для встроенной базы данных на основе SQLite. После получения единственного разрешения от пользователя, Gears может хранить неограниченное количество данных для каждого домена в таблицах базы данных SQL.
В то же время Брэд Нойберг и другие продолжали вкалывать на dojox.storage чтобы обеспечить единый интерфейс для всех этих разных плагинов и API. На 2009 год dojox.storage может автоматически определить (и обеспечить универсальный интерфейс) Adobe Flash, Gears, Adobe AIR и ранний прототип хранилища HTML5, который был реализован только в старых версиях Firefox.
В обзоре этих решений есть закономерность: все они либо специфичны для одного браузера, либо полагаются на сторонние плагины. Несмотря на героические усилия, они все радикально различаются интерфейсами, имеют разные ограничения по хранению и предоставляют разные способы взаимодействия с пользователем. Вот проблема, которую в HTML5 необходимо было решить: обеспечить стандартный API, который изначально поддерживается несколькими браузерами без необходимости полагаться на сторонние плагины.
Введение в хранилище HTML5
То, что я буду называть «HTML5-хранилище» в спецификации именуется «веб-хранилище», которое в свое время было частью спецификации HTML5, но затем выделено в отдельную спецификацию по неинтересным для вас политическим мотивам. Некоторые разработчики браузеров также называют его «Локальное хранилище» или «DOM-хранилище». Ситуацию с именами осложняют некоторые похожие названия из других стандартов, о которых пойдет речь ниже.
Так что такое HTML5-хранилище? Проще говоря, это способ для веб-страниц хранить пары ключ/значение локально с помощью браузера. Как и кукисы, эти данные сохраняется даже после ухода с сайта, закрытия вкладки браузера, с выходом из браузера или чего-нибудь еще. В отличие от кукисов эти данные никогда не передаются на удаленный веб-сервер (если только вы не пожелаете отправлять их самостоятельно). В отличие от всех предыдущих попыток обеспечить постоянное локальное хранилище, эта технология встроена в браузеры, поэтому она доступна даже тогда, когда нет сторонних плагинов.
Какие браузеры? Ну, последние версии практически каждого браузера поддерживает HTML5-хранилище. даже Internet Explorer!
| IE | Firefox | Safari | Chrome | Opera | iPhone | Android |
| 8.0+ | 3.5+ | 4.0+ | 4.0+ | 10.5+ | 2.0+ | 2.0+ |
Проверка на HTML5-хранилище
Вместо самостоятельного написания этой функции, вы можете использовать библиотеку Modernizr.
if (Modernizr.localstorage) <
// window.localStorage is available!
> else <
// нет встроенной поддержки HTML5-хранилища
>
Использование HTML5-хранилища
Интерфейс хранилища <
Получить через getItem(ключ);
Установить через setItem(ключ, данные);
>;
Вызов setItem() с существующим именем ключа молча перепишет предыдущее значение. Вызов getItem() с несуществующим ключом вернет NULL, а не вызовет исключение.
может быть переписан с использованием синтаксиса квадратных скобок:
Есть также методы для удаления значений по имени ключа, а также очистки всего хранилища (то есть удаление всех ключей и значений одновременно).
Интерфейс хранилища <
Удалить через removeItem(ключ);
clear();
>
Вызов removeItem() с несуществующим ключом ничего не вернет.
Наконец, есть свойство для получения общего количества значений в области хранения и для перебора всех ключей по индексу (получает имя каждого ключа).
Интерфейс хранилища <
length
Получить key(целое неотрицательное число);
>
Слежение за областью HTML5-хранилища
if (window.addEventListener) <
window.addEventListener(«storage», handle_storage, false);
> else <
window.attachEvent(«onstorage», handle_storage);
>;
| Свойство | Тип | Описание |
|---|---|---|
| key | string | Ключ может быть добавлен, удален или изменен. |
| oldValue | любой | Предыдущее значение (если переписано) или null, если добавлено новое значение. |
| newValue | любой | Новое значение или null, если удалено. |
| url* | string | Страница, которая вызывает метод, приведший к изменению. |
Событие storage нельзя отменить, внутри функции обратного вызова handle_storage нет возможности остановить изменение. Это просто способ браузеру сказать вам: «Эй, это только что случилось. Вы ничего не можете сделать, я просто хотел, чтобы вы знали».
Ограничения в текущих браузерах
Говоря об истории локального хранилища с помощью сторонних плагинов, я упомянул про ограничения каждой техники. Я вспомнил, что не сказал ничего об ограничениях теперь уже стандартного HTML5-хранилища. Я дам вам ответы, а затем объясню их. Ответы в порядке важности такие: «5 мегабайт», «QUOTA_EXCEEDED_ERR» и «нет».
«5 мегабайт» — сколько места для хранения выдается по умолчанию. Это значение на удивление одинаково во всех браузерах, хотя и сформулировано не более как предложение в спецификации HTML5. Надо понимать, что вы храните строки, а не данные в исходном формате. Если вы храните много целых чисел или чисел с плавающей запятой, разница в представлении может оказаться большой. Каждая цифра в числе с плавающей запятой хранится в виде символа, а не в обычном представлении для таких чисел.
«QUOTA_EXCEEDED_ERR» это исключение, которое вы получите, если превысите свою квоту в 5 Мб. «Нет» является ответом на следующий очевидный вопрос: «Могу ли я попросить у пользователя больше пространства для хранения?». На момент написания в браузерах не реализован какой-либо механизм для веб-разработчиков, чтобы запросить больше места для хранения. Некоторые браузеры (например, Opera) позволяют пользователю контролировать квоты хранилища для каждого сайта, но это чисто инициатива пользователя, не связанная с тем, что вы как разработчик можете встроить в ваше веб-приложение.
HTML5-хранилище в действии
Давайте посмотрим на HTML5-хранилище в действии. Снова обратимся к игре «уголки», которую мы построили в главе про рисование. С этой игрой связана небольшая проблема: если вы закроете окно браузера посередине игры, то потеряете результаты. Но с HTML5-хранилищем мы можем сохранять процесс игры на месте, в самом браузере. Откройте демонстрацию, сделайте несколько ходов, закройте вкладку браузера, а затем снова ее откройте. Если ваш браузер поддерживает HTML5-хранилище, демонстрационная страница волшебным образом вспомнит точное положение в игре, в том числе, сколько ходов вы сделали, положение каждой фишки на доске и даже выбранную фишку.
Как это работает? Каждый раз, когда происходит изменение в игре, мы будем вызывать эту функцию.
function resumeGame() <
if (!supportsLocalStorage()) < return false; >
gGameInProgress = (localStorage[«halma.game.in.progress»] == «true»);
if (!gGameInProgress) < return false; >
gPieces = new Array(kNumPieces);
for (var i = 0; i gGameInProgress ) является логическим типом. В функции saveGameState() мы просто храним его и не беспокоимся о типе данных.
Но в функции resumeGame() мы должны рассмотреть значение, полученное из локального хранилища в виде строки и вручную построить собственное логическое значение.
gGameInProgress = (localStorage[«halma.game.in.progress»] == «true»);
Аналогичным образом, число ходов хранится в gMoveCount как целое, в функции saveGameState() мы просто сохраняем его.
За пределами пары ключ/значение: конкурентное видение
Хотя в истории было много уловок и обходных путей, нынешнее состояние HTML5-хранилища на удивление благополучно. Новый API был стандартизирован и включен во все основные браузеры, платформы и устройства. Для веб-разработчика такое увидишь не каждый день, не так ли? Но это больше, чем «5 мегабайт пар ключ/значение» и будущее постоянного локального хранилища это. как бы сказать. ну, пусть конкурентное видение.
Одно видение является аббревиатурой, которую вы уже знаете — SQL. В 2007 году Google запустил Gears, кроссбраузерный плагин с открытым исходным кодом, в который включена встроенная база данных на основе SQLite. Этот ранний прототип позже повлиял на создание спецификации Web SQL Database. База данных Web SQL (ранее известная как «WebDB») обеспечивает тонкую оболочку вокруг базы данных SQL, что позволяет делать следующие вещи из JavaScript:
openDatabase(‘documents’, ‘1.0’, ‘Local document storage’, 5*1024*1024, function (db) <
db.changeVersion(», ‘1.0’, function (t) <
t.executeSql(‘CREATE TABLE docids (id, name)’);
>, error);
>);
Как вы можете видеть, большая часть действий находится в строке с методом ExecuteSQL. Эта строка может поддерживать любые команды SQL, в том числе SELECT, UPDATE, INSERT и DELETE. Это все равно, что серверное программирования баз данных, за исключением того, что вы делаете это с JavaScript! О радость!
Спецификация базы данных Web SQL была реализована в четырех браузерах и платформах.
| IE | Firefox | Safari | Chrome | Opera | iPhone | Android |
| – | – | 4.0+ | 4.0+ | 10.5+ | 3.0+ | 2.0+ |
Конечно, если вы использовали более чем одну базу данных в своей жизни, то знаете, что «SQL» это скорее маркетинговый термин, чем жесткий и быстрый стандарт (кто-то может сказать то же самое об HTML5, но это не важно). Конечно, есть актуальная спецификация SQL (она называется SQL-92), но в мире нет сервера баз данных, который соответствует только этой спецификации. Есть Oracle SQL, Microsoft SQL, SQL в MySQL, SQL в PostgreSQL, SQL в SQLite. В действительности, каждый из этих продуктов с течением времени добавляет новые функции SQL, так что недостаточно даже произнести «SQL в SQLite». Вы должны сказать «версия SQL, который поставляется вместе с SQLite версии X.Y.Z».
Все это подводит нас к следующей оговорке, в настоящее время размещенной вверху спецификации Web SQL.
Спецификация зашла в тупик: все заинтересованные разработчики используют серверный SQL (SQLite), но нам нужно несколько независимых реализаций, чтобы двигаться по пути стандартизации. Пока другие разработчики заинтересованы в реализации этой спецификации, описание диалекта SQL было оставлено как обычная ссылка на Sqlite, который не приемлем для стандарта.
Именно на этом фоне я расскажу вам о другом конкурентном видении для продвинутых, постоянное локальное хранилище для веб-приложений: Indexed Database API, ранее известное как «WebSimpleDB», теперь ласково называемое IndexedDB.
Indexed Database API предоставляет то, что называется хранилище объектов, при этом много идей заимствовано из баз данных SQL. Есть «базы данных» с «записями», каждая запись имеет определенное количество «полей». У каждого поля есть определенный тип данных, который определяется при создании базы данных. Вы можете выбрать часть записей, затем перечислить их «курсором». Изменения в хранилище объектов обрабатываются с «транзакциями».
Если вы хоть раз программировали базы данных SQL, то эти термины, вероятно, вам знакомы. Основная разница в том, что хранилище объектов не имеет структурированного языка запросов. Вы не напишите условие вроде «SELECT * from USERS where ACTIVE = ‘Y'». Вместо этого используются методы, предоставляемые хранилищем объектов для открытия базы USERS, перечисления записей, фильтрации наших записей и использование методов доступа для получения значения каждого поля оставшихся записей. An early walk-through of IndexedDB (Ранний проход IndexedDB) это хорошее руководство о том, как работает IndexedDB и сравнение IndexedDB с Web SQL.
На момент написания IndexedDB был реализован только в бета-версии Firefox 4. Для контраста, Mozilla заявила, что никогда не будет воплощать Web SQL. Google заявил, что они рассматривают поддержку IndexedDB для Chromium и Google Chrome. И даже Майкрософт заявил, что IndexedDB «отличное решение для веб».
Что вы как веб-разработчик можете делать с IndexedDB? На данный момент практически ничего, кроме некоторых технологических демонстраций. Через год? Возможно.