Припиніть використовувати localStorage! І зверніть увагу на альтернативи

Розробник та блогер Julien Etienne у своїй колонці на платформі Medium радить відмовитися від localStorage. Ми переклали текст, щоб ви могли ознайомитися з його аргументами. Далі — слово автору.

localStorage не був розроблений для сучасних додатків і не підтримує алгоритм структурованого клонування. Заголовок не є клікбейтом, повідомлення різке: «Припиніть використовувати localStorage!». Тут немає ніякої двозначності, і ми не беремося за руки і не співаємо кумбайя, щоб пом’якшити удар.

localStorage з’явився на сцені приблизно в 2009 році як сховище на основі рядків розміром 5 МБ. Він ніколи не був розроблений як остаточний спосіб зберігання даних у браузері.

Давайте відразу перейдемо до суті з деякими основними моментами, оскільки наша увага в наші дні розсіяна:

• Один тип даних: Ви можете зберігати лише рядки. Якщо ви хочете зберігати щось інше, вам доведеться серіалізувати це у рядок і десеріалізувати для отримання.
• Історично повільний: localStorage дещо повільно зберігає та отримує дані, що робить його небажаним для додатків, які потребують частих транзакцій.
• Обмежене сховище: localStorage має ліміт 5 Мб.
• Помилки серіалізації: Якщо ви не знайомі з помилками при зберіганні даних у localStorage, ви можете створювати помилки у вашому додатку. Ці типові помилки не завжди очевидні, особливо для розробників-новачків.
• Блокування операцій: localStorage не є асинхронним і буде блокувати ваш додаток. За певних умов це може навіть призвести до переривчастості анімації. Асинхронність має фундаментальне значення для створення гнучких додатків, особливо для мобільних пристроїв

Що сталося з WebSQL?

WebSQL мала на меті бути простим інтерфейсом бази даних SQL для Інтернету. Він мав пристойну підтримку, але з часом зіткнувся з проблемами, які призвели до його занепаду.

Чому вони кинули дитину?

• Реалізація одним постачальником: WebSQL був в першу чергу веб-кітом (спочатку Chrome і Safari). Відсутність підтримки з боку інших великих виробників браузерів (Mozilla та Microsoft) зробила впровадження розробниками майже неіснуючим у комерційному світі.
• Відсутність стандартизації W3C: це має вирішальне значення для прийняття. W3, схоже, відмовився від цієї пропозиції у 2010 році.
• Конкуренція з IndexedDB: IndexedDB набувала все більшої популярності та підтримки під час розвитку WebSQL. На відміну від WebSQL, IndexedDB була розроблена як стандартне, кросбраузерне рішення.
• Проблеми з безпекою: Декілька розробників та спеціалістів з безпеки висловили занепокоєння щодо безпеки WebSQL. Вони були скептично налаштовані щодо різних аспектів, включаючи відсутність контролю дозволів та вразливості в стилі SOL.

Зрештою, IndexedDB стала «рекомендованим» стандартом для зберігання даних на стороні клієнта, оскільки вважається більш надійною та кросбраузерною. Але що хорошого в «рекомендованому», якщо більшість досвідчених фронтенд-розробників на момент написання цієї статті уникали його, як чуми?

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

А як щодо Cookies?

Файли cookie були створені в 1994 році Лу Монтуллі, розробником веб-браузерів компанії Netscape Communications.

Дехто з вас ще навіть не народився, коли файли cookie псували життя. Назва цієї статті мала б бути «Припиніть використовувати файли cookie та localStorage», але це дуже важка боротьба (так, ми повинні використовувати безпечні файли cookie).

• Обмеження розміру: Розмір файлів cookie зазвичай обмежений приблизно 4 Кб на домен.
• Дані надсилаються з кожним запитом: Файли cookie надсилаються з кожним HTTP-запитом до відповідного домену. Якщо ваші дані не потрібно передавати з кожним запитом, це може призвести до непотрібних накладних витрат і підвищеного використання пропускної здатності.
• Занепокоєння з приводу безпеки: Файли cookie більш вразливі до XSS. Оскільки файли cookie автоматично додаються до кожного запиту до домену, вони можуть стати мішенню для шкідливих скриптів.
• Термін дії та термін служби: Файли cookie були розроблені таким чином, щоб їх термін дії закінчувався до певної дати.
• Збільшення затримки: Оскільки файли cookie автоматично включаються до кожного HTTP-запиту до домену, вони зазвичай призводять до збільшення затримок, що уповільнює завантаження вашого веб-сайту.

Чому IndexedDB

• Краща продуктивність: На відміну від localStorage, IndexedDB працює асинхронно, запобігаючи блокуванню операцій (API керується подіями, а не обіцянками).
• Велика квота сховища: IndexedDB надає більший обсяг пам’яті (залежить від браузера, операційної системи та доступного сховища) порівняно з місцевим сховищем localStorage, яке обмежується 5 МБ.
• Надійність та структурованість даних: Зберігання та пошук даних у localStroage може призвести до непередбачуваних результатів, якщо не робити це належним чином. IndexedDB зменшує загальний примус до типів і використовує алгоритм структурованого клонування, забезпечуючи цілісність даних.

Ймовірно, ви не захочете використовувати IndexedDB безпосередньо

Це зовсім не весело, і у вас є кращі заняття, ніж боротися з вороже налаштованим сховищем, щоб потім розчаруватися через те, що воно виявилося не таким, як ви очікували.

Причина, з якої ви хочете користуватися бібліотекою, полягає в тому, що здебільшого вони:

• Засновані на обіцянках;
• Простіші у використанні;
• Зменшити шаблонний код;
• Зосередження на більш значущих речах.

Я не рекомендую використовувати бібліотеки, розмір яких перевищує, наприклад, 10 кБ у заархівованому вигляді. Всі ці кілобайти складаються, і ці бібліотеки розміром понад 50 кБ не роблять нічого значущого для ваших реальних сценаріїв.

Єдина проблема, яку я виявив з більшістю бібліотек IndexedDB, полягає в тому, що вони здебільшого орієнтовані на керування версіями, що вам, ймовірно, зовсім не потрібно, особливо якщо ви просто шукаєте розумну альтернативу localStorage.

Швидка затичка: я створив db64, бібліотеку, щоб зосередитися на більш відносних аспектах IndexedDB.

Якщо вам потрібна версійність або курсори, я б порекомендував idb, яка є всеосяжною бібліотекою, що добре покриває всі нішеві випадки.

Висновок

На мою думку, ніхто не повинен використовувати localStorage в наш час. Новим розробникам краще погратися з Promise() або async/ await, ніж намагатися з’ясувати, чому число «0» робить їхні умови truthy.

Підсумовуючи, можна сказати, що є перевага у швидкості, це неблокування, ви можете надійно зберігати типи і навіть використовувати курсор для ітерації над записами, якщо вам подобаються такі речі, ви можете легко побудувати пошукову систему на стороні клієнта з накопиченими вибірками даних, які не змушують ваші анімації смикатися, як це робить localStorage, блокуючи і втручаючись в них.

Для постійного зберігання даних IndexedDB є кращим інструментом, особливо якщо ви використовуєте бібліотеку-обгортку, щоб полегшити собі життя.