Cookies vs. local storage: ¿Cuál es la mejor opción?

Con la llegada de HTML5 y sobre todo, de algunas API’s fundamentales de JavaScript 5, muchos programadores vimos hace años algunas opciones que parecían venir a sustituir viejos recursos tradicionales. Este es el caso de las cookies, que nos permiten almacenar información de los usuarios en nuestros servidores y comprobar su estado cada vez que la página es servida, pero, la aparición de las opciones localStorage y sessionStorage ha planteado dudas sobre qué camino seguir.

Bien, lo primero que hay que decir es que se trata de dos tecnologías distintas, especialmente, desde el punto de vista del almacenamiento, ya que las API localStorage y sessionStorage, lo hacen en el cliente. Así que dependerá de las necesidades de nuestra aplicación.

¿Cuáles son los pros y contras de estas dos opciones? Empecemos por las Cookies:

Pros

• Soporte heredado (ha existido por siempre)
• Datos persistentes
• Fechas de caducidad

Contras

• Cada dominio almacena todas sus cookies en una sola cadena, lo que puede dificultar el análisis de los datos
• Los datos no están encriptados
• Las cookies se envían con cada solicitud HTTP Tamaño limitado (4 KB)
• La inyección de SQL se puede realizar desde una cookie

Por su parte, en el Almacenamiento local (localStorage) podemos señalar:

Pros

• Soporte por la mayoría de los navegadores modernos
• Almacenado directamente en el navegador
• Las mismas reglas de origen se aplican a los datos de almacenamiento locales
• No se envía con cada solicitud HTTP
• ~ 5MB de almacenamiento por dominio (eso es 5120KB)

Contras

• No soportado por nada antes: así que el soporte no está disponible para los navegadores antiguos: IE 8, Firefox 3.5, Safari 4, Chrome 4, Opera 10.5, iOS 2.0, Android 2.0. Pero, como puede verse, ya es difícil encontrar estas versiones en uso hoy en día.
• Si el servidor necesita información almacenada del cliente, debe enviarla a propósito.

Además, existen una variante de localStorage, llamada sessionStorage, que permite almacenar datos con la garantía de que, cuando el usuario cierre el navegador o cambie de dominio, la información será borrada automáticamente. Esto es una solución ideal para los casos en los que solo necesitamos la información temporalmente (formularios encadenados o anidados, las distintas páginas de un asistente que recoge datos etc.).

Y, por si esto fuera poco, la programación es muy simple, y sigue el mismo patrón en ambos casos. Observa sino, como programar lectura/escritura en unas pocas instrucciones (incluso se dispone de dos sintaxis alternativas):

Y la forma en que podemos depurarlo es trivial, tanto usando IDE’s complejos, como Visual Studio o Eclipse, como desde el propio navegador, que nos muestra los valores directamente, en la pestaña “Application“, como podemos ver en la siguiente captura:

Si el que necesita la información es tu cliente (tu JavaScript), entonces, por supuesto, cambia. Estás desperdiciando ancho de banda al enviar todos los datos en cada encabezado HTTP.

Si se trata del servidor, el almacenamiento local no es tan útil porque tendría que reenviar los datos de alguna manera (con Ajax o campos de formulario ocultos o algo así). Esto podría estar bien si el servidor solo necesita un pequeño subconjunto del total de datos para cada solicitud.

Es más fácil trabajar con el almacenamiento local porque no es necesario analizar una cadena para obtener datos. En su lugar, puede hacer una llamada para el nombre de la variable y se devuelve su valor. Lo mismo se aplica a la creación y eliminación de datos también. Sin embargo, todavía se siguen usando las cookies, en parte por desconocimiento, y en parte (mucha menor parte), por  compatibilidad.